Over the course of a project a tester will take on many roles and activities in a project and through these will gain valuable experiences. Over time you as a tester will have taken these experiences and assembled a toolbox of methods, ideas and ways of working to pick from for each new project.
This post will address some of the projects I’ve been part of and I will be sharing parts of the toolbox that these projects have given me. It will also give you as a tester one or many new tool(s) for your toolbox or reawaken the knowledge of tools you already possess.
Postcards from the Trenches
Developer – “Hey, that Banana Moth Pupa, what’s up with that?”
Tester – “It’s not good, that’s what’s up with that.”
Developer – “Ok.”
Tester – “Although, you should really get on the Blue Moon Butterfly first.”
This is a conversation I faithfully transcribed at one of my assignments and an example of the tips and tricks that I have brought with me from each of my assignments. The methods, ways of thinking and techniques are all tools that I have added to my toolbox over the years. This is what I would like to share with you today, these tools and the assignments where I picked them up. To help me in this, each assignment has sent a postcard with an anthropomorphic representation of itself.
The Elephant
My first postcard comes from the careful and slow-moving elephant, which represents my first assignment as a test consultant. The elephant sends her postcard from a maintenance project using a waterfall approach where the test group was split up, one tester to each development team.
Bring Everybody Together
The lesson I learned from the elephant was the Bring Everybody Together tool. Given that each tester was assigned to their specific development team, there was a risk that the tester would be isolated within her area of responsibility. To combat this, the entire test group were brought together to perform certain test activities each test phase. Testing together really helped the feeling of community within the test team and shared the knowledge each tester has gotten from their section.
“Once per test phase, gather the test team and test together.”
The Coyote
The animal known as the coyote is a fast-moving, quick-thinking and adaptable animal, and he sends his postcard from an agile project loosely based on the Kanban method where the test team had a large measure of freedom to decide on their own process.
Constant Communication
One of the tools the coyote taught me was to communicate constantly. The project organization was spread out geographically with each part (development, test, etc.) in a different city or country than each other. To ensure that knowledge was being shared and to form a cohesive group the team made sure to, daily and frequently, talk to each other. Using instant messaging tools we remembered to talk about other things than the project, like you would in a “normal” team over a cup of coffee.
“Communicate daily and frequently, forming a group bond.”
Adaptable Documentation
The team started with a test strategy document, but as the project continued this was largely abandoned. So we, the testers, started from scratch.
No reports.
No documented plans.
And as the demands for certain specific documentation arose, they were met. One example of which is when the project lead wanted performance metrics, the test team set up a performance measuring tool, gathered the metric and supplied them to the project lead. But we were adamant in ensuring that no documentation was worked on if it was not specifically asked for.
“Start with nothing, add and detract according to project demands.”
The Ant Colony
The last postcard comes from the cohesive ant colony, which is made up of many small parts, each working according to its best ability for the good of the colony. The colony sends it greetings from a project using a mixture of different agile methods, mainly Scrum, where the testers make up a part of a mixed team where all participants take responsibility for the functionality.
Test Race
The teams making up the colony worked in two- to three week iterations, delivering quality functionality at the end of each iteration. To ensure this quality the team gathered at the end and participated in a time-boxed activity to test through the worked-upon functionality covering all applicable configurations. The end result of this activity was not only new bugs (hopefully not), but also a shared agreement on whether the functionality was good enough to release, or if it needed more work.
“New eyes on the functionality and shared agreement on quality”
Bug Naming
Part of a tester’s daily life is finding and working with bugs, which can become tedious and clunky. To combat this, the testers in our part of the colony decided to give each found bug a unique name. As part of the bug management program, it received an ID but to distinguish it, we gave it a real bug’s name. This is incidentally where the starting conversation originates. In the ant colony project we used Wikipedia’s list of bugs, giving each tester and developer a special frame of reference.
“Unique bug names help project participants remember the bugs.”
Postcards
Each of these postcards represents one of my assignments and each assignment had lessons for me to learn, bringing new tools into an ever-expanding toolbox. Seeing the difference in each postcard with projects using waterfall, Scrum(ish) and Kanban(ish) it is evident that these tools are not all-encompassing.
As a tester you can’t expect to utilize each and every one of them, but my hope is that within these postcards, you can find one tool that you can utilize to make your testing more fun.
This is what we all want I guess, to enjoy our day and to have fun at work.
