June 19, 2019 at 12:37Six ways testers can benefit (besides functional testing)
- Transfer
Salute! Next week, classes will begin in the new stream of the QA-specialist course , and in this connection we will share with you useful material translated specifically for students of the course. Go.
Functional testing remains valid even with the extensive implementation of automation. Many software products require manual testing to verify and examine all functions and their interactions.
Unfortunately, many testers conduct only functional testing, without going beyond it. The reasons for this may be lack of skills, inability to write code, fear of the unknown, or limited knowledge of the testing landscape.
To paraphrase Sam Kaner, software testing is the search for product quality information that can help stakeholders make informed decisions.
In addition to functional testing, there are other ways to find information. In this article, we’ll look at six ways that have helped me increase the effectiveness of my projects.
Testers usually study requirements documents, discuss them with stakeholders, and then develop tests. But we all know that there are scenarios that are not covered by test cases that appear while using the product. Most of them are covered by developers, but some may come as a surprise to everyone.
The development team can help by compiling a list of all messages that are in the product, including error messages, informational messages, and warnings. It will also serve as a good test coverage test in terms of messages displayed by the system. If testers have never seen a message that will be displayed to the user, then they should go back and understand in what cases this message will be displayed.
Once, having received a list of messages, I immediately noticed that a number of them were completely new to the testing team. After studying, we realized that they were from obsolete code and, although we no longer supported this functionality, they were in the source code. This code should have been removed since it no longer affected the product.
Depending on the architecture of the application, preparing such a list can be easy or difficult. But if you think this exercise will help the tester team test better, then stakeholders should agree to find a way to prepare a list of messages. Try this approach and check how well you know your product and what your test coverage is.
Many product teams release the first versions very quickly, and then think about stabilizing the code after reaching a certain number of customers or according to other indicators. Initial quick releases usually take precedence over doing the right releases. But as more and more developers get involved, there is a high probability of inconsistency.
In the process of stabilizing the product, focus on getting rid of any UX inconsistencies. Perform a UX review of the entire application. Start with icons, text, actions, functions, and main threads. Use characters and brainstorm for a full UX review. Also think about touchpoints for users. How do you deal with them? Is there anything misleading in your application? There are exercises at https://cantunsee.space that will help you test your UI skills.
When we made an UX review of one of the actively used products of our company, we found inconsistency patterns and could easily associate them with various decisions that we made as a team, releasing features in a hurry, outsourcing development to another team, releasing features with outdated plugins etc.
It is a pity that many testers work in isolation and have no idea about the products of other companies. Examine your competitors with advertising information, webinars, demos, news in the media and blogs, and then write down features and analyze the strengths and weaknesses of your product.
Ask your product teams if you can access other companies' offers and ask how you can help competitor analysis. In addition to analyzing functionality, also consider criteria such as usability, performance, security, and availability. It is useful to make a comparative table “functionality - evaluation criteria” with the points that the products scored.
Tools are good for those who know how to use them effectively. They can save a lot of money and time and greatly complement testing. As a tester, you must have extensive knowledge of the systems used and the processes used.
In addition to automating functional checks and quickly creating test data, there are also tools for detecting patterns in logs, for replicating data from production, for simulating functions, for recording user actions and for responding to events based on rules. Also, to achieve most of the final goals, there is no need to buy proprietary tools. It can be a simple program with hundreds of lines that takes a screenshot of an application based on a trigger in the log.
Sometimes it’s not obvious to everyone how useful these or other tools are until you demonstrate what benefits they can bring, so study their capabilities.
As described in Elizabeth Hendrickson's book Explore It! Reduce Risk and Increase Confidence with Exploratory Testing ”, one way to prevent a disaster is to think about the possible headlines for bad news related to your product or project and test these risks. Testers are good at thinking about possible accident scenarios, and this skill can help the development team avoid mistakes when writing code, saving time and effort in advance.
This can be a fun game to play with multiple stakeholders, and it will give everyone confidence that they will take care of the risks. When we played this game with one of our teams, some of the headlines invented by the technical support and management gave us a different point of view - without this we would never have thought about these tests.
Due to the continued use of their product, the testing team may be biased. And what seems to testers as expected behavior, in fact, may be inconvenient for users. You can examine support calls to find out about customer pain and problems using your application.
Once we complained about the feature of one of our products and the convenience of its use, but this was not accepted as a bug. Although when several clients began to deal with similar usability problems, this was fixed with a high priority. This incident has given us great authority in the organization. And later we were invited to take part in numerous discussions about usability solutions.
Customer voice is real data that you should pay attention to, and you can use this data to contribute to the development of your product.
These six methods are easily combined with functional testing and are of great benefit. Try them in your testing work and tell us about your experience.
That's all. We look forward to your comments and invite you to an open day, which will be held on June 21.
Summary: Many testers conduct only functional testing, without going beyond it. But software testing is the search for product quality information that can help stakeholders make informed decisions, and there are many ways to find information beyond functional testing. This article describes six methods that can help you improve the effectiveness of your projects.
Functional testing remains valid even with the extensive implementation of automation. Many software products require manual testing to verify and examine all functions and their interactions.
Unfortunately, many testers conduct only functional testing, without going beyond it. The reasons for this may be lack of skills, inability to write code, fear of the unknown, or limited knowledge of the testing landscape.
To paraphrase Sam Kaner, software testing is the search for product quality information that can help stakeholders make informed decisions.
In addition to functional testing, there are other ways to find information. In this article, we’ll look at six ways that have helped me increase the effectiveness of my projects.
1. Examine all messages
Testers usually study requirements documents, discuss them with stakeholders, and then develop tests. But we all know that there are scenarios that are not covered by test cases that appear while using the product. Most of them are covered by developers, but some may come as a surprise to everyone.
The development team can help by compiling a list of all messages that are in the product, including error messages, informational messages, and warnings. It will also serve as a good test coverage test in terms of messages displayed by the system. If testers have never seen a message that will be displayed to the user, then they should go back and understand in what cases this message will be displayed.
Once, having received a list of messages, I immediately noticed that a number of them were completely new to the testing team. After studying, we realized that they were from obsolete code and, although we no longer supported this functionality, they were in the source code. This code should have been removed since it no longer affected the product.
Depending on the architecture of the application, preparing such a list can be easy or difficult. But if you think this exercise will help the tester team test better, then stakeholders should agree to find a way to prepare a list of messages. Try this approach and check how well you know your product and what your test coverage is.
2. Do a UX Review
Many product teams release the first versions very quickly, and then think about stabilizing the code after reaching a certain number of customers or according to other indicators. Initial quick releases usually take precedence over doing the right releases. But as more and more developers get involved, there is a high probability of inconsistency.
In the process of stabilizing the product, focus on getting rid of any UX inconsistencies. Perform a UX review of the entire application. Start with icons, text, actions, functions, and main threads. Use characters and brainstorm for a full UX review. Also think about touchpoints for users. How do you deal with them? Is there anything misleading in your application? There are exercises at https://cantunsee.space that will help you test your UI skills.
When we made an UX review of one of the actively used products of our company, we found inconsistency patterns and could easily associate them with various decisions that we made as a team, releasing features in a hurry, outsourcing development to another team, releasing features with outdated plugins etc.
3. Conduct competitor analysis
It is a pity that many testers work in isolation and have no idea about the products of other companies. Examine your competitors with advertising information, webinars, demos, news in the media and blogs, and then write down features and analyze the strengths and weaknesses of your product.
Ask your product teams if you can access other companies' offers and ask how you can help competitor analysis. In addition to analyzing functionality, also consider criteria such as usability, performance, security, and availability. It is useful to make a comparative table “functionality - evaluation criteria” with the points that the products scored.
4. Explore tools
Tools are good for those who know how to use them effectively. They can save a lot of money and time and greatly complement testing. As a tester, you must have extensive knowledge of the systems used and the processes used.
In addition to automating functional checks and quickly creating test data, there are also tools for detecting patterns in logs, for replicating data from production, for simulating functions, for recording user actions and for responding to events based on rules. Also, to achieve most of the final goals, there is no need to buy proprietary tools. It can be a simple program with hundreds of lines that takes a screenshot of an application based on a trigger in the log.
Sometimes it’s not obvious to everyone how useful these or other tools are until you demonstrate what benefits they can bring, so study their capabilities.
5. Think about the risks that could become a “nightmare”
As described in Elizabeth Hendrickson's book Explore It! Reduce Risk and Increase Confidence with Exploratory Testing ”, one way to prevent a disaster is to think about the possible headlines for bad news related to your product or project and test these risks. Testers are good at thinking about possible accident scenarios, and this skill can help the development team avoid mistakes when writing code, saving time and effort in advance.
This can be a fun game to play with multiple stakeholders, and it will give everyone confidence that they will take care of the risks. When we played this game with one of our teams, some of the headlines invented by the technical support and management gave us a different point of view - without this we would never have thought about these tests.
6. Spend time with customer support
Due to the continued use of their product, the testing team may be biased. And what seems to testers as expected behavior, in fact, may be inconvenient for users. You can examine support calls to find out about customer pain and problems using your application.
Once we complained about the feature of one of our products and the convenience of its use, but this was not accepted as a bug. Although when several clients began to deal with similar usability problems, this was fixed with a high priority. This incident has given us great authority in the organization. And later we were invited to take part in numerous discussions about usability solutions.
Customer voice is real data that you should pay attention to, and you can use this data to contribute to the development of your product.
These six methods are easily combined with functional testing and are of great benefit. Try them in your testing work and tell us about your experience.
That's all. We look forward to your comments and invite you to an open day, which will be held on June 21.