Software applications are complex, with real-time communication taking place among several components. Databases, APIs, servers and even hardware devices work together to give a seamless end-user experience.
For applications that have already been developed and deployed to production, testers already know the features that are historically important and where to focus their testing efforts. But if you are building a brand-new application with not much documentation and no historical data, how do you know what features to test? These five tips can help in such scenarios.
1. Start with the things you know
Before a new application is developed, the stakeholders already have a general idea about the expectations for the product. Based on their research from existing users, usability testing, and the business goals and vision for the company, they know the type of application that needs to be built for their customers.
This is a good place to start designing a test strategy. Interview the stakeholders and try to get as much information as you can about the product. This also extends to developers, business folks and technical leads who can give different perspectives on the application. All this gathered information can help you understand the functionalities of the application, the expectations of the user, the critical modules to be tested, and the timelines within which testing needs to be complete and the product has to be released.
If there is any documentation or resources that could help along the way, use this to your advantage too. These could include legal documents, help documents, business plans and high-level requirements.
2. Do competitor research
A great way to learn about your application is to do competitor research. For example, say you are developing a travel booking application. You can use other apps like Expedia, Kayak and Orbitz for reference and see how your application works compared to them.
You can observe how much memory those apps consume in relation to yours, the different flows of the travel booking process, the different modules present in the application, and critical paths the user can take from start to finish. Document these observations and use them as a guide to test your application.
Solve Your Testing Challenges
Test management tool for QA & development
3. Adopt an agile methodology
If your company decides to follow an agile process such as Scrum, XP or kanban, then testers should know what to test based on user stories. Each iteration has a set of user stories that have to be developed and tested within a set timeframe. The features to be tested can be uncovered from the user stories, and the order in which the stories are played helps to prioritize the testing efforts.
It’s important to consider the amount of testing effort that goes into a story. Some stories may need less effort compared to others. For example, a story for the font size of a page changing from 15-point to 16 may need less testing than a story dealing with implementing a new payment functionality for the application. There is high risk and impact if the latter feature does not work as expected, so more testing effort has to be dedicated to it.
4. Try various testing approaches
There are several testing approaches that can help in learning the application and prioritizing the modules to be tested. Two helpful approaches for new applications are session-based exploratory testing and risk-based testing.
Session-based exploratory testing
These are time-boxed testing sessions focused on testing a particular module for a certain amount of time. This method can be used within any domain, project or application when you want to get quick feedback about the application instead of writing detailed test cases, like in scripted testing. These sessions give you more flexibility in exploring the product, and you get to use creativity within the boundaries of the goal of the session.
All session notes are recorded in a charter document, including details such as the goal of the session, the necessary resources used in the session, task breakdowns containing the time spent on performing different tasks during the session, test ideas and observations, issues uncovered during the session, and any screenshots (if necessary).
Performing these sessions is simultaneous learning and execution, which gives a better idea about the product features. You’ll uncover bugs that would be otherwise hard to find using scripted or automated testing, as well as identify high-risk areas and tasks that are time-consuming and could be good candidates for automation.
Testing based on risk helps to ensure the focus is more on high-impact and critical areas.
For example, say you are testing two stories. Story A is for implementing a new video player for streaming movies, and story B are to ensure the help documents related to the video player open up in a separate browser tab when clicked. If story A does not work as expected, it has a high impact on the customer and business. If story B does not work as expected, although it still would be an issue, it is likely the customer would not even notice and business would not be affected.
Given this context, if you have two days to test the above stories, it does not make sense to spend one day on each. Instead, you would dedicate about a day and a half on story A, as it is higher risk, and half a day or less on story B. This is where risk-based testing helps: by ensuring testers are giving the right amount of focus and effort to higher-risk modules.
To determine which modules have more risk, teams would conduct a formal risk analysis. This usually consists of identifying different risks associated with a module and assigning different business and technical scores to them. Totaling up the risk scores helps to prioritize the testing effort.
5. Rely on past experiences
If you’re tasked with testing a brand-new application without much documentation or information about the product, don’t feel lost. The above strategies can help anyone get started with focused testing and doing more exploration.
All-in-one Test Automation
Cross-Technology | Cross-Device | Cross-Platform