Agile test procedures in Waterscrum + Staging Enviroment

Question

Currently, I am working in several teams at the same time. The project teams work in Waterscrum and have defined an agile sprint of - one-week development + one week testing.

All teams work with each other, but on different projects that are interlinked again.

Some teams don't have a staging environment yet, and therefore don't use test procedures that are based on the normal agile staging procedure. Currently, only functional tests are used within the team. Neither direct integration tests nor unit tests are an issue.

But because exactly this topic, Unit Test, is to be solved, my task is now defined. So far everything has always worked well in normal environments, but here the external factors are defined fundamentally different.

But there are the following to unsolvable factors:

• Unittest should be made mandatory for everyone. Instruction of the stakeholder and the customer assigned to him.
• All teams should introduce unit testing in the staging procedure and plan accordingly via agile planning.
• A unittest test environment is to be used for all teams.
• Until now, each team had its own definition of Ready and Done.
• A global team-wide definition of Ready and Done would be urgently needed to solve competence problems.

Questions:

• How can I build a single Unittest platform that can be used by all project teams?
• Based on the Waterscrum principle?
• Based on the Staging Prinzig. How can I define a Global Definition of Ready and Done so that it is accepted by all teams on the new Unitetst procedure? Previous approaches

• In order to also use static test procedures in the staging area, I introduced Sonarqube accordingly with the developers. The problem of code quality, between the teams within the staging environment, was an unsolvable problem.

• In the next step, we want to use the Unittest procedure to recognize our problem factors faster and more effectively at an early stage.

Do you have one or more ideas or hints on how to tackle these problems? The question is consciously based on itself, so that one can better understand these connections.

Answer 1

There are a few challenges to the situation that you are raising. First, there is no official thing called waterscrum, so there are no rules for doing it. Generally, Waterscrum or WaterScrumfall are derogatory terms referring to poor Scrum practice. Therefor, we should be approaching each quality practice in the context of their value by themselves, not their place in a broader approach.

Next, your process splits development and testing into two separate activities and I presume two separate groups of people. Then you are trying to layer in concepts that rely on those activities to be combined - particularly definition of done and unit testing.

In most agile approaches, there is an assumption (derived from lean) that you want to build quality in rather than checking for it later. Both of the above practices have the goal of doing this. The definition of done established a standard intended to promote a particular level of quality of any product and the team is expected to apply whatever skills necessary to build an increment of the product that reaches that needed level of quality. The problem you describe is not necessarily uncommon. However, the solution is straight-forward. You gather the teams together (or trusted representatives of the teams) to define the minimum definition of done for the whole product that stretch across teams (though individual teams are always welcome to be more stringent).

Unit testing and TDD are common techniques used by developers to ensure code quality at the lowest level of code. Generally, these practices lead to less aberrant code logic and difficult-to-find edge cases and also help alleviate the burden of high-level testing. Using a single platform may or may not be possible or practical depending on your application. The best people to answer this would be the developers. It's worth noting that even if it is possible, it may not be desirable if the value gained from different platforms is greater than the effort that goes into maintaining them. Again, allowing this to emerge from the teams is traditionally the best way to approach this problem.

To circle back, the core challenge you are facing does not appear to be a technical one. Rather, you are trying to mix a traditional approach that insists on controls and an agile approach that insist on relinquishing control and challenging teams to find their own way (either individually or as a collective) to meet the quality standards required by your product.