Site Overlay

Hacks: Testing with no requirements

Shift left, grooming sessions, or using development processes such as BDD: working with clear, agreed requirements is a blessing in Software Quality Assurance, and already a good sign of quality. The reality, however, is that most of the organizations actually need us to help them reach that ideal state, meanwhile we still deliver some things in the old-fashioned way: ambiguous User Stories with empty Jira tickets. Start-ups want to move fast, adding new features day after day, while prehistoric companies tend to realize too late they need to work on something: in this article I’m not going to preach the importance of quality requirements for the success of an IT project, but I’ll rather tackle how can one cope with the situation, meanwhile working on the change management of it.

So, imagine you are in either of the above stated situations, and:

  • You don’t really know the software product you should be testing
  • You find a lot of defects but since you’re not intimate yet with the software, you don’t know which ones are the most relevant
  • You’re trying to plant the seed of clear, agreed requirements, but you don’t have time to water it because of the speed of development
  • You’re the only QA in the project, or even in the whole company
  • You realize the increments are breaking trivial functionalities, slowly degrading the quality of the software
  • You want to automate it all and the only way of doing that is cloning yourself, twice
  • Generally, most of your time is spent on detection activities, rather than prevention
  • Everyone agrees things should be done differently. When it comes to actually doing, people are missing the shot of courage

Even though “What am I doing here?” would naturally come to one’s mind, take a deep breath. There’s more of us out there! Although I always say that you need to have some level of insanity to work in QA, here’s some hacks that help me control the madness and achieve my goals at the end of the day:

  • Always start by asking what are the main business goals of the new feature/change/bug fix. This helps you to focus your efforts on the areas which are more likely to have a higher impact on business, and even helps you to prioritize efforts between many of them.
  • Make a standard Test Plan / Test Guide that can help you tackle the most basic Test Cases for standard tickets. Share that with everyone. Ask devs to help you: maybe they can automate some parts?
  • Combine the above with some Exploratory Testing.
  • Treat the previous state of the system as the main reference point. Obviously if something can’t be reproduced on the immediate previous version, it’s a freshly baked defect.
  • Raise all your findings. Order them based on the first item in this list.
  • Use your second screen: Open your application in debug, open the database, check your logs in real time, inspect the network in the browser. Look at all the information you can to inspire for more tests.
  • Start small with automation: Automate simple flows to help you and the team with the basics. 
  • Use the traditional way of breaking the system to learn about its flaws and to gain knowledge and credibility inside the team
  • Never lose hope: use the knowledge and the credibility you gain and coach your stakeholders to decide for quality in the moments of failure (which, by the way, are natural to come if we encounter ourselves in situations like this one, even though we might do our best!).

It’s true that in QA we might be facing challenging times depending on the project and how well requirements are defined for those projects, however this shouldn’t stop us to lose focus from doing what QA is mainly hired for: fight the challenges standing in the way of quality. The rest are tools, methodologies or philosophies we believe in, which we should definitely work towards. Getting there means rolling up our sleeves, apply some hacks and getting our hands dirty.

PS: Another great way of learning how to cope with this is getting in touch with your local QA Community: network and learn what others are doing to make things work in similar situations!