Serverless is a highly trending term in the world of software architecture right now and one can judge this from the many references of the term in journals, products, and open s...
By: Shripad Khairnar | April 18, 2017
It is real hard to comment at what point the testing should be denoted as enough testing. It’s even more difficult to predict that the product is defect free post your deliberate testing attempts. However, RBT has proven a way to grab optimum consequences on the testing results.
Being in the testing team on any complex project, you must brainstorm within all the relevant stakeholders while asking the WH questions.
- WHEN is the right time to implement RBT on your project?
- WHICH all critical business scenarios, modules that need to be attended on priority?
- WHAT all steps/approaches that you would like to overlay to succeed?
- WHERE would you focus to find more critical defects?
- WHO you are while testing the application?
- WHY team harmony is very essential while implementing RBT on the project?
- HOW would you determine the success of your RBT efforts on the project?
WHEN…is the right time to implement RBT on your project?
Do you anticipate any possible situation/s on your project/s from the list below? If yes – your project is a right candidate and for sure, it’s high time that you choose implementing RBT to enhance project success and expect better outcomes.
- Scarcity of either or all resources – viz: time, manpower, money
- Anticipating late QA build/s arrivals to Testing Team and Go Live date is still unaltered
- Expecting to detect the critical defects earlier on the project execution
- Worried about the business loss if the critical functionality is not tested in time
- In addition to all above challenges, you do not want to compromise on the quality of testing deliverables
WHICH… all critical business scenarios, modules that need to be attended on priority?
You may want to grab the list of modules, functions that need to be considered as a top priority testing items while treating them as risks. You must spend enough time for this phase of RBT implementation on your project.
- You identify business scenarios where failure of modules; functions become a show stopper & a big loss on the business front.
- You take a note of frequently and heavily used areas of the application under test.
- You may want to beat the complex areas of your system.
WHAT… all steps/approaches that you would like to overlay to succeed?
The entire testing team needs to be in war room to streamline the RBT approach once all the prioritised items have been identified.
- Allocate the complexity to all the identified business scenarios (e.g Simple, medium, high, complex)
- Identify the probability of event occurrence and its impact to allocate the weightage.
- Define the effort estimate and duration to address the risk.
- Allocate the set of test cases/scripts to test the identified risk.
- Identify the resources needed to address the risk.
WHERE… would you focus to find more critical defects?
To achieve better handle on defect finding coverage within RBT approach, you may want to follow a few guidelines while handling the different testing options on the project.
- Static Testing – this is to double check by inspecting areas which are identified and considered as a high risk.
- Review Test Artefacts – the relevant test stakeholders need to review the test plan, test cases and a test estimate document to ensure the correctness.
- Re-testing – this is cross check if the failed scenarios work properly when a new build is in place.
- Different testing types viz, System, Regression testing results would yield the outcomes that enables to supply relevant information to required folks.
- Exit criteria – this is a test completion criteria when met, the testing team can consider the testing for a specific risk item on the prioritized list as accomplished.
WHO… you are while testing the application?
Right people on the right tasks can achieve expected results. Testing team needs to involve all the relevant stakeholders while implementing the RBT on their project. You need to know the very basic fact that…
- Tester is to provide the information which in turn enables the management to take accurate decision, Go-No Go.
- Testers do not create software nor do they create defect therein.
- Testers just judge the risks on the project and share their results as to which all risks have been addressed so far and which all other risks are still lingering in the application.
- However, in some situations testers do play a catalyst role in suggesting the appropriate steps that help management teams to take decisions.
WHY… team harmony is very essential while implementing RBT on the project?
As commented earlier, there is a need of high collaboration and coordination among the teams when we want to implement RBT. Inputs from all the relevant stakeholder becomes a goldmine.
- Business Analyst needs to own the RBT from requirements elicitation through to completion of detailed design and guide testing teams.
- Test/Project Manager must be informed of all the information as he is the owner of the risk assessment results and he must ensure smooth execution further
- Test Analyst team needs to have thorough understanding from the business and domain perspective
HOW… would you determine the success of your RBT efforts on the project?
A risk-based testing approach addresses the size and complexity parameters of a regression testing suite in a methodical manner. You can measure the success by capturing the various metrics on the RBT implementation
- Forcing the test cases prioritization by clearly defining importance of a functionality or feature – metrics: the number of test cases planned, executed and completed
- Encouraging impact assessment to identify the likelihood of failure, thus addressing the testability of a requirement – metrics: the number of defect per function, the number of hours used in testing per defect found.
- Improving testing effectiveness by ensuring testing of all critical functionalities, which are used most often – metrics: Total number of defects found and number of hours used in fixing per defect
At the end, we all as a team need to realise a few facts that – victory of RBT implementation is dependent on number of factors like senior stakeholder buy-in; robust Risk-Based Assessment; effective testing processes and the key factor is communication to all relevant roles.