It all starts with Quality

Testers do not just “do testing” in an Agile team and have many roles to play during the delivery of software. Testers are fully involved in the development lifecycle, meaning quality starts from day one. Although everyone in the team is responsible for quality, the test team tend to drive this and lead by example to promote good working practices, as well as being at the forefront when identifying product risks.

Tester Types
Testers come from all backgrounds. There is a diverse set of testing skills that are developed through personality traits, education and experience, which shape the way the individual tester brain works. There is not one type of tester that is more effective than another due to these differing skillsets and all can contribute to delivery as well as each other.

It is not always useful to pigeon-hole individuals, especially when testers in an Agile team can be expected to display a variety of skill sets. However, there is a case that suggests that people tend to fall into a pattern of behaviour that they feel most comfortable with, especially when working under pressure. We can summarise the many tester traits into four types, with most testers demonstrating a primary and a secondary type.

● Organiser – leaders, managers, coordinators, reporters, good communicators, making sure things get done, processes followed, stakeholder management, coaching, training, negotiators, influencers, checklists, efficiency, continuous improvement
● Analyser – manual investigation, models, statistics, data creation, data analysis, metrics, diagrams, process flows, algorithms, risk analysis, test coverage, logical thinking
● Questioner – curious, emphatic, customer focused, explorers, thinking outside the box, consistency, inquisitive, use of personas, edge cases, creative thinking, mind maps
● Techy – automation, non-functional, tools, test harnesses, code investigation, testability, technical reviews, code coverage, impact analysis, implementation, avoid rework

Support
This leads onto another key role that testers play, which is to support the team. The way each tester thinks will naturally compliment the other Agile roles in the team, which also tends to fit under these same types. For example, the activities that an Organiser enjoys carrying out will be able to support the Project Manager that also leans towards being an Organiser. A tester that is classed as an Analyser / Questioner will naturally focus their work that helps and supports the Business Analyst who also share the same traits.

Responsibilities
It is possible to map the day to day test activities against the Tester Types, to show which traits are employed when carrying out the various responsibilities and how they help other team members:

The Organiser – Supporting the Project Manager
● Creating test strategy documents
● Making sure test tasks are scheduled into the correct sprints
● Suggesting and implementing ideas for efficiency
● Coaching other team members in the importance of testing
● Negotiation of resources and time
● Providing reports for test coverage and defects
● Focussing on delivery according to the Quality Triangle
● Making sure tasks and stories are updated on the board
● Keeping a close eye on estimates vs actuals
● Evaluating whether stories can be test complete within the sprint

The Organiser / Analyser – Supporting the Product Owner
● Defect management and trend spotting
● Managing Environment setup
● Providing estimations metrics and forecasts
● Helping to prioritise the backlog based on Risk impact and dependencies
● Inputting into the definition of done
● Identifying and reporting scope creep

The Analyser / Questioner – Supporting the Business Analyst
● Analysing requirements for conflicts and inconsistencies
● Investigating design, UX, usability, intuitiveness using mock-ups and wireframes
● Test planning for exploratory sessions
● Carrying out Risk Analysis Matrix
● Designing Automated tests for regression
● Helping to create acceptance criteria
● Asking questions and prompting discussion
● Carrying out demonstrations and overviews for sign off and quality checks
● Liaising with the UAT team
● Focussing on preventing bugs rather than finding them

The Analyser / Techy – Supporting Developers
● Preparing test data efficiently
● Creating a Test Automation Framework including controls and ids
● Supporting Build and release management
● Researching and ensuring good use of test tools and test harnesses
● Pairing with developers for investigation and problem solving
● Inputting into Code reviews and unit testing
● Carrying out and reporting Performance and Security tests

The Organiser / Questioner – Supporting Testers
● Negotiating with other testers regarding risk-based testing
● Facilitating Test Ideas Workshops
● Ensuring Demoes are carried out for sign off
● Coaching and mentoring
● Debriefing and further test ideas
● Cross training and knowledge sharing
● Creating a community spirit and collaborative atmosphere

The Lonely Tester
In small teams where there may only be one tester, it can be difficult to find someone that can cover all four disciplines. However, it is a tester’s responsibility for self-development. If the tester has the right attitude and aptitude, then it is reasonable to expect that they will be able to learn and contribute in all areas. For example, there are many creative testers that have been able to master the skills required for automation. It is important that the sole tester has the support from other team members to allow them to succeed and grow with the team. Adding stories to the backlog for knowledge transfer allows Developers, Business Analysts and Project Managers to work closely with the sole tester and is essential for supporting each other.

A Sense of Balance
If a team is only made up of very technical people, then delivery may be focused on happy path, automation and non-functional testing. There is a danger that the software will not be intuitive with a lack of negative tests, leading to UX type defects being found after release. An absence of documentation or effective reporting will also make it difficult to determine what quality looks like if there are no Organisers in the team. This is an extreme example, but demonstrates that if the team is not balanced, then the software and quality is also unlikely to be.

So, in an Agile team, it is important to aim for a diverse set of testers to cover all responsibilities to a high level during software delivery. This avoids gaps, making sure that the software is being tested from all angles, so a deeper and varied set of defects can be found. The benefit of having a test team that thinks diversely is a great asset and will make any Agile team stronger through collaboration and knowledge sharing. Seeking to have testers in a team that balance each other with creative and technical skills gives a dynamic that allows information about quality to be assessed as thoroughly as possible.