0

Details:

I wanted to ask if anyone has experience with the role of the classic software tester in Scrum ?

Information My personal experience is that in the first days there is not much to do for software testers (of course this does not mean that they do nothing, there are also general tasks in the QA department, create test environment, update test cases and write new ones, etc.).

The first days of the Sprint are usually spent writing User Stories. These are then converted into solution specs and the implementation can begin. The software tester has little to do at the beginning, he starts to review and comment the specifications mostly between the 4th and 8th sprint day.

These are then rewritten by the developer or software tester into test cases, whereby another software tester reviews the test cases and, if necessary, corrects them with the help of the programmer.

Subsequently, the first builds are completed (Alpha 1, Alpha 2,....,Alpha n) and the first round of functional testing can be performed.

After the complete implementation of all features (alpha for all modules), the first bug party can take place to determine the quality of the implementation and, if necessary, decide to run a second round of functional testing. This is followed by the integration test regarding the communication of the different modules and their interfaces.

Then the first update and installation tests can be performed and the business verification tests.

And last but not least the user acceptance test at the customer site.

To reduce the time needed for testing and to focus it on the changed areas (cost reduction regarding the testing effort), we thought about copying the sprintbacklog tasks into an Excel sheet (Y-axis) and listing the modules of the program on the X-axis. Here the respective programmer can mark which areas have been changed by which task. Then the software tester can test the respective test cases at these modules due to this information.

The same applies to the user stories, here the test effort can also be reduced if these are brought into dependence with the changed modules and thereby an indication is created, which use case scenarios must be examined and tested.

Questions: I would be interested to know how you have accommodated testing activities in Scrum.

2
  • 1
    You have just described a waterfall project with two-weeks timeslots. I think the team has to reconsider the understanding of agility and Scrum. Nov 16 '21 at 11:55
  • Not the first project where it goes the same way ;)
    – Mornon
    Nov 16 '21 at 12:21
2

If your definition of "classic software tester" is someone who takes in requirements and software and produces things like "tested software", defect reports, test reports, and so on, perhaps building test plans and test cases along the way, that doesn't have a place in Scrum. I'd say it doesn't have a place in very many methods that fall under the umbrella of Agile Software Development.

The problem is that this notion of "classic software tester" introduces a handoff. Someone needs to communicate requirements and pass ready-to-test software off to someone else. Handoffs are wasteful and tend to slow the process down without much gain. There may be times when it does add value, but those aren't common.

The mindset of a software tester in Agile Software Development needs to be that of a specialist. The whole team is working toward the goals and you have deep expertise in a particular area that can help the team get there. Your knowledge and expertise is useful at every step of the way.

Let's consider a team using the Scrum framework.

At some point prior to the Sprint in which it is worked on, each Product Backlog Item is captured and refined. During refinement, as a test specialist, you can think about what you would need in order to test the Product Backlog Item. If some aspect of it is unclear or ambiguous, get that sorted out as much as possible as part of refinement - if it's unclear to you, it's probably going to be unclear when someone starts working on it. If the way the work is ordered in the Product Backlog doesn't make much sense from a test perspective, bring that up as well so any dependencies can be worked out before Sprint Planning.

At Sprint Planning, make sure the scope of work likely to be necessary to achieve the Sprint Goal is not only buildable, but also testable during the Sprint timebox. If there are any known issues or problems that may come up, make sure the team is aware of those so the commitment to the goal coming out of Sprint Planning is reasonable.

Throughout the Sprint, work alongside the Developers to collaboratively build and maintain the test environment, along with any test cases. As a test specialist, you may take the lead on this kind of work, but it doesn't mean that you should be doing it alone. Also work with the other Developers to build up their test skillset so everyone can help in testing.

Automate, automate, automate. A test specialist is a good candidate for someone to be ultimately responsible for choosing test automation frameworks and integrating them into the build process. Getting manual test cases automated and making sure new test cases get automated quickly will make regression faster. Finding defects earlier in the process is good. Maintenance almost never ends, though. When tests fail, someone needs to determine if it's the software or the test that needs to be revised. Plus, there are new versions of test frameworks and new tools that can enhance the test process to be evaluated and incorporated. You cannot be Agile without automated tests - the time and effort needed to run through manual test cases to account for both regression as well as new functionality is just too high.

Make testing a part of the Definition of Done. Work is not Done until some level of testing has happened and the system is in a good state. A potentially releasable Increment is born every time a Product Backlog Item is Done and incorporated into the product. If you wouldn't feel comfortable putting that Increment into production because you're afraid of quality issues, find ways to get comfortable and enact them as a team.

There's no need for complex tracking in a spreadsheet of a duplicate of the Sprint Backlog and marking off changes. Instead of adding to documents, communicate as a team. Collaborate on getting work to Done. Tear down silos between development specialists and test specialists.

2
  • "The mindset of a software tester in Agile Software Development needs to be that of a specialist." - I think in agile it's exactly the opposite... 🤔 Nov 29 '21 at 17:30
  • @VishalAggarwal No. They are a specialist. Depending on the context, perhaps they want to develop skills outside their specialty and use those skills for the benefit of the team (a comb-shaped or pi-shaped individual, to use those terms). However, the team is what needs all of the skills, not each individual. The specialists on a team can help the non-specialists develop their skills in a particular area - a test specialist would help the development specialists or DBA specialists or UX specialists grow their test skills. Nov 29 '21 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.