Quality analyst is a high risk, low rewards role of any project. Nobody says that product is of top quality due to QA. On the other hand everybody pounces upon the QA team when the issues are found while using the application.
The waterfall model had given an advantage to QA team to ensure that the product would not launch before it was well tested and gets their approval. This power of right to reject given to QA team empowered the management in delivering well tested products. It ensured that the builds shared with stakeholders meet minimum expectations. It ensured that app is developed thoroughly and provided the scope for the maneuvering of analysts within application to harden sections of the applications.
However, the agile approach removes this biggest cushion from QA team. During the development phase, the team is at the mercy of the dev team to get the build. The sprints can’t be altered frequently. Even when the build is shared with the team on time, if there are issues which must be fixed, then the build with those fixes needs to be tested THOROUGHLY.
As a delivery manager, I saw this conversation happening frequently within my team.
There are no specifics, because, frankly, that’s what manager wants. But how do we get from this point to a point where we could share a build with confidence?
Divide and Conquer
The traditional approach of testing has a test case document where each test case is associated with a module and submodule.
However the problem arises when some the basic functionality of the application does not work after making the last minute changes. The traditional approach of testing fails to handle it as it carries too much baggage of test cases. There are just too many test cases to care.
Can we reduce the test cases? Yes, but that would be compromising thoroughness of the testing. Our unique solution helps us to age old method of limiting the battles by dividing the things to be tested on multiple parameters and using them effectively for assuring quality in the ever changing requirements and continuous modifications in code.
Modules and submodules
In the new approach, we continue to write the test cases according to modules and submodules. Modules or components are the major building blocks of applications where the functionalities can be demarcated.
The good testers have great intuition of where to look for in every situation, whether they are given a very small amount of time or enough time to test the entire application. A manager can ensure that the test cases are written to cover the entire application and to capture minutest details. The manager also breaks the application into modules and submodules to help every team member to prepare the plans centered around the modules.
Agility can’t be achieved with strong and heavy armors!
We prepare the test case documents to ensure the quality. However, when it comes to sharing a build in agile model, the test case document becomes a heavy armor which you have to throw away. The sheer number of test cases enforces the manager to take a step back and evaluate the strategy of using it during agile process.
Adapt to the changes
Instead of going with an approach of All or None (of the test cases), we find a middle ground by putting things in perspective. We create a test case document which must be adaptive. Which means, the test case document should perform the following things:
- It should be up-to-date for the use cases
- If the time to test and code changes are known, it should be able to give a set of test cases.
Keeping these things in mind, we started setting priorities to each test case:
- Highest: no matter when you share the app, this must be tested. These are the core features of the app at their highest level.
- High: For a module to be called functional, these test cases must work for that module. It ensures the module level compliance
- Medium: these are the usual test cases which we often come across. Validations, special requirements, must have things etc.
- Low: These are the lowest priority items and may not be checked often. Basically, regression to these issues may not be visible until we perform the complete run of the test case document.
How does this change anything?
The first thing a QA has to do in the morning is to update the test-case document and update the issues fixed from previous day. This ensures that the document is always up-to-date.
We at Mobisoft, use these parameters to ensure that the app is being tested thoroughly. During the weekly builds, on the day of the build, QA might test only the high priority items from recent changes and highest priority of the application. During the rest of the week, everyday, QA plans some module+submodule+priority combination by collaborating with the Manager and Developers. It ensures that all the testing being done is well planned and documented.
Tags
We have also introduced tags column in test case document to ensure cross module dependency. It is often seen that the changes in one module affect the changes in other module but they do not get captured at all in the test case document. Having tags to link dependency between modules helps capture that information. The tags can be SYNC, NFC, Push Notifications, chat, image upload etc… This helps the QA to test all the modules with similar functionality when the code is copied to multiple places leading to issues at multiple locations.
Summary
Using the priority fields, tags and daily updation of test cases, we ensure that the builds are tested to the specification and overall build quality is maintained throughout the duration of the project.
It helps us restrict the changes, testing to limited areas, and effectively perform bug control operations consistently.
Engagement Managers from the client team being in possession of these documents and reports, can also feel confident about their apps and report to their authorities with better accuracy.
In the end it helps Mobisoft achieve the goal of transparency, agility and effectiveness with reduced efforts.
Author’s Bio
Hemant Shinde works as a Solutions Engineer at Mobisoft Infotech. He likes to add scalability and availability to mobile applications. He has 8+ years of experience in systems engineering, virtualization and cloud based systems. Apart from that, he has interest in history, e-commerce, Internet of Things and loves traveling.
