Whenever there is something big coming at you, there is always a fear to get past it. This happens more often in the software industry, especially when you are a QA professional. However, there is nothing to be scared of.
While you are in this profession, you might miss something that can make your boss yell at you. If not, at least you would be answerable for many awkward questions thrown at you. You might not be able to defend yourself immediately; however, the answer could vary depending upon the situation and the actual reason behind the miss. In either of the case, you must not estrange yourself completely and put the entire blame on the developers.
But, if you have really done something crazy or missed an issue, you must be prepared to accept it and take the blame. However, you would definitely want that this never happens to you again.
Testing has a trite of not testing the only thing that can break production. This can be related to your real life incidence, where your keys are placed in the last place you look. In testing, such cases appear in areas that you would have never thought of testing or anyone would not have tested. You might think of attempting to test every user situation, which might not be possible in practical.
With the advanced technology and broader understanding, many modern testers know the gravity of short SDLCs in an agile development process. However, this requires a risk based testing. The role of a tester here is to minimize the issues due to risk while moving into the production phase. Any move made by the technology directors to achieve things faster could prove to be costly. Moreover, it won’t be a great idea to involve more QA; however, the testers must prioritize things to perform quick testing.
At least, the tester must ensure the fulfillment of all requirements as well as the software, which should work to accomplish business needs. However, this must not be the end of your testing scope or one should not recline by just testing the happy path.
Initially, you are the one who knows the software completely, but a new user can do things that they are not supposed to do. Here, exploratory testing holds immense importance to ensure everything is in the right place. But, how far down you can go?
Risk Based Testing
As mentioned above, the extent of exploratory testing can go far beyond till an exaggerated situation. You must recognize the key areas and situations that are more likely to repeat. This would help in reducing the time spent in testing, and the saved time can be utilized in accelerating the development cycle.
Risk based testing revolves around this ideology, and why not? With short SDLCs being critical to business, this appears to be the most feasible approach for QA. It requires you to first note down the important function of the change and the test scenarios based on that, then analyze the risk involved and finally plan and prioritize your testing.
The change that has been made should be purposeful and must be followed by smart and efficiently prioritized exploratory testing of the areas that are more likely to create issues.
There are many key factors involved in performing risk based testing. Some of them are mentioned below.
- Adequate knowledge of your systems
- Good understanding of the possible paths
- Familiarity with the points around the function
- Interaction with the application
This would help in identifying and isolating the key areas for testing. However, you would not be able to cover the entire thing, as already discussed. In fact, it’s very unrealistic. But with planned and executed risk you can at least be quick.
