QA – determine the suitable Test Plan

Software testing can be accomplished while using verity of test types. QA engineer should use the relevant test type based both on the test cause and test target (you must understand the trigger for the testing request).

You can accomplish this task while answering on a few simple questions.

Q: Why we need to test?

Answer:

Before starting your tests you must understand the cause (why you need to perform these tests?)If you don’t understand it you have a major problem, in the next few lines I'll give few examples that may sharp my point.

Issues that may cause the need for Re-testing:  

1. New software that need to be tested from scratch
2. Patch that created for a specific customer
3. Bug found in code that need to be closed with specific test
4. New feature for existing software.
5. Performance issues found on customer environments.
6. Product validation before releasing it to customers.  
7. Retesting specific components after changes made in code.
8. Re testing based on new feature that doesn't relevant for our software but may cause risk with the integration.
9. Quick testing review for a new product.
10. Additional architecture that your software need to support.

As you can see,

Every answer can help you with your test selection, understanding the cause is crucial when taking decisions.

Q: What change in code?

Answer:

Understanding the code changes is crucial when need to design your test plan, please take in mind the next few points:

Scale of change in code – you can assume that bigger change in code will need much more adaption from the QA side .As a result  ,the test plan complexity and scale will be larger than specific change in code.

Affected components in software

Based on previous case, you must understand how the change in code affects the software components, you always need to remember that changes in code for specific component may affect other components; therefore we can describe 2 situations:

Direct influence on software – here you need to understand the influence of the change on the specific component that affected from it. If the change performed directly for component 1, you should understand the exact consequence for this component.

Indirect influence on software – after you deeply understand the influence on the direct area, you must think about the areas that called be affected from the change but not relevant for the actual change.

For example, if we have software with 4 components that depend on each other, every change in one of the component called affect the others, therefore you need to investigate and found any defects that may occur from this issue.