Step 2: Customize your development process to provide support to automated testing.(Continued)

Tester Tasks:

Be part of planning meeting for current sprint: the tester will be in charge of provide estimations about data creation, test cases/acceptance test design, test execution, frameworks design/improvements, scripting tasks, setup environments, etc.

Be part of planning meeting for next sprint: the tester just needs to validate if he will create any complex environment before starting next sprint, or major improvements for the automation framework.

Write Acceptance Criteria for each item (*) for next sprint: Testers create acceptance criteria for the user stories compromised for next sprint, they work helping BA (if the team includes BAs) giving suggestions from QA perspective, Standards, User Experience, possible performance issues and future bugs detected. Depending how agile we are… we will have acceptance criteria and/or some test cases (also depending the company. sometimes you need to show some evidences about executions as test cases).

Create acceptance criteria could be a very creative task but we need to validate how possible they are and if we are in the same page that the PO, so a validation with the team could be necessary.

Update AC according to PO comments & Create Test Cases for next sprint: Once we received the team feedback we update the acceptance criteria and start creating test cases (or acceptance test if we are working with APIs).

Automate APIs (Current sprint): If the application is divided in tears, we will have APIs or Services. We could start scripting before programmers finish coding for the current sprint.

At first glance, all our tests will fail but gradually programmers finish their work our suite will pass.

Automate them is easier than UI and easier to maintain as well. Automation could be affronted using some tools like SoapUI, Jmeter, etc.

Execute AC 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 automate candidates for next sprint.

Automate Smoke Test UI / Regressions (Previous sprint): Automate UI once the application is stable could avoid you many headaches. In this stage, we will start automating the Smoke test for the current features done or regressions for complex modules. In feature iterations we will update the smoke test adding the new features. (see Step 1: Automation Feasibility validation. Run the checklist : Execution )

Exploratory Testing: this kind of testing will find bugs that no automated test will find ever. There is nothing compare than the tester creativity and we should apply this kind of  testing once every sprint.

Be part of Review meeting for current sprint: Testers or BA could lead the internal/external Demo. The goal is to show the commitment for current sprint and "ideally" we shouldn't show any issue live! So a Tester could choose the safer path to be shown and point out the known issues as well (an extra slide could be enough). Testers and BA speak human language, programmers don’t. ;)

 

Be part of Retrospective meeting for current sprint: In this meeting, everyone will have the same participation identifying things well done, things to improve and actions to apply.