Traditional Software Testing
When working with a traditional methodology, the software testing stage occurs at the end of the process. Often there are strict delivery times already established. There are a million reasons why time runs short in the process and QA engineers are left with little time to run tests, disrupting all of the planning that was originally decided at the beginning of the project.
When this happens, QA engineers can start to feel desperate and can get sucked into a cycle of endless daily work. Is this the only way to work? No!
Tips for Managing Hurried Testing
Before talking about specific tips for managing hurried software testing, it is worth mentioning that there are a lot of ways you can avoid this situation, or at least mitigate it. Nevertheless, we’ll go ahead and list some corrective actions you can take when you find yourself under the gun and facing deadlines.
The first thing you should know is the relation Scope–Cost-Time (SCT) that occurs in all software projects. If time is short in one factor, then one of the other two factors must change in order to compensate.
Adding New Resources
Understanding the previous point, one aspect that needs to be taken into account is the project context, and whether new resources can be added to the project. New resources can help you accomplish your tasks in the previously established timeline. There may also be the possibility of paying overtime to the existing resources. If possible, this could be an easy solution.
However, remembering our SCT relation, more resources involves more expenses, which might not be viable. Additionally, it doesn’t always help to add new people you fulfill your tasks on time. In fact, new resources could even be counterproductive, considering learning curves and overlapping tasks.
Therefore, if we can’t change the cost, then we are left with adjusting the scope. How do we go about this? Changing the scope means choosing not to test something, which can lead to a lot of critical errors in production.
An alternative would be to identify the most important test cases that will guarantee the correct function of the system. In order to successfully execute this plan, you should take into account the 80/20 rule or well known as the Pareto’s rule. It means that you can identify the 20% of functionality that is normally used for the 80% of your typical users. Testing on this way you can ensure that 80% of the typical users won’t have errors using the application but just testing only the 20% of the functionality of the application.
First, you identify the reduced case set that will allow for maximum coverage, which is called MAT (minimal acceptance testing). Other test cases might not generate as much value, for example those that test to see if the cursor changes when hovering over an actionable button.
Even if this solution is executed correctly, you could find errors later in the process, however these errors shouldn’t be critical or significantly affect the project delivery or a big quantity of users.
We have named some examples of things you can do to get through this situation. There are other solutions that could work better, depending on the project. That is why understanding the project functions is crucial in order to know which solution to take. You just need to remember the SCT relation, which should always be respected so that the whole QA team doesn’t suffer adverse effects on quality.
Lastly, remember that you can always ask for more time, even if that isn’t the PM’s favorite solution.
If you are looking for a software partner who will work towards your own business goals and success, then Avantica is your solution. We offer dedicated teams, team augmentation, and individual projects to our clients, and are constantly looking for the best methodologies in order to give you the best results.
Let’s start a project together