The role of the classic software tester in Scrum?

Question

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.

Answer 1

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.

Answer 2

As a software testing company role of a classic software tested in a scrum is to review the requirements and create test cases while the feature is under development. Once the feature is Ready for Testing, than we perform testing of individual user stories on environments and post that a continuous integration test as a part of Regression in the last two days of the sprint depending upon the features to be released in a sprint.

Answer 3

Classic software tester provides vital role in any professional organization. High level points are mentioned below -

In the Scrum framework, the role of a classic software tester is typically encompassed within the cross-functional development team. Scrum promotes a collaborative and self-organizing team structure where individuals with different skills work together to deliver valuable software increments. Although there isn't a specific role called "software tester" in Scrum, the responsibilities related to testing and quality assurance are shared by the entire team. Here's how the classic software tester's role can be integrated into Scrum:

• Collaborative Testing: In Scrum, all team members, including developers, testers, and others, collaborate closely throughout the development process. Testers actively participate in sprint planning, backlog refinement, and daily Scrum meetings. They work hand-in-hand with developers to understand the requirements, provide input on testability, and identify potential issues early.

• Definition of Done (DoD): The Definition of Done is a shared understanding within the team that defines the quality criteria for a user story or a sprint. Testers contribute to defining the DoD by ensuring that testing and quality assurance activities are included. They may specify criteria such as successful unit tests, integration tests, system tests, user acceptance testing, and other relevant quality measures.

• Test Automation: Testers often play a significant role in creating and maintaining automated test suites. They collaborate with developers to write automated tests, including unit tests, integration tests, and acceptance tests. Automated testing helps ensure that the software meets the defined quality standards and allows for faster and more reliable regression testing.

• Continuous Integration and Testing: Testers actively participate in continuous integration and continuous testing practices. They work alongside developers to ensure that new code changes are automatically built, integrated, and validated using automated tests. This collaborative effort helps catch integration issues, regressions, and bugs early in the development cycle.

• Sprint Reviews and Retrospectives: Testers provide valuable input during sprint reviews, where the team demonstrates the completed work to stakeholders. They validate the software's functionality and its alignment with the defined acceptance criteria. Additionally, testers contribute to retrospectives by sharing insights on testing practices, identifying areas for improvement, and suggesting adjustments to testing strategies or processes.

Here are some of the benefits of having a software tester in Scrum:

• Increased quality: Testers can help to identify and fix defects early in the development process, which can save time and money.
• Improved customer satisfaction: By ensuring that the product meets the needs of the users, testers can help to improve customer satisfaction.
• Increased productivity: Testers can help to improve the efficiency of the development process by identifying and fixing defects early.
• Reduced risk: Testers can help to reduce the risk of releasing a product with defects.

It's important to note that the specific responsibilities and tasks within the testing domain may vary depending on the organization, project, and team dynamics. However, in Scrum, the emphasis is on fostering a collaborative environment where quality is a shared responsibility among all team members, including the classic software tester.