While developing a product one comes across many situations in which a person needs to take decisions which might present all alternatives which seem wrong or all alternatives which seem
correct. In case of such tough decisions, one has to be guided by some best practices which can
help him to solve this problem if not present a readymade solution to the problem.
The best practices can categorized into broad categories:
1) 10 must haves for a Quality Engineer.
2) Four things which any professional or entrepreneur cannot afford to forget.
The best practices of a Quality Engineer ensure that quality of the final product is ensured.
1. Know the technology
In the area of software development, technology is changing rapidly. What is new trend today
may become obsolete tomorrow. In this fast changing world a tester should keep abreast with
the latest in the technology world. A Tester should know what technology is being used for
developing applications. He should know the supporting technology associated with OS. This
will make sure that the tester will find bugs at the early stage, thus reducing the price for the fixing of bugs. Also, studying the technology helps study the competitor better and thus helping your product to have a good standing in the market. Studying the technology would also help the Quality Engineer to understand the workflow and the product better.
2. Learn from past experiences
Before writing the test plan and the test cases, QE should try to scan data from past projects,
which are similar in nature. This may give them some better test cases, issues that were
identified in the end of the cycle, some areas that could be automated. If the application is extension of earlier project, high priority and severity bugs should be regressed for current version of application.
3. Ensure sufficient coverage of feature workflow
The key to success of the testing effort is that when a customer uses the product, he/she
should be able to seamlessly use it. This kind of seamless experience can only be ensured if the
common user workflows have been tested thoroughly. The challenge here is that different users
use different features and in fact might even use the same feature in a different way. Here is
where the role of sufficient coverage comes in.
Coverage can broadly be classified into two categories:
a) Coverage of different functionalities present in the software
The software performs a series of tasks. However the usage of these tasks may vary depending
on the requirement of the customer. Once the possible workflows have been identified, one needs to prioritize the workflows depending upon the number of users who would use the particular feature.
b) Coverage of the different routes while going through the workflow of the software
Common functionalities can be accomplished in many different ways in most software. E.g. in
order to copy a text in Microsoft Word application, one can use the keyboard shortcut Ctrl+C, or
right click on the selected text and select copy. One can also use the edit menu to do the same.
Each of these three routes is important because a user can copy text using any of these. As a
Tester, one needs to find all possible routes of accomplishing a task. After the routes have been
Identified, Quality Engineer needs to see how much probable are these in a real world scenario.
Also study of usage of this feature in comparison to other features needs to be done. As for our
example, we need to know how much common it is for the user to use the ‘copy’ feature in
comparison to other features like ‘find’, ‘replace’, ‘cut’ etc.
4. Make a matrix for hardware to be supported by application (and prioritize the hardware)
Many applications support different configurations of hardware. A proper matrix ensures that application is working on important configuration of hardware.
5. Assign two QEs (primary and secondary)
An application has multiple features. There should be two QE assigned to a feature. The
QE can be assigned as primary QE and secondary QE. Primary QE is responsible for creating
test plan, test cases, setting test environment, executing testing, reporting bug and regression of
bugs. Secondary QE can work as a back up. He can be involved for reviewing test plan and
script, helping primary QE in setting up testing environment, executing some part of test cases at different interval and in regression of bugs. This will help in getting control of bug myopia (blindness to a bug if working for a long time in testing a feature).
....... to be continued
2 comments:
are yaar tell me 1 thing that dont u think so dat 2 qe are some thing more \over??
@nielkanth:
Assigning 2 QE's depends on the feature. If the feature is very small, then just a single QE is enough. But if the feature is quite big enough, then there are chances of bugs being missed by a QE. Moreover, the primary QE of one feature can be secondary QE of other feature, thereby balancing the resources.
Ex:
Feature1 - Primary QE - Adam(Tester1)
Feature1 - Sec QE - Leman(Tester2)
Feature2 - Primary QE - Leman(Tester2)
Feature2 - Sec QE - Adam(Tester1)
The advantage of this is that: Since QE's are also humans, they are bound to commit mistakes and bugs may slip. The second QE might be able to figure out the slippage and hence reduce the bugs.
Post a Comment