In software development, quite often quality assurance engineers must perform quality assurance without precisely described requirements. Verifying the outcome without an outline of requirements is not the easiest thing to do, particularly for inexperienced developers. So, what’s the best way to handle this challenge?
First, remember the most important rule of testing and software quality assurance – the sooner a defect, error, crash, or other malfunction is detected, the cheaper it’s going to be to fix. This is true from both the client’s or end user’s point of view, as well as from the developer’s perspective.
Let’s consider four ways of gathering the needed information, prior testing, to provide a high-quality product and make sure that all participants in the process are satisfied even when we lack clear requirements.
- The client
- The team
- Experience
- Combined approach
Client
The most reliable way to obtain information about an application is from the client and it doesn’t matter who conceptualized the product idea. Maybe the ideator is on the other side of the world; maybe they’re working on the marketing team of an Ecommerce company, or perhaps they are the CEO of a small startup. It doesn’t matter where the idea came from; the most important thing is to satisfy the client.
Team
The next option is to construct a team. The team might be located on-premise, or it might be a remote team working in various parts of the world. We may have access only to QA Lead/Manager. Nevertheless, let’s describe three groups of people who can help you:
Project Manager, Business Analyst, Product Owner – Under ideal conditions, these people are the primary source of information. Often they have enough information to describe what the result should look like.
- QA Engineers – If the team already has other QA engineers, you’re lucky. They can safely tell you in which direction to move, the purpose of the work, the goals the client would like to achieve, and ideal testing approaches.
- Developers & Designers – When there’s no manager or when they have a day off, we might be the only ones working on a project on a given day. When this is the case, it’s a good option to ask for help from developers or designers who worked on the part we need to check. It is most likely that they know the reason the piece of work in question was implemented. If they don’t know, the chances of defects and errors are pretty high. It’s easy to see how entire team awareness of application work is fundamental for success and customer satisfaction.
Experience
Sometimes there’s no one to ask at all. Either there is no one nearby, everyone is out, or we’re freelancers who work for ourselves. In these cases, we have to utilize experience.
- Internal/Own Experience – In these cases, we try to apply all the knowledge and skills we have accumulated to achieve the expected result. We can turn inward and ask ourselves, “How would I use this?” “Would it be convenient, comfortable, and understandable for me to use this?”
- External Experience – The other option is using everything around us. Googling, reading articles, asking questions, installing similar applications, visiting related websites, and analyzing competitors or partners. Finding answers from external sources is all about exploring and investigating. By comparing the product we are working on with what was completed by someone else, we use the experience of others who have developed something similar
**Lifehack**
By analyzing similar products, we can also read reviews and look for other pieces of information. Perhaps users of a related product are unhappy with specific functionality, and our client is unaware of potential issues. As quality engineers, our mission is not just to test, but to achieve the highest possible quality. Therefore, when appropriate, we need to make professional suggestions and warn clients of potential problems.
Combined Approach
Finally, we often must use all the above approaches. The best results will occur when we can adapt, be flexible and agile. Commonly, we must acquire information any way we can and combine this information to identify the best routes to take. Successful quality engineering recognizes that there is no perfect recipe and the skill to adapt is incredibly valuable in today’s market.
Conclusion
This article is not intended to provide specific directions as to which test design techniques should be used. Instead, the article’s purpose is to encourage ways to be the most productive and produce the highest quality products, even when we are missing very critical pieces of information. Software quality assurance is not easy when clear requirements are lacking, but there are still paths leading to successful outcomes.
