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:
- New software that need to be tested from scratch
- Patch that created for a specific customer
- Bug found in code that need to be closed with specific test
- New feature for existing software.
- Performance issues found on customer environments.
- Product validation before releasing it to customers.
- Retesting specific components after changes made in code.
- Re testing based on new feature that doesn't relevant for our software but may cause risk with the integration.
- Quick testing review for a new product.
- 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.
No comments:
Post a Comment