17. What are different types of verifications?
Verification is static type of s/w testing. It means code is not executed. The product is evaluated by going through the code. Types of verification are:
Walkthrough: Walkthroughs are informal, initiated by the author of the s/w product to a colleague for assistance in locating defects or suggestions for improvements. They are usually unplanned. Author explains the product; colleague comes out with observations and author notes down relevant points and takes corrective actions.
Inspection: Inspection is a thorough word-by-word checking of a software product with the intention of Locating defects, Confirming traceability of relevant requirements etc.
18. How do test documents in a project span across the software development lifecycle?
The following figure shows pictorially how test documents span across the software development lifecycle. The following discusses the specific testing documents in the lifecycle:
Central/Project test plan: This is the main test plan which outlines the complete test strategy of the software project. This document should be prepared before the start of the project and is used until the end of the software development lifecycle.
Acceptance test plan: This test plan is normally prepared with the end customer. This document commences during the requirement phase and is completed at final delivery.
System test plan: This test plan starts during the design phase and proceeds until the end of the project.
Integration and unit test plan: Both of these test plans start during the execution phase and continue until the final delivery.
19. Which test cases are written first: white boxes or black boxes?
Normally black box test cases are written first and white box test cases later. In order to write black box test cases we need the requirement document and, design or project plan. All these documents are easily available at the initial start of the project. White box test cases cannot be started in the initial phase of the project because they need more architecture clarity which is not available at the start of the project. So normally white box test cases are written after black box test cases are written.
Black box test cases do not require system understanding but white box testing needs more structural understanding. And structural understanding is clearer i00n the later part of project, i.e., while executing or designing. For black box testing you need to only analyze from the functional perspective which is easily available from a simple requirement document.
20. Explain Unit Testing, Integration Tests, System Testing and Acceptance Testing?
Unit testing – Testing performed on a single, stand-alone module or unit of code.
Integration Tests – Testing performed on groups of modules to ensure that data and control are passed properly between modules.
System testing – Testing a predetermined combination of tests that, when executed successfully meets requirements.
Acceptance testing – Testing to ensure that the system meets the needs of the organization and the end user or customer (i.e., validates that the right system was built).
21. What is a test log?
The IEEE Std. 829-1998 defines a test log as a chronological record of relevant details about the execution of test cases. It’s a detailed view of activity and events given in chronological manner.
22. Can you explain requirement traceability and its importance?
In most organizations testing only starts after the execution/coding phase of the project. But if the organization wants to really benefit from testing, then testers should get involved right from the requirement phase.
If the tester gets involved right from the requirement phase then requirement traceability is one of the important reports that can detail what kind of test coverage the test cases have.
23. What does entry and exit criteria mean in a project?
Entry and exit criteria are a must for the success of any project. If you do not know 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 provide the requirement document or acceptance plan. If this entry criteria is 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 in projects is that the customer has successfully executed the acceptance test plan.
24. What is the difference between verification and validation?
Verification is a review without actually executing the process while validation is checking the product with actual execution. For instance, code review and syntax check is verification while actually running the product and checking the results is validation.
25. What is the difference between latent and masked defects?
A latent defect is an existing defect that has not yet caused a failure because the sets of conditions were never met.
A 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.
26. Can you explain calibration?
It includes tracing the accuracy of the devices used in the production, development and testing. Devices used must be maintained and calibrated to ensure that it is working in good order.
27. What’s the difference between alpha and beta testing?
Alpha and beta testing has different meanings to different people. Alpha testing is the acceptance testing done at the development site. Some organizations have a different visualization of alpha testing. They consider alpha testing as testing which is conducted on early, unstable versions 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.
28. How does testing affect risk?
A risk is a condition that can result in a loss. Risk can only be controlled in different scenarios but not eliminated completely. A defect normally converts to a risk.
29. What is coverage and what are the different types of coverage techniques?
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.
30. A defect which could have been removed during the initial stage is removed in a later stage. How does this affect cost?
If a defect is known at the initial stage then it should be removed during that stage/phase itself rather than at some later stage. It’s a recorded fact that if a defect is delayed for later phases it proves more costly. The following figure shows how a defect is costly as the phases move forward. 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 during the requirement and design phases.
For instance, if a defect is identified during requirement and design we only need to change the documentation, but if identified during the maintenance phase we not only need to fix the defect, but also change our test plans, do regression testing, and change all documentation. 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.
