Basics of Software Testing

Q. Why do we need testing?
Ans. Software development involves ambiguity, assumptions and flawed human communication.
Each change made to a piece of software, each new piece of functionality, each attempt to fix a defect, introduces the possibility of error. With each error, the risk that the software will not fulfil its intended purpose increases.
Testing reduces that risk.

We can use QA processes in an attempt to prevent defects from entering software but the only thing we can do to reduce the number of errors already present is to test it. By following a cycle of testing and rectification we can identify issues and resolve them.
Testing also helps us quantify the risk in an untried piece of software.
After modifications have been made, a piece of software can be run in a controlled environment and its behaviour observed. This provides evidence which informs the decision to move to the
next phase of the project or to attempt to rectify the problem.
And finally in some software development efforts, testing can actually be used to drive development. By following statistical models of software development and methods such as usability testing, software development can move from an unfocused artistic endeavour to a structured discipline.

Q. What is a requirement and how is it different from a specification?
Ans. This is important for a candidate to know since a lot of issues that arise during the testing phase come about because of deficient requirements and specifications. The following is a good explanation:

Requirements are gathered from the customer who indicates what their needs are. These needs are then translated into specifications which are the blueprint for specifications for the development team.

Q. What is the difference between use case, test case, test plan, and scenario?
Ans. Use Case: Use case is prepared by BA in the System Requirement Specification (SRS) which are nothing but a steps which are given by the customer.
Test Case: It is prepared by the Test Engineer based on the use cases from SRS to check the functionality of an application thoroughly.
Test Plan: Test plan is prepared by TeamLead, it represents the Scope of the test What to test and What not to test Scheduling What to test using automation etc.
Scenario: Scenarios are prepared in Load testing, complete one business flow, and It is a brief description of an event or a series of events or It is a hypothetical story used to help a person think through a complex problem or system.

Q. What does a Test Case include?
Ans. A Test Case includes Test Case ID, Steps Description, Expected Output, Actual Output, Pass/Fail, Remarks.

Q. What is difference between bug, error and defect?
Ans. Bug and defect essentially mean the same. It is the flaw in a component or system, which can cause the component or system to fail to perform its required function. If a bug or defect is encountered during the execution phase of the software development, it can cause the component or the system to fail. On the other hand, an error is a human error, which gives rise to incorrect result. You may want to know about, how to log a bug (defect), contents of a bug, bug life cycle, and bug and statuses used during a bug life cycle, which help you in understanding the terms bug and defect better.

Q. What is the difference between the severity of a bug and the priority of a bug?
Ans. A priority is based on how urgently the bug needs to be fixed. The factors to consider are what else needs to be fixed, and how important is this bug relative to the others. A severity measures the impact of the bug on the application. How much damage can be caused to the integrity of the data in the system if the bug causes an incident?

Q. What is the difference between unit testing and integrated testing?
Ans. A developer will perform unit testing on the modules they have changed independently of each other. Integrated testing involves testing the system as a whole with all the changed modules combined. It is an end-to-end testing of the application in a real-world simulated environment.

Q. Define black box testing and white box testing?
Ans. Black Box testing involves some form of data that is input into a process and the validation of the output. A tester cannot see inside the process. They can only see the output. White Box testing allows a tester to look inside the process and validate the data before, during, and after processing but prior to the output. Validation steps on the process may be necessary in white box testing.

Q. What is a test case and a test case walkthrough?
Ans. A test describes the input to a test. This can include the data, the screen that will be used and the parameters that may drive the test. It will describe the steps necessary to execute the test case. It will describe the output and the results that are to be expected. It may include manipulation of the input data to test the particular case. A Test Case Walkthrough is a review of the test case by Testing Peers. It can highlight steps that may have been missed or test cases that may have been missed.

Q. What is automated testing?
Ans. A large project or system can involve hundreds of test cases. An automated tool can be used to record actions from a transaction. This may include menu choices, buttons and clicks. These tests can be initiated and performed much faster than manual tests. Whenever a change is made to the source code, the test can be rerun and the logged results can be verified to the expected results.

Q. When is a decision table used?
Ans. A decision table is used to help testers simplify the documentation of test cases when there are a lot of combinations of different inputs that must be used to test business rules.

Q. What is portability testing?
Ans. This testing refers to the practice of moving and testing an application on different platforms. For example, an application may require testing on different windows operating systems. The time involved and the challenges that occur should be documented as part of testing results including instability and adaptability.

Q. What is the difference between functional and non-functional testing?
Ans. Non-functional testing includes test cases that validate security log ons, performance and testing of disk and memory space. Functional testing includes the testing of the actual functions that the end user will be using, including transactions and reports.

Q. Can you explain PDCA cycle and where does testing fit?
Ans. Software testing is an important part of software development process. In normal software development below are the four important steps and also referred in short as the PDCA cycle.

PLAN -> Do -> CHECK -> ACT, Then ACT ->DO...repeats the same cycle again

Plan: - Define your goal and the plan of how you will achieve that goal.
Do / Execute: - Depending on the plan strategy decided during the plan stage we do execution accordingly in this phase.
Check: - Check / Test to make sure that we are moving according to plan and we are getting the desired results.
Act: - During the check cycle if any issues are there then take appropriate action accordingly and revise your plan again.

Q. What is the difference between Defect and Failure?
Ans. When a defect reaches the end customer it is termed as failure and if the defect is detected internally and resolved it’s called as a defect.

Q. Define different categories of defect?
Ans. Wrong: - The requirements have been implemented incorrectly. This defect is a variance from the given specification.
Missing: - There is a requirement given by the customer and is not done. This is a variance from specification, an indication that the specification was not implemented, or a requirement of the customer was noted properly.
Extra: - A requirement incorporated into the product that was not given by the end customer. This is always a variance from specifications, but may be an attribute desired by the user of the product. However, it is considered a defect because it’s a variance from the existing requirements.

Q. Difference between Verification and Validation?
Ans. In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and that it fulfils its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development life cycle.
Validation: Are we building the right product?
Verification: Are we building the product right?
Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements.
Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

Q. What is Usability testing?
Ans. Usability testing can quantitatively and qualitatively test the usability of a new design, prototype or specific interaction. There are a number of usability testing methodologies that can extend to testing with smaller participants or testing with hundreds of users through a remote usability test. Equally the research practice also provides collaborative design testing during the course of a design phase, which means that design decisions can be tested on a weekly basis rather than at the end of a project.

Benefit: Usability testing highlights pain points in an interaction that is supported by evidence by the end user target group.

Risk: The outcomes of a usability study need to be considered and acted upon. Time needs to be made within the design phase to implement and fix issues. Critically, if a card sorting exercise (which helps with the development of content hierarchy) is not conducted, usability can raise IA or copy issues that may be too late to change. So if time allows conduct a card sorting exercise or test usability as early as possible. Two weeks lead time is required by the experience team to starting the recruitment process and kick-off the study.

Q. What is the difference between Latent and Masked Defect?
Ans. Latent defect is an existing defect that has not yet caused a failure just because the exact set of conditions has never been met.
Masked defect is an existing defect that hasn't yet caused a failure, just because another defect has prevented that part of the code from being executed.

Q. A defect which could have been removed during initial stage is removed in later stage how does it affect cost?
Ans. If a defect is known at the initial stage then it should be removed during that stage / phase itself rather than doing it some later stages. It’s a recorded fact that if a defect is delayed for later phases are proven more costly. Below figure shows how a defect is costly as the phase moves ahead. A defect if identified and removed during the requirement and design phase is the most cost effective, while a defect removed during maintenance is 20 times costlier than requirement and design phases. For instance if a defect is identified during requirement and design we only need to change documentation , but if identified during the maintenance we not only need to fix the defect , but also change our test plans , do regression testing and change all documentation for the same. This is why a defect should be identified / removed in earlier phases and the testing department should be involved right from the requirement phase and not after the execution phase.

Q. In testing can you explain the concept of work bench?
Ans. Work bench is a way of documenting how a specific activity has to be performed.
There are four sections for every work bench:-
Input: - Every task needs some defined input and entrance criteria. So for every work bench we need defined inputs. Input forms the first steps of the work bench.
Execute: - This is the main task of the work bench which will transform the input in to expected output.
Check: - Check steps assure that the output after execution meets the desired result.
Production output: - If the check is right Production output forms the exit criteria of the workbench.
Rework: - During the check step if the output is not as desired then we need to again start from the execute step.

Q. What’s the difference between Alpha and Beta testing?
Ans. Alpha and Beta testing means different for different people. Alpha testing is the acceptance testing done at the development site. Some organizations have a bit different visualization of Alpha testing. They consider alpha testing as a testing which is conducted on early, unstable version of software. On the contrary Beta testing is acceptance testing conducted at the customer end. In short the difference between Beta testing and Alpha testing is the location where the tests are done.

Q. What is coverage and what are the different types of coverage techniques?
Ans. Coverage is a measurement used in software testing to describe the degree to which the source code is tested. There are three basic types of coverage techniques as shown in the following figure:
• Statement coverage: This coverage ensures that each line of source code has been executed and tested.
• Decision coverage: This coverage ensures that every decision (true/false) in the source code has been executed and tested.
• Path coverage: In this coverage we ensure that every possible route through a given part of code is executed and tested.

Q. Can you explain how one defect leads to other defects?
Ans. Defect Cascading is a defect which is caused by other defect. So one defect triggers other defect. For instance in the accounting application below there is one defect called negative taxation. So the negative taxation defect affects the Ledger which in turn affects four other modules.

Q. What is the difference between Pilot and Beta testing?
Ans. The difference between Pilot and Beta testing is that Pilot is nothing but actually using the product (only that it is limited to some users) and in Beta testing we do not input real data, but it’s installed at the end customer to validate if the product can be used in production.

Q. What does entry and exit criteria mean in a project?
Ans. Entry and exit criteria are a must for the success of any project. If you do not know from where to start and where to finish then your goals are not clear. By defining exit and entry criteria you define your boundaries. For instance you can define entry criteria that the customer should give the requirement document or acceptance plan. If these entry criteria’s are not met then you will not start the project. On the other end you can also define exit criteria for your project. For instance one of the common exit criteria’s in all project is that customer has successfully executed all the Acceptance Test plan.

Q. On what basis is the Acceptance plan prepared?
Ans. In any project Acceptance document is normally prepared using the following inputs.
This can vary from company to company and from project to project.
• Requirement document: - This document specifies what exactly is needed in the project from the customer perspective.
• Input from customer: - This can be discussions, informal talks, emails etc.
• Project plan: - Project plan prepared by the project manager also serves as a good input to finalize your acceptance test.

Q. What’s the relation between environment reality and test phases?
Ans. Environment reality becomes more important as test phases start moving ahead. For instance during unit testing you need the environment to be least real , but at the acceptance phase you should have a 100 % real environment , or we can say it should be the real environment. Below graph shows how with every phase the environment reality should also increase and finally during acceptance it should be to the maximum.

Q. Can you explain regression testing and confirmation testing?
Ans. Regression testing is meant for regression defects. Regression defects are defects due to which the functionality which was working first normally has stopped working. This is probably because of changes made in the program or the environment. To uncover such kind of defect regression testing is conducted.

If we fix a defect in an existing application we use confirmation testing to test if the defect is removed. It’s very much possible because of this defect or changes to the application it can affect other sections of the application. So to ensure that no other section is affected we can use regression testing to confirm the same.

Q. What is configuration management?
Ans. Configuration management is a detailed recording and updating information for hardware and software components. When we say components it does not only mean source code. It can be tracking of changes for software documents like requirement, design, test cases etc.

When changes are done in ADHOC and uncontrolled manner more chaotic situations arise and more defects are injected. So whenever changes are done it should be done in a controlled fashion and with proper versioning. At any moment of time we should be able to revert back to the old version. The main intention of Configuration management is that we can track our changes back if we have issues with the current system. Configuration management is done by using baselines.

Q. Can you explain the concept of baseline in software development?
Ans. Base lines are logical ends in a software development cycle. For instance let’s say you have software whose releases which will be done in phases i.e. Phase 1, Phase 2 etc. So you can base line your software product after every phase. In this way you will now be able to track the difference between Phase 1 and Phase 2.

Q. What different impact rating’s you have used in your project?
Ans. Normally impact rating for defects is classified in to three types:-
• Minor: - Very low impact but does not affect operations on large scale.
• Major: - Affects operations on a very large scale.
• Critical: - Brings the system to halt and complete show stopper.

Q. Can you explain what a test log is?
Ans. The test log as a chronological record of relevant details about the execution of test cases. It’s a detail view of activity and events in a chronological manner.
Add Comments :
    Software Testing, Second Edition provides practical insight into the world of software testing and quality assurance. Learn how to find problems in any computer program, how to plan an effective test approach and how to tell when software is ready for release. Software Testing (2nd Edition)