We assume that the process of producing software at your company takes place with cross-functional teams of developers, testers, a Product Owner or Manager, with the team supported by a Scrum Master.
As a CEO, CTO, CPO, or SM, your job is to constantly try to understand and implement practices which will have a favorable impact on the quality of the software or your product.
Analyzing their suggestions, many testing specialists do not go beyond their complex academic language when explaining the complexity of the software manufacturing process. Their papers are often quite lengthy, full of various classifications. We understand that many readers search for recommendations ready to use and to implement.
You may be surprised to learn that usually there are two or three reasons behind many testing problems and we propose to start diagnosing them in the following ways.
A bad specification or overlooking it during work
One of the most frequent mistakes teams make is having an unclear specification or lacking one, resulting in tester uncertainty as to whether the app or function operates correctly. It is estimated that 75% of all project problems result from a bad specification and its subsequent bad management.
It is difficult to optimize developers and testers when functional and non-functional fields are not clearly defined.
Moreover, the Product Owner must precisely describe this functionality and the tasks must be clear for the entire team. Following these practices ensures that the “ticket” has been “delivered” in accordance with the requirements. If during the testing many errors are reported, including a lot of documentation ones, then the best course of action should be to precisely reformulate the requirements and repeat the implementation.
Sprint Planning does not include testing
One of the four processes in Scrum where the Product Backlog’s task list is viewed and estimated, Sprint Planning provides the best opportunity to once again discuss every task as we want all team members to understand them in the same way.
It has been our experience that, from the point of view of a tester, many problems start with Sprint Planning. It is important that developers and testers understand the purpose of Sprint. Therefore, why is it that so many testers may still be disoriented? First of all, an estimated task may exclude the opinions of testers, leaving them no opportunity to have input during the testing, which could improve executing all of the tasks during Sprint.
Secondly, the beginning of a new Sprint often requires testers to be self-organized. For example, if in the current Sprint the testers do not catch-up on the works, they may work for instance on automatic tests, resulting in a problem that hinders their self-organization, which is sometimes so important.
Thirdly and lastly, Sprint Planning includes only tasks of similar complex and difficult executions, resulting in testers starting to work on most of the tasks at once, creating a so-called bottleneck. The problem compounds itself as tasks defined as “large” (high measurement of complexity) are commissioned for testing in Sprint at the last moment, impacting negatively the quality of their testing.
It is also worthy to remember that Sprint should take various tasks into consideration depending on their complexity or story points and thanks to this, the testing work during Sprint is usually divided relatively evenly. By regularly commissioning testing tasks, the team will detect errors more proficiently and locate their sources more expediently.
The developer is not a tester
Even if developers ask critical questions about the product, just like professional testers, a question arises: Can developers build a product and at the same time catalog errors of a software they created? Such a practice could be considered a conflict of interests.
Of course, test-driven development and unit tests constitute an answer to this often expected dual-functionality of a developer. In accordance with the good practices of Agile, successful projects are those which include members possessing a wide range of complementary skills.
Testers organize their work in accordance with the software’s specifications just like developers, but often, they use different tools. Starting with product validation verifying whether the product meets all of its specifications, the team ensures there will be no errors.
Then the tester verifies whether the product works in accordance with its usage in various scenarios, that it can perform automated regression tests, and that it is going to execute performance test scripts, and it includes creating a viable testing environment.
We recommend friendly and informal overviews of the code by developer teams, especially if there are some junior members just starting their careers. Implementing this practice will eliminate many unnecessary errors even before a tester begins.
How to start solving these three problems?
Imagine a triangle or an iceberg. At the base you have the three basic problems: Specification, Sprint Planning, and a Developer working as a tester. The top stands for “not executing the project”.
Because we divide the problems related to the software and the testing into a multitude of smaller and more manageable problems, we begin to focus on the top of the iceberg.
In the past, perhaps, you came across the following situations: a tester was forced to make shortcuts, the tester’s work was poorly estimated, the dominating approach was to solve malfunctions later, Sprint Planning touched upon testing issues insufficiently, tasks were too large and delivered for testing at the last moment, or the specification was either unclear or not present.
Are there divisions and tensions within in your team and therefore you are unsure as to where and how to implement the changes?
In order to handle and solve many of the software testing problems we have showcased, we hope that our recommendations will be helpful and will save your teams much time and effort.