In the first part of this article, I wanted to explain about how we integrated QA into Agile artefacts at Triad and we covered quality in user stories, definition of ready, definition of done and documentation.
This second part looks at the role of test environments, ticket workflow, test automation and team communication and how the business and Agile development teams can benefit by optimising these artefacts.
Test Environment
It is advised to have the test environments setup and deployments tested even before the developers start writing code. This ensures that there is an environment available to test the code once the code is developed. You can have different environments such as local, Integration (QA or System test environment), Staging (pre-production) and Production.
Local environments are used by the developers and testers to run the application in their local machines for development and testing.
The Integration environment is where the code is deployed through Continuous Integration / Continuous Deployment (CI/CD) pipelines for System testing. This environment is used by the QA team to perform manual testing and to run automated Integration (API) tests and Smoke tests ideally every time a code change is pushed to the remote repository.
A staging environment is similar to a production environment setup used by QA teams for manual and automated Regression testing, Performance/Load testing and Security testing.
Ticket workflow in a Scrum or Kanban
Ticket workflow is an assortment of statuses, which are used to track the progress of a ticket. The below table illustrates the ticket workflow that can be used in Agile Scrum model or in Kanban model. This workflow board can be created in any project management tool like Jira or Azure DevOps.
| To Do | In Dev | Blocked | Ready for code review | In code review | Awaiting QA | In QA | Done |
To Do: This is the first state, indicating the user story is ready to be picked up by a developer. It might seem obvious but the user story in this state should meet the definition of ready as otherwise the missing pieces can multiple throughout the Agile process.
In Dev: This state indicates that the feature is under development.
Blocked: This state indicates that the respective story is being blocked and cannot proceed, for example if further information is required to progress or a dependency exits.
Ready for code review: Once the feature is developed, the developer moves the ticket to this state indicating that the ticket is ready for review by a peer.
In code review: The ticket that is currently under peer review is moved to this state when an assignee is specified. If there are any comments, then relevant comments are posted against the ticket and assigned back to the appropriate developer.
Once the review comments are fixed, the ticket is moved to “Ready for code review“, then moved to “In code review” by a peer. Finally, if it has passed the review, then the code is approved by the peer and merged, ready for QA.
Awaiting QA: Tickets in this state are ready for testing.
In QA: Tickets in this state will be picked by the QA team and undergo thorough manual testing. If the acceptance criteria are not met, then it has failed QA and is moved back to “To Do” and assigned back to the developer with relevant comments, steps to reproduce the issue, relevant screenshots and expected behaviour.
After fixing any defects, the ticket undergoes all the above steps and is retested.
You can follow the Exploratory Testing technique for manual testing.
Done: After the ticket has passed QA, it is moved to “Done” with any relevant comments, and closed. In principal, a feature should be moved to “Done” by, or in collaboration with the Product Owner to indicate the Product Owner has accepted this feature as complete (as opposed to the development team just saying it is complete). Depending on the project team structure, an additional status ‘Ready for PO review’ could be introduced.
Exploratory Testing
Exploratory testing is about discovery, investigation and learning. As the name suggests, it’s about testers exploring the application to identify potential edge cases.
Exploratory testing is the simultaneous process of test design and test execution. It is also complementary to test automation; that is while automated checks are checking for regression issues, exploratory testing focuses on new features which have been developed.
Test Automation
The major challenge for QAs on any Agile project is the amount of regression testing that needs to be performed before each release; this can also be addressed using test automation.
In order to get quick feedback, automated test scripts need to be executed as often as possible, ideally after every code change that is pushed to the repository. Tests need to be fast, delivering consistent and reliable results.
It is important to prepare a test automation strategy that is result-oriented and fits well with the team and organisation as a whole. You can read more about creating an effective test automation strategy in my blog post “How to optimise test automation on Agile projects”.
Communication
No matter how good the process is, if there is a lack of communication amongst the team members then it is difficult to produce a high quality product. Co-locating the team in a shared workspace will improve face-to-face communication and helps to build trust among the team members. When co-locating is not possible, you can use team collaboration tools such as Skype, Slack, Microsoft Teams or similar.
In Agile, requirements and solutions evolve through collaboration between self-organising cross functional teams and stakeholders. This makes it important to have a regular interaction between QAs, developers, stakeholders and the BA/Product Owner through daily stand-ups, planning meetings, backlog refinement meetings, regular demos and retrospectives.
Conclusion
Your team can enjoy the benefits of the Agile development process that produces a high quality product frequently and repeatedly. However, in order to achieve this, the QA process needs to be integrated into the development cycle and should be in the minds of all team members, always.
It should be part of the team’s day-to-day work rather than something that occurs at the end of development. It is also equally important to have effective communication amongst the team to improve the quality of the product, constantly.
Venu Botla
Consultant, Triad Group Plc
