How can a tester create added value?
“In any moment of decision, the best thing you can do is the right thing. The next best thing is to do a little more than necessary. The worst thing you can do is nothing”. -Theodore Roosevelt
If we interpret the same idea in software testing, "as much as necessary" here equates to testing, debugging, and compliance - all of which are already very demanding tasks. "Do a little more than necessary" is all that goes beyond the above.
The primary responsibility of the tester could be defined as the delivery of a quality product with as few defects as possible to the product owner within various constraints, such as deadline, budget and team. To achieve this, the tester can contribute on a much broader scale than just matching the development.
The following recommendations are based on my personal experience. They may vary depending on the project, the composition of the product owner and development team, and the size of the project.
These practical tricks could help a novice tester who wants to start somewhere and be more than just the "last step of Dante's hell" in the software development process, as one developer jokingly once formulated testing :)
Two-dimensional testing
Two-dimensional testing: based on requirements and ideas. As the fixed project volume also places limitations on testing, the priority is always to try to achieve compliance, but this does not prevent the tester from writing down all his ideas about improving the quality of the product.
For example, if in analysis and design, loading is attached to the content with a "load more" button, but if the content that is loaded by the end-user is in hundreds, the tester may suggest adding pagination instead of a "load more" button.
Since the creation of an entirely new component is not written in a "scope" of a project, such proposals can be stored separately as ideas.
It could be in a separate document, which is presented to the product owner at the end of a phase. By subtracting requirements and ideas in this way, it is possible to stay in the budget for fixed-volume projects, while offering added value to the client.
Errors
Error and error correction reporting instead of error reporting. The mistake I have made repeatedly is that in the context of non-functional testing (e.g. usability testing, accessibility testing), I have provided a description of the error, but have not included how to fix it or provided an example of a working component.
For example, if developed breadcrumbs are not keyboard accessible, don't have a focus indicator, and don't contain link elements. In this case, the description of how the element should behave, plus a code example and a reference to a working example, saves a lot of time. In other words, a bug description only through negation is never a sufficient input to the developer to correct the bug.
Automated regression tests
Automated regression tests help free up time for other activities. Regression tests are probably the “dullest” part of testing, as their job is to repeat tests that have already been created, thereby detecting errors that a new snippet of code can cause.
Manually "chipping" the same tests over and over again is hugely time-consuming. Instead, the tester should create new tests and move forward in the process. There is no project where time is not a critical factor, especially in agile models, and thus any automation that helps to save time should constantly be in the tester's focus.
Test data and environment management
The test environment should allow all development parties - both the developer and the product owner's team - to quickly and conveniently access the full scope, content and information of the development. In essence, this means that relevant data has been created, linked to specific users and covering the maximum possible scope for development.
All this information is easy to find, and the corresponding links are written down, accessible and updated in the project documentation (preferably in the cloud).
Suppose a UX designer, product owner, or analyst wants to see specific content developed at an earlier stage, created with the maximum possible data. In this case, he can find it independently with the help of the documentation and does not depend on the rest of the development team.
Both the transfer of the necessary test data into the test environment and the creation of documentation should be the task of the tester, as he or she will already create the relevant data when testing compliance.
A weak tester
A weak tester is better than an experienced non-empathetic tester. "Weak" in this context means a tester who is not yet very technical, who doesn't yet have five years of experience as a tester, who is not very well versed in different database languages or software development processes, and who asks a lot of "silly questions".
Are these characteristics beneficial, and can they make a tester empathetic?
One of the most critical skills of a tester is the ability to see the product from the end user's perspective and a clean page. To be able to do this, it is better to be "weak" and not know everything that goes on behind the scenes of software development.
Perhaps it’s also good not to be able to explain all the shortcomings, i.e. how something works or why it works or does not work, and to be at the level of demand and need for someone who knows nothing about software development.
In other words, the end-users should never be considered as capable as the development team. Therefore "silly questions" must be asked boldly in the development and analysis phase - the better and more daring the tester is and is, thus, able to ask "silly" questions.
Agile tester
In agile development, the tester is also agile. In essence, this means that the tester plans his time so that he does not become a bottleneck in scrum-type projects.
To avoid this, he works in the same time window as the rest of the team and does not start testing when he has time off from other projects and activities.
Also, to increase the speed of "debugging", the tester will report any errors found following the error reporting recommendation above.
The tester also tests the quality of the development process
This task may also be part of the Quality Assurance Specialist's field of work, but in compact teams, this role is often missing, and as the last link in the development team, the tester has the best overview of the entire development process.
If the design views are too sketchy and do not contain real information, don't cover individual cases, or are not versioned - in agile development, a single file, which is a design file, is overwritten repeatedly.
It almost always causes development errors. Or, if the requirements lack proper user stories, are out of date, or are open to various interpretations, this usually also leads to development errors. It happens even if the developer selects a ready-made component; in the end, it still does not quite fit into a particular solution.
The value-added task of the tester is to analyze the errors and causes of development and to draw attention to them. Of course, static testing also makes a clear contribution here, but it cannot replace fully drawn conclusions or analysis, which can only be done after the development phase. There is no part of the process that cannot be made more efficient. Quality consists of the quality of each role separately and the quality of teamwork collectively.
In conclusion, the tester can definitely add value to the software development process by only wanting to contribute a little more than necessary. Tester and QA can help to create better, more stable products if they focus on prevention and optimizing the workflow from the kickoff of every project.
We hope you found the article we wrote helpful in putting testing into practice in your company. Try out these tasks in your testing work and let us know your experiences.
