When I started my first role as a Tester, I didn’t really know much about software testing. My role was titled Business Support Analyst, so for a while I didn’t even realise I was a Tester. The developers were all on a separate floor in the office, and we rarely saw or spoke to them. But as time went on, and I gained more knowledge about testing, I realised that what I was doing was User Acceptance Testing.
Then I moved on to another company as a System Tester. We were all on the same floor with the developers this time, but there was still a separation between Developers and Testers. The company was a small software house, and they didn’t have much in the way of formal processes.
My third role as a Tester, was where I really started to learn about software development processes, albeit Waterfall. Agile was an unknown concept to me, and probably to most large companies at that time. I was working in a team of Testers, with a little more collaboration between Developers, Business Analysts, and us, but with all the problems that Waterfall can cause. Test automation was something I’d heard about, but had no experience of. This role was purely manual testing. Writing test scripts into a test tool, then running those scripts once the Developers had deployed their code. We had a tool for test automation, but very few of the Testers had experience of using it.
After a few years of working in Waterfall, I had the opportunity to move on to a project that was using Agile. I’d heard more about Agile by this time, and I was looking forward to trying something new.
Moving to an Agile environment was like a light being switched on. Suddenly everything was bright, and new, and exciting. Testers working closely with Analysts and Developers, and having input into the features being developed was refreshing. No more long system requirements meetings, and endlessly amending test scripts as requirements changed.
The project had a test automation framework, using Cucumber and Selenium, and part of my role was to write test scenarios using Gherkin. This was all new, and a bit odd sounding, but I was enjoying it. There was still a separation though. We wrote the scenarios in Gherkin, then passed them over to the Developers to implement. I didn’t know what the test automation framework looked like, or how it worked. Testing for me, involved manually verifying that the acceptance criteria had been met, and doing some exploratory testing once the user story moved into the testing column on our scrum board.
Being curious, as Testers are, and technically minded, I started to ask about the test automation. I had a few sessions sitting with the Automation Tester to learn how it worked, and shown how the Gherkins were understood by the framework to automate the web browser. Eventually I started to help implement the Gherkins for new user stories, and to help maintain the framework, and over time this then became a bigger part of my role as a Tester.
I didn’t think of myself as an Automation Tester. I was still a Tester, that knew how to help with test automation. I also learned about Performance Testing, and Accessibility Testing and these also became part of my role.
As I’ve moved on to different Agile projects, I’ve noticed there is still a separation. But it’s not between Developers and Testers as much, as there is far closer collaboration. It is within testing itself. I’ve worked in teams that have people referred to as Manual Testers, Performance Testers, Automation Testers (or Dev in Test).
In Agile teams, I’ve often thought that referring to people as Manual Testers sounds slightly derogatory. To me, it reinforces the separation in testing.
One of the biggest changes I found when I moved to projects using Agile, was being able to contribute early in the life-cycle of a user story, highlighting potential issues, and preventing defects at an early stage. This is one of the strengths of working as a Tester on an Agile project. But I also helped with automation, firstly by helping create scenarios, then later automating those scenarios.
So I think as a Testing community, we need to start addressing the separation. Instead of having Manual Testers, Automation Testers, Performance Testers, lets just start seeing us all as Testers – Agile Testers. A group with cross-functional skills, and able to adapt to the needs of the team or project. We add value in different places, whether through helping to define requirements, automate tests, explore an application to find issues, or report on performance and other aspects of the software being tested.
It doesn’t mean the specialisms will go away. But I think it will encourage a different mindset, where Agile Testers that don’t know about automation for example, won’t be put off asking about it as they are not the Automation Tester. Instead, it will be seen as a skill that could allow them to add value in a different place. It will encourage Testing to be seen as an activity, rather than a task carried out by the Tester.
We are all Agile Testers.