Read also: Is your Project ‘Business As Usual’?
As Quality Assurance professionals, many times we used to talk about this term BAU (Business As Usual) Testing. Many of us know exactly what it is, but yet because of the jargon BAU, we may tend to think it is something else. In a typical software life cycle model of Define-Design-Code-Test-Deploy-Maintain-Retire, most of us pre-dominantly get involved in "Test" phase. In our project organization models, whenever we celebrate the success of software "Go Live" junctures, we leave few of our team members at the project location stating as production support team. Exactly what they are going to do after the deployment of the software application is called BAU Testing. In this article, we can understand about the development support teams as well. Let's discuss what our production support team is usually doing as part of their process.
Business-As-Usual (BAU) Testing
After successful implementation of the tested software applications in the production environment, there are different reasons to make changes in the applications
1. Defects found in Production: There will be defects identified in these during the day-to-day operations. Defects that are leaked into production environment due to inadequate test coverage or inconsistent configuration management of code. Also there will be some latent defects which are hidden and not possible to find during the few cycles of testing. Example: defects due to data type overflow for a variable declared in integer for a counter, say number of transactions in the bank account.
2. Enhancements: While these applications are in use, users come up with new requests to enhance the features either for ease of use or to get better results. Based on the criticality, these enhancements will be prioritised and approved for development.
3. Technology Upgrades: There might be a necessity to upgrade to a latest technology due to various reasons. Example: Improve performance, Support compatibility to new technologies / devices, Increase storage, Ease of use etc.
Operating systems, Databases, middleware and software applications may be upgraded or replaced. In most of these occasions, data migration also involved. So testing requirements also high.
4. Regulatory Changes: Almost all the industries are transforming at a quicker pace and needs regulatory interventions to streamline them. So they impose new requirements to industry players. Many of them has to reflect in the core business applications.
BAU Testing Process
1. In a process oriented business environment, all the above defects / changes will be logged in a centralised tool / tracker by a dedicated team.
2. These defects / changes will be sent to a change control board or approving authority to decide the need for implementing the change, priority and the deadline for implementation etc.
3. Once the change / defect is approved, then the development team will estimate the effort for their development and unit testing.
4. In a similar way, testing team will provide their effort estimate for their system testing and integration testing. Generally this will involve a quick template based estimation for test design, comprehensive test execution and regression. Every change / set of changes will be treated as a separate projects which require a brief test plan and closure report as well.
5. Acceptance Test estimates will be provided by the user group who are responsible for User Acceptance.
6. Once all the effort estimation are completed and agreed, development of the change / fixing of the defect will be carried out by the development team. They are responsible for Unit testing as well. In many places, testing teams will insist on the submission of test evidences for the unit testing as a process. When there is a centralised test management tool, the evidences will the be attached in it.
7. Once the development team promotes the change to the testing environment, it will be tested by the testing team and any defects found will be raised to development team for fixing.
8. Once the defects identified by the testing team are fixed by the development team, these defects will be retested and a regression would be carried out by the testing team to confirm that the defects are closed appropriately and no impacts are created due to the change.
9. A similar testing with business scenarios will be done by the User Acceptance team to give a go ahead to promote the code to the production.
10. Once the UAT closure report is signed off, code will be promoted to production by the release team. At each stage the code will be maintained in a configuration management tool with appropriate versions.
Defect Leakage: In each stage if a defect is not identified and identified by the next team, it is known as defect leakage. Defect leakage is a key metric in BAU testing and a contentious topic between teams. For example, if a defect related to a change is identified by UAT team which was missed by SIT team, it is called defect leakage. Sometimes, both SIT & UAT teams might miss some defects which will be identified in production by the operations users. This scenario will be more damaging to the entire testing process.
Advantages of being in a BAU Testing team
1. Learning on the domain and the business processes will be enormous as a small testing team has to take care of almost all the changes.
2. Projects are very streamlined as they are properly estimated and prioritized. So the work load will be uniform and not with steep spikes.
Please write share your experience in a BAU Testing projects in comments.
