Where we learn technology

Category: Agile

Scrum 2020 Guide — New Changes

                          SCRUM GUIDE 2020 UPDATES



It’s been 25 years since the launch of the Scrum Guide. With contributions from the Scrum community, Dr. Jeff Sutherland and Ken Schwaber have made updates to make it crisper, leaner and more transparent.

Role of a Tester in Scrum – Agile Process

Role of a tester in Release and Sprint Planning:

Understand user stories and acceptance criteria
User stories get clarified from the respective stakeholders where there is insufficient information
High level test strategy has to be decided for whole release
All the risk that might occurs at the time of release needs to be noted or documented
Number of testing types need to be decided and discussed
Estimate time for each user story test case creation and execution
Break user stories into different testing tasks
Decide each story test coverage
Acceptance criteria for user stories needs to be defined

Understand and plan for user stories automation and support various levels of testing

Customer satisfaction through delivery of high-quality software which is earlier and continuous is highest priority
Engagement is early during the project from sprint planning but the QA activities are same
Business people, developers, and testers must work together throughout the project
Discuss and understand each user story with stakeholders and then decide on acceptance criteria for the same
Welcome changing requirements. Tester needs to be adaptable to any changes
Define activities for themselves to estimate time, updating test cases as and when changes appear, complete testing within the sprint time etc.
Story level estimation needs to be done and time needs to be assigned for each story
Test Cases needs to be developed as per the story acceptance criteria and needs to be change whenever there is a change in story
Deliver high quality software iteratively from a couple of weeks to a couple of months
QA needs to track the progress of testing on a daily basis with continuous feedback

Naveen Khunteta
Naveen AutomationLabs 

Testers Working in an Agile Team

Testers Working in an Agile Team

Today’s tester role is more versatile and calls on a wide range of skills. Now testers have tasks throughout the sprint, and they also program — yes! — as regular programmers. (I don’t say as developers, as all participants in the team are part of the development: the business analyst (BA), the designer, the tester, the tech writer and the programmers.) Testers don’t need to be specialists in any one language; the more languages they know, the better the solutions they will find. A good engineer in testing should be able to adapt his or her knowledge according to the needs.
So let’s examine in greater depth the testers working in a team and their task distribution along the sprint. (This process localizes tester tasks, though it could be missing tasks for other roles).
In an Agile method, we could have previous, current, and next sprints. Our tester will have tasks related to each of these stages.
Tester tasks
Be part of the planning meeting for the current sprint. The tester will be in charge of providing estimations about data creation, test cases/acceptance test design, test execution, framework design/improvements, scripting tasks, setup environments, etc.
Be part of the planning meeting for the next sprint. The tester needs to validate whether he will create any complex environments, or any major improvements for the automation framework, before starting the next sprint.
Write acceptance criteria for each item for the next sprint. Testers create acceptance criteria for the user stories for the next sprint, helping the BA (if the team includes BAs) by giving suggestions from a QA perspective regarding standards, user experience, possible performance issues, and future bugs. Depending how Agile we are, we will have acceptance criteria and/or some test cases (this will also depend on the company, since sometimes you need to show some evidence about execution as test cases). Creating acceptance criteria can be a very creative task, but we need to validate how possible they are and whether we are on the same page as the PO, so validation from the team could be necessary.
Update acceptance criteria according to PO comments and create test cases for the next sprint. Once we receive team feedback, we update the acceptance criteria and start creating test cases (or acceptance tests if we’re working with application programming interfaces, or APIs).
Automate APIs (current sprint). If the application is divided in tiers, we will have APIs, or services. We could start scripting before programmers finish coding for the current sprint. At first, all our tests will fail, but gradually as programmers finish their work, our suite will pass. Automating them is easier than automating user interfaces, and they’re easier to maintain as well. Automation can be achieved using tools such as SoapUI, Jmeter, etc.
Execute acceptance criteria manually (current sprint). Test cases should be executed manually at least once when each user story is done. Manual verification will give us a set of bugs, an idea about limitations and how critical a test case is. On the other hand, this practice will determine the automation candidates for the next sprint.
Automate smoke test UI/regressions (previous sprint). Automating the UI once the application is stable could help you avoid many headaches. In this stage, we will start automating the smoke test for the current features done or regressions for complex modules. In future iterations we will update the smoke test, adding the new features.
Exploratory testing. This kind of testing will find bugs that no automated test will ever find. There is nothing that compares with the tester’s creativity, and we should apply this kind of testing once every sprint.
Be part of the review meeting for the current sprint. Testers or the BA could lead the internal/external demo. The goal is to show commitment to current sprint, and ideally we shouldn’t show any issue live! So a tester could choose the safer path and point out the known issues as well — an extra slide could be enough. (Testers and the BA speak human language, while programmers don’t, according to popular belief. . . .)
Be part of the retrospective meeting for the current sprint. In this meeting, everyone will participate, identifying things well done, things to improve, and actions to apply.
Naveen AutomationLabs