Explore topic-wise InterviewSolutions in .

Though it varies DEPENDING on the SIZE and structure of the software DEVELOPMENT teams, typically, a bug can be assigned the following types of severities, going from low to high:

• Low
  • User Interface bugs
  • Accessibility issues
• Medium
  • Leaky abstractions
  • Software hangs
  • Users unable to PERFORM a specific action
  • Boundary conditions
• High
  • Crashing under high load
  • Business logic and/or calculation errors
  • Any user action that causes the software to crash
  • Exposing SENSITIVE user data
  • Security problems
  • Loss of data

1. Selenium: a web browser automation tool that automates the test suites you need to run on a web browser.[1]
2. Protractor: An end-to-end test framework for Angular and ANGULARJS applications. Protractor runs tests against your application RUNNING in a real browser, interacting with it as a user would.[2]
3. Cypress: A modern front-end testing tool BUILT for the modern web. Though it’s similar to Selenium and Protractor, it’s architecturally different from them.[3]
4. Jasmine: This is an open-source JavaScript testing framework that allows you to write behavior-driven tests.[4]
5. JUnit and NUnit: These are unit testing frameworks for Java and C# PROGRAMMING languages, respectively. 

All SOFTWARE has a target user. A user story describes the user's motivations and what they are trying to accomplish by using the software. Finally, it shows how the user uses the application. It ignores the design and implementation details.

A user story aims to focus on the value provided to the end-user instead of the exact inputs they might enter and the expected output.

In a user story, the tester creates user personas with REAL NAMES and characteristics and tries to simulate a real-life INTERACTION with the software. A user story often helps fish out hidden problems that are often not revealed by more formal testing processes.

Some common MISTAKES INCLUDE: 

• Poor Scheduling 
• Underestimating 
• IGNORING small issues 
• Not following the exact process 
• Improper RESOURCE allocation 

A software bug is an error in the software that produces wrong results. A software tester tests the software to FIND bugs in it.

There are many causes for the bugs—for example, poor design, sloppy programming, lack of version control, or miscommunication. Throughout development, developers introduce hundreds or thousands of bugs in the system. The goal of the tester is to uncover those bugs.

You can find a bug in many different ways, regardless of your role. When building the software, the software developer might notice the bug in ANOTHER module, written by another developer or by themselves. The tester actively tries to find the bugs as part of a routine testing process. Finally, the users could see the bugs when the software is in production.

All bugs, no matter how they are found, are recorded into a bug-tracking system. A triage TEAM triages the bugs and assigns a priority to the bug, and assigns the bug to a software developer to fix it. Once the developer resolves the problem, they check in the code and MARK that bug as ready for testing. Once a bug is ready for testing, it goes to the tester, who tests the software to verify if it’s indeed fixed. If it is, then it’s closed. If not, they assign it to the same developer with a description of the exact steps to reproduce the bug. Some examples of popular bug-tracking systems include BugZilla, FogBugz, etc.

Trivia:
The first software bug was discovered by Admiral Grace Hopper, on September 9, 1947. After they opened a malfunctioning PIECE of hardware, they found an insect stuck in the relay. Image Source: Link

QA stands for Quality Assurance. In a software development team, a QA ensures that the software is thoroughly tested before releasing it to the end-users. 

QA activities are GENERALLY performed while the product is being developed and focuses on improving the software development process.

In many software organizations, a tester and a QA can be the same person, but they can be different depending on the organization's size. The goal of the QA is to ensure quality in the shipped software.

Quality Control: QC stands for Quality Control. Its main aim is to ensure that the developed products meet the required STANDARDS or not.

QC is a process in software engineering that is used to ensure Software product quality by testing and REVIEWING its functional and non-functional requirements. QC activities are generally performed after the product is developed as it examines the quality of the end products and the final outcome. 

In manual testing, a tester manually verifies the functionality of the software. The tester has a comprehensive list of all the test cases they should test, along with the test data. They go through each case, one by one. They launch the software as an end-user would, enter the input, and manually verify the output.  

It may seem that manual testing is INEFFICIENT when compared to automated testing. It is slow, not REPEATABLE in a consistent manner, and prone to HUMAN misjudgment.

However, manual testing allows the tester to realistically test the software, using actual user data in a natural user environment, subject to similar external conditions. Only a human, not a computer, can evaluate the usability and ACCESSIBILITY of the application and how it looks and feels to the end-user. It also gives a broader perspective of the system. Finally, some test scenarios just can't be automated and NEED to be manually tested.

You should always test the software manually before trying to automate the testing.

Test-Driven-DEVELOPMENT (TDD) is a popular software development technique, first introduced by Kent Beck in his book with the same name, published in 1999.

In TDD, a developer working on a feature first writes a failing test, then writes just enough code to make that test pass. Once they have a passing test, they add another failing test and then write just enough code to pass the failing test. This cycle repeats until the developer has the fully working feature. If the code under the test has external dependencies such as database, files, or network, you can MOCK them to isolate the code. 

Benefits of TDD:

• Writing tests first forces you to think about the feature you are trying to build, helping you produce better code. 
• As you always have a working set of tests at hand, a failing test indicates that the problem is with the code you just added, reducing the time spent in debugging. 
• Writing tests HELP the developer to clarify the requirements and specification. It’s challenging to write good tests for a poor set of requirements. 
• It’s tough to produce high-quality software unless you can test the software after each new CHANGE. You can NEVER be sure that your new code didn’t break the working software. TDD gives you the confidence to add new code, as you already have a test in place.

Testing metrics provide a high-level overview to the management or the developers on how the project is going and the next action steps. 

Here are some of the metrics derived from a record of the tests and failures:

• Total number of defects found, ordered by their severity
• Total number of bugs FIXED
• Total number of PROBLEMS CAUSED by an error in the source code vs. configuration or external environmental factors
• Bug find and fix RATE over time
• Bugs by produce/feature area
• The average time is taken by a bug since it’s found and fixed. 
• Total time SPENT on new feature development vs. time spent on resolving bugs and failures
• Number of outstanding bugs before a release
• Bugs/failures reported by the customers vs. those found by the testers

Non-functional testing tests the system's non-functional requirements, which REFER to an attribute or quality of the system explicitly REQUESTED by the client. These include performance, security, SCALABILITY, and usability.

Non-functional testing comes after functional testing. It tests the general characteristics unrelated to the functional requirements of the software. Non-functional testing ensures that the software is SECURE, scalable, high-performance, and won't CRASH under heavy load. 

During testing, a tester records their observations, findings, and other information useful to the developers or the management. All this data belongs to a test record, also called a bug report.

A detailed bug report is an important artifact PRODUCED during testing. It helps the team members with:

• Understand the problem,
• Steps to reproduce the problem,
• The environment and the specific conditions under which it happens, and
• The resolution if/when the developers fix the problem.

Here are a few bits of information that a good bug report should contain. Image Source: Bugzilla

For example, here is a picture of a bug reported on Jira, a popular bug-tracking software. 

Any software tester's goal is to find out as many bugs and PROBLEMS in the system so that the customers don't have to. Hence, a good software tester should have a keen eye for detail. They should know the ins and outs of the software they are testing and push every aspect of the software to its limits, to identify bugs that are hard to find with the software's regular use.

Having the domain knowledge of the application is essential. If a tester doesn't understand the specific problems the software is trying to solve, they won't be able to test it thoroughly.

A good tester should keep the end-user in mind when they are testing. Having empathy with the end-user helps the tester ensure that the software is accessible and usable. Simultaneously, the tester should possess basic PROGRAMMING skills to think from a developer's perspective, which ALLOWS them to notice common programming errors such as null-references, out-of-memory errors, etc.

Communication, both written and VERBAL, is an essential skill for a tester. A tester will frequently have to interact with both the developers and the management. They should be able to explain the bugs and problems FOUND during testing to the developers. For each bug found, a good tester should provide a detailed bug report consisting of all the information a developer would need to fix that problem. They should be able to make a good case to the management if they are uncomfortable releasing the software if it contains unresolved issues.

Similar to software development, testing has its life cycle. During the testing, a tester goes through the FOLLOWING activities.  

1. Understand the requirements: Before testing software or a feature, the tester must first understand what it is supposed to do. If they don’t KNOW how the software is supposed to work, they can’t test it effectively. 
2. Test Planning and CASE Development: Once the tester has a clear understanding of the requirements, they can create a test plan. It includes the scope of testing, i.e., part of software under test and objectives for testing. Various activities are involved in planning the test, such as creating documentation, estimating the time and efforts involved, deciding the tools and platforms, and the individuals who will be conducting the tests.
3. Prepare a test environment: The development happens in a development environment, i.e., on a developer’s computer that might not represent the actual environment that the software will run in production. A tester prepares an environment with the test data that mimics the end user’s environment. It assists with realistic testing of the software. 
4. Generate the test data: Though it is impossible to do exhaustive testing of the software, the tester tries to use realistic test data to give them the confidence that the software will survive the real WORLD if it passes the tests. 
5. Test Execution: Once the tester has a complete understanding of the software and has a test environment set up with the test data, they execute the test. Here, execution means that the tester runs the software or the feature under test and verifies the output with the expected outcome. 
6. Test Closure: At the end of the test execution, there can be two possible outcomes. First, the tester finds a bug in the part of the software under test. In this case, they create a test record/bug report. Second, the software works as expected. Both these events INDICATE the end of the test cycle. 

Developers make POOR testers. Here are some reasons why:

• They try to test the code to make sure that it works, rather than testing all the ways in which it doesn't work. 
• SINCE they wrote it themselves, developers tend to be very optimistic about the software and don't have the correct attitude NEEDED for testing: to break software. 
• Developers skip the more sophisticated tests that an experienced tester would PERFORM to break the software. They follow the happy PATH to execute the code from start to finish with proper inputs, often not enough to get the confidence to ship software in production.

However, it doesn't mean that developers shouldn't test the software before sending it to the tester. Developer testing helps find many bugs that are caused by programming errors. These are hard to find for a tester because they don't always have access to the source code.

You can test the software in many different ways. Some TYPES of testing are conducted by software developers and some by specialized quality assurance STAFF. Here are a few different kinds of software testing, along with a brief description of each.

It is impossible to exhaustively test software or PROVE the absence of errors, no matter how specific your test strategy is.

An extensive test that finds HUNDREDS of errors doesn’t imply that it has discovered them all. There could be many more errors that the test might have missed. The absence of errors doesn’t mean there are no errors, and the software is perfect. It could easily mean ineffective or incomplete tests. To prove that a program works, you’d have to test all possible inputs and their combinations.

Consider a simple program that takes a string as an input that is ten characters long. To test it with each possible input, you’d have to enter 2610 names, which is impossible. Since exhaustive testing is not practical, your best strategy as a tester is to pick the test cases that are most likely to FIND errors. Testing is sufficient when you have ENOUGH confidence to release the software and assume it will work as expected.

Software testing comes into play at different times in different software development METHODOLOGIES. There are two main methodologies in software development, namely Waterfall and Agile.

In a traditional waterfall software development model, requirements are gathered first. Then a specification document is CREATED based on the document, which drives the design and development of the software. Finally, the testers conduct the testing at the END of the software development life cycle once the complete software system is built.

An agile software development model works in small iterations. You test the software in parallel as it is GETTING built. The developers build a small functionality according to the requirements. The testers test it and GET customer feedback, which drives future development.