| Q1. In Which phase of software Life Cycle Testing should be done? Earlier testing was done after the build and execution phases(which is still being followed in many organizations). But the earlier we catch a defect, the more cost effective it is. For instance, fixing a defect in maintenance is ten times more costly than fixing it during execution.Testing should occur in conjunction with each phase. In the requirement phase |
We can also review the design document from the architecture and the correctness perspectives. A testers biggest strength is in finding the Design Gaps , that's why a Tester should have good domain knowledge.
In the build and execution phase we can execute unit test cases and generate structural and functional data.
And finally in testing phase we run the system test cases and see if the system works according to the requirements. During installation we need to see if the system is compatible with the software. Finally, during the maintenance phase when any fixes are made we can retest the fixes and follow the regression testing.
Q2. Which area has more defects: Design or coding?
The design phase is more error prone than the execution phase.
The best example and the most frequent defects which occur during design is that the product does not cover the complete requirements of the customer.
Second is wrong or bad architecture and technical decisions make the next phase, execution, more prone to defects. Because the design phase drives the execution phase it’s the most critical phase to test. The testing of the design phase can be done by good review.
On average, 60% of defects occur during design and 40% during the execution phase, because coding will be done on the basis of design only.
Q3. when can we properly start the testing?
Testing can be started properly after getting the proper inputs from the Client or the End user we would require following data:
The first thing we need is the acceptance test plan from the end user. The acceptance test defines the entire test which the product has to pass so that it can go into production.
We also need the requirement document from the customer. In normal scenarios the customer never writes a formal document until he is really sure of his requirements. But at some point the customer should sign saying yes this is what he wants. Never make a test plan without a proper sign off.
The customer should also define the risky sections of the project. The customer is the right person to say which things can really impact its business
With this feedback the testers can prepare a proper test plan for those areas and test it thoroughly.
The customer should also provide proper data for testing. Feeding proper data during testing is very important. In many scenarios testers key in wrong data and expect results which are of no interest to the customer.
Q4. 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 exact set 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.
Q5. How Defect removal at different stages impact 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.
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.
Q6. What is a workbench?
A Workbench is a way of documenting how a specific activity has to be performed. A workbench is referred to as phases, steps, and tasks There are five tasks for every workbench:
Projects are not made of one workbench but of many connected workbenches. A workbench gives you a way to perform any kind of task with proper testing. You can visualize every software phase as a workbench with execute and check steps.
Requirement phase workbench: The input is the customer’s requirements;
we execute the task of writing a requirement document, we check if the
requirement document addresses all the customer needs, and the output is
the requirement document.
Design phase workbench: The input is the requirement document, we
execute the task of preparing a technical document; review/check is done
to see if the design document is technically correct and addresses all the
requirements mentioned in the requirement document, and the output is
the technical document.
Execution phase workbench: This is the actual execution of the project. The
input is the technical document; the execution is nothing but implementation/
coding according to the technical document, and the output of this phase is
the implementation/source code.
Testing phase workbench: This is the testing phase of the project. The
input is the source code which needs to be tested; the execution is executing
the test case and the output is the test results.
Deployment phase workbench: This is the deployment phase. There are
two inputs for this phase: one is the source code which needs to be deployed
and that is dependent on the test results. The output of this project is that
the customer gets the product which he can now start using.
Maintenance phase workbench: The input to this phase is the deployment
results, execution is implementing change requests from the end customer,
the check part is nothing but running regression testing after every change
request implementation, and the output is a new release after every change
request execution.
Q6. What is the difference between Alpha and Beta testing?
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.
Where as 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.
Q7. What is defect cascading?
Defect cascading is a defect which is caused by another defect. One defect
triggers the other defect.
Important Software Testing Interview Questions: Part 1
No comments:
Post a Comment