This is a guest post by Stéphanie Desby (@StephDesby).
Stéphanie is a geek and curious, she is passionate about tech innovations. As a QA Tester, she likes like to play with webapps, mobile, IoT and APIs.
I’m a junior tester in an Agile team of 7 developers. The team hired me about a year because they wanted a tester directly in their team and not in a separate department of the company.
Before working here, I was working as a “robot” tester in a startup company. There, all the tester had to do was manually execute a list of test cases written by more experienced testers. That was it. Execute test cases and say if it passed or not.
I wanted something more adventurous so I joined an Agile team.
This team is using TDD and the code already had a large unit test coverage but nothing else. So I’m in charge of testing the APIs we develop and to automate the acceptance and non regression tests.
How to exist on the task board when you are a tester
In the first few months of working here, something bothered me everyday. At stand ups, everyone has something to say about a post-it on the board but I had no way to discuss about what I was doing. There were just a bunch of post-its in a “Test” column at the end of the board. But nobody cared because the test column was always full of post-its and nobody asked what was happening with the tests. Once post-its arrived in this column, that meant work was done because development on the feature was done and the Product Owners had already said “Ok, it’s going to production”.
This situation was very frustrating.
A solution came from a tutorial day with Growing Agile at Agile Testing Days 2015 (ATD 2015). Sam Laing and Karen Greaves suggested to remove the Test column and replace it by a “Show me” column. By doing this, it forces test tasks to appears on the board like any other tasks. The “Show me” column describes the task that has been done and are ready to be shown to someone else before reviewing the code and deploying. It allows a way to check that functionality answers the need before beginning a long process of reviewing code and deployment validation with a wrong feature.
My team and I tried this solution when I came back from the conference. We removed our “Tests” column and I started to put my post-its on the board. Now I’m asked what I am doing and everybody knows what has to be done before Tests are complete. This is a huge difference for me because it has reinforced my feeling of belonging to the team.
We still have issues with the “Show me” column because we are only 1 tester and 1 product owner/manager on the team and none of us has the time to go to each developer pair to take a look at each task. But, when features are complicated, we all work together on it to be sure that everybody understood what was asked. We are also having “Grooming sessions” to help this happen.
Shared knowledge for each feature
The grooming session is a habit I brought back from ATD 2015 too. It’s a meeting we do before starting to develop on a project. During this meeting, we take all the User Stories of a sprint and discuss them. The goal is to build the acceptance criteria for each story and make sure that everybody has understood what it means and what is expected.
At first, we were doing this session with just discussions and the meetings were kind of boring because the Product Owners took time to write each acceptance criteria directly in a way we could automate it (in Gherkin) and while he was doing this, everybody just watched.
Then I thought about using Example Mapping, which is more structured and helps everybody to participate. I invite you to read the cucumber.io blog post about it if you want to learn more about this method.
We had the chance to try this once only but the Grooming Session was more dynamic. Plus, as a tester, I found the method very good to spot what have to be test carefully and to not forget anything.
As Grooming Sessions are a meeting with the whole team, it’s also an ideal place to know where the technical difficulties are and identify some risky zones and where to perform advanced tests.
We do need to improve on this exercise but it helped to let everybody talk about the User Story. A simple thing we struggle with is that it’s always the same people that talk. Those who are more quiet, or shy, are never heard.
I like to be a tester so let me be a tester
All these small tricks are very helpful. But there is one difficulty that I didn’t find an answer to: how to be more than just an automation maker.
As I’m the only tester for all our projects, I always have to write the automated checks. Therefore, I’m always late and have no time to do complete testing (checking + exploring). I’m more a programmer than a tester right now and I don’t like this situation. I’m thinking about what could I do to change my role and make my colleagues understand that automation is not everything and that testing is not just “automatic checks”. Or to find an organisation that could allow me to write less code.
I still struggle with this one but if someone has faced this situation before and can help me with it, please leave a comment.