Software Quality Assurance Interview Questions
We will list the top Software Quality Assurance Interview Questions here in this article. Go through them and prepare well for your upcoming interview.
Question 1: In the world of software development, software testing and software quality assurance are often used together. Even to the extent that these two seem so similar, and to some people, they may mean the same. As one with knowledge of software development, what would you describe to be;
- i. Software Testing
- ii. Software Quality Assurance.
- iii. Do you think software testing and software quality assurance are the same? If your answer is no, in your own words, what would you say constitutes the difference between these two?
Question 2: Looking at the SDLC (Software Development Life-Cycle), there’s so much involved from requirement gathering and analysis, design, coding, testing, deployment, and lastly, maintenance. How important or necessary is testing? Or, in a bid to save costs incurred in software development, what reasons can you give regarding why the software project manager should not strike out the testing phase?
Question 3: In Software development, there are some basic postulates often referred to as software principles. These are essential theories that every software tester or software QA professional should know before going into practice. There are 7 of these theories that are popularly recognized. Which include:
- Software testing is an activity that shows the presence of defects only but can not be used to show the absence of any defects.
- Software testing can never be completely exhaustive.
- Absence of software error fallacy
- Software Defect Clustering
- Pesticide Paradox, etc
Explain briefly and very simply any three (3) of the above-mentioned five (5) software testing principles.
Question 4: In question 3 above, point (b) talks about software testing not being exhaustive. Since software testing is not completely exhaustive, identify and explain three bases for exiting the software testing phase.
Question 5: To successfully divide the steps to developing software into phases. Each phase is focused on achieving a certain and particular goal. Systems referred to as software development models are developed. One of these models, the oldest and most popular of them, is the waterfall model. Can you share your understanding of the waterfall model and some of the disadvantages of this model with us?
Question 6: In software testing, the approach to testing usually falls amongst two categories, namely static and dynamic testing. In static testing, testing is done without running the code, and the dynamic approach to testing is the exact opposite of the static approach. The Static approach to testing is further divided into walk-throughs and code reviews, amongst others. In your own words, give a short and simple explanation of what you understand to be walkthroughs and code reviews under the static approach to software testing.
Question 7: As the team leader of the software QA unit in this company. After giving your software project manager reasons from question two (2) above regarding why he/she should not strike out the software testing phase to save cost incurred in developing a particular software the company just got the contract to develop from the government. Your software project manager is still adamant about not including the software QA unit on a particular project. To further try to convince your software project manager, can you tell him about at least two (2) infamous software failures in the history of humankind?
Question 8: As a professional software QA expert, give brief explanations detailing the difference between the following terms:
- Build and Release
- Bug release and Bug leakage
- Retesting and Regression Testing
Question 9: In question 6, we discussed the two main approaches to testing be static and dynamic testing approaches. In question 6, we focused on static testing, testing that is done without running the code, and dynamic testing to be testing that is done when running the code.
- In not more than 3 sentences, mention any objective(s) of dynamic testing that you know.
- Explain equivalence partitioning as a technique of the dynamic approach to testing
- Boundary value analysis was invented as a modification of the Equivalence Partitioning technique. What do you understand to be the difference between these two?
Question 10: Automated testing or automation testing is an alternative to manual testing, and in this form of testing, software tools are used to execute testing and test reporting. And to be able to effectively and efficiently write testing scripts, knowledge of some scripting languages like Python or Perl is necessary. As head of the software QA unit, under what kind of situations would you advise that automation testing be employed?
ANSWERS TO SOFTWARE QA INTERVIEW QUESTIONS
- i. Software testing is a process or activity carried out during the entire software development cycle. The duration is always dependent on the software development model being used. Software testing is usually executing code, whether as fragments or as a whole, with the sole intent of finding bugs in the code. But this is not always so as errors can still be discovered without running the code, and this type of testing that does not require the code to be executed is called STATIC TESTING.
- ii. Software QA is the short form for software quality assurance, and it involves running or checking software or code for bugs. Still, beyond discovering bugs, it also involves eliminating the discovered bugs and ensuring that the code conforms to industry-accepted standards. The endgame here is to deliver the best software product possible.
- iii. No. I wouldn’t say software testing and quality assurance are the same. Testing is all about checking for errors or bugs. At the same time, QA goes beyond just the errors to implement changes to the software that will eliminate the bugs and result in better user experience outcomes.
Disposing of the testing phase could result in losses and major damages, too, depending on the use case of the software. Some of the reasons why software testing is necessary includes;
- Software Testing and QA helps bugs which will result in customer satisfaction.
- A well-tested software will perform optimally in terms of how much time it takes to execute and how light (consuming less memory) the software gets to be released into the market.
- The most basic reason has got to be that this phase will help identity bugs that would have been created in the course of development.
- Testing can be used to prove the presence of a bug, and even when it seems like all the bugs have been found, it does not mean that the software is 100% bug-free. This leads me to the next principle that testing can never be exhaustive.
- Testing can never be exhaustive because this would mean testing all possible combinations of inputs and user behaviors with all types of devices across all possible locations. These numerous permutations and combinations would be difficult to implement as software projects usually have time budgets that have to be adhered to.
- The principle of software defect clustering suggests that the most errors are discovered in little clusters or modules. This is identical to the 80/20 rule, and comparing the 80/20 rule with the software defect clustering principle would mean that 80% of the defects or failures would be present in 20% of the code or software. This may not always be true in all cases for all software, but it is a pattern that industry experts have found to be prevalent over the years.
- The software testing principle referred to as the Pesticide paradox tries to establish a similarity between software and insects. In insects’ study, there is a particular phenomenon known as cross-resistance, in which the insects develop some form of resistance to a particular pesticide that has been used consistently over time to control insects or pests. The same thing is obtainable with software. When the same test scripts are repeated repeatedly, the type of bugs discoverable by such test scripts will no longer be available. To overcome this pesticide paradox, test scripts must be reviewed after a few test runs.
Software testing/QA is never exhaustive, but just like I said in question 3 above, there’s a limited time budget for QA activities, so the first criteria for exiting the testing/QA phase is time. Another reason to exit the QA phase would be when all of the test cases have been met. For every project, there is usually a test suite consisting of test cases. Once all of these test cases are met, the project team can decide to shut down testing.
Another reason for signing off on testing could be achieving a certain bug rate. For instance, a software project team could have an acceptable bug rate of 15%. This means that for every 200 test cases, errors/bugs should not be found in more than 30 test cases. In other words, 30 test cases or less returning positive for bugs are acceptable, and the team could exit testing if there are no major or high priority bugs to eliminate. Anything more than 30 test cases would mean more QA activities to eliminate the bugs.
The Waterfall model is the oldest and most basic software development model. It is also called the Sequential model as the flow of activities is unidirectional and flows from the top phase to the bottom, and as a result of this, the software will not be in working form up until the last stages of the SDLC. This unidirectional flow from the top to the bottom is why it is the “Waterfall Model.”
The phases of the model are; Requirement Analysis, System Design, Implementation, Testing, Deployment, and Maintenance. Between the Requirements Analysis and System Design, you get the Requirement Specifications, which will guide what the software is supposed to be designed to do. Between the System Design phase and Implementation, you get the Design Documents, which consists of designs using tools like wireframes, etc., to show a clear overview of the page structure and layout of the software, functionality, user flow, and intended behaviors. In between the Implementation and Testing phase, the fully developed software is obtained. This fully developed software is tested, and Quality Assurance is carried out before the deployment stage to ensure that the consumers get functional software with a minimum bug rate.
This model is simple to understand and implement and is usually very suitable for smaller projects. Still, unfortunately, it is difficult to go back to any phase to implement any changes once that phase is passed. This model is not suitable for complex and object-oriented software projects.
Both Walkthroughs and Code Reviews are static testing approaches in QA. Walkthroughs are similar to presentations, and in this case, the presenter is the developer/coder who wrote the code. This aims to detect errors, find alternative code implementations, assess the conformity of code to industry standards and user specifications, and any other QA aims. The code reviewed and other items like test plans, release notes, installation procedure, etc., are reviewed.
Code review is also referred to as peer review. And usually is of two forms, the formal and light-weight code reviews. The formal code reviews usually take on the formal form just like the name suggests, and it is quite detailed too. Developers from other teams would be involved in reviewing the code line by line, function after function. Generally, this is an extensive and exhaustive process. The lightweight code review is less formal and costs less. It could be of any of the following approaches: Email-threads, Pair-programming, Tool-assisted code review, etc.
Between 1985 to 1987, the Therac-25 radiation therapy machine malfunctioned. This resulted in some patient’s radiation overdoses in several multiples of what they needed, eventually leading to severe injuries and, in some extreme cases, death of the patients being treated. This challenge was due to what is described as RACE CONDITION, which is a form of a concurrent programming error, which happens when software is dependent on the timing of one or more uncontrollable processes to function well.
July 1962, mariner 1 was the first spacecraft in the American Mariner Program. The aircraft veered off course because of an error in computer software. The aircraft had to be shot down few seconds to when it would not have been possible to bring it down anymore. The post-flight investigation revealed that a hyphen was missing in the software that resulted in the transmission of incorrect signals.
- Build and Release: A build is a product handed over to the testing team for testing, while a release is a product handed over to the consumer for use.
- Bug Release and Bug Leakage: Bug release is when software is released with a bug to the testing team, and the software developer knows about this bug as at the time of release. While bug leakage is when a software version is released to the consumer and the bug is discovered by the end-user, and the QA team did not discover this bug in the course of testing.
- Retesting and Regression Testing: the QA team does retest to ensure that test cases that failed the last execution pass testing after the defect has been fixed. Regression testing is done to ensure that changes carried out during testing have not affected unchanged parts.
- Dynamic testing seeks to test the dynamic behavior of code by focusing on validation of the code. This is done by changing the values of the system and observing how it reacts to the changes.
- Equivalence Partitioning: This testing method seeks to reduce the number of input conditions to be tested to save time. The test input data is divided into groups called partitions or equivalence classes. They are called so because the computer is expected to react equivalently to every input data member of a certain partition.
- Boundary value analysis is also referred to as Range Checking. The difference between these two lies in how the test inputs are selected. In equivalent partitioning, input data is randomly selected from the test class, while boundary value analysis only takes two input values. These two input test values are the values at the extremes of the partition. In both Boundary value analysis and equivalence partitioning, if any input that is a member of a partition fails a test case, it is assumed that all the members of that partition would fail that test case.
As head of the QA unit, I would advise that automated testing be employed when the automation tool is compatible with the software under test or when there are more regression tests. Automated testing is also quite useful when the software to be tested is considerably stable in meeting functional requirements.