There is a huge shallow agreement in my part of the galaxy. It’s the term “tester”.
I know quite a lot of people who declare themselves as “tester”, independent of what it says on their business card, contract or signature. Test Analyst, Test Specialist, Test Lead, Test Manager, Software Engineer in Test, Test Consultant, to name just a few of the classics. Most of them simply call themselves “tester”. Yet everybody has a very different understanding of his daily business.
There is a role in many projects defined as “the tester”. And this is the description from my understanding how non-testers usually see this role.
A tester is the person responsible for creating test cases, test scripts, test charters, or whatever you call the plan of what you want or need to test. This person is then responsible for the actual performance of testing, doing regression testing and/or writing, adapting or extending test scripts. And of course reporting (providing information) on what they have done and found, be it counting entities of test artifacts, writing reports, filling dashboards, and filing bug reports in whatever way is appropriate for the project. That’s usually about it.
But hold on, reality isn’t that easy. Many of the people I know who call themselves “testers” do way more.
Consultants – Asking questions is what you could do all day long. Why are testers asking questions? To improve their understanding of the system (product, project, company, etc.) It’s to analyze risks, and sometimes – in forms the remind of Socratic Questioning – trying to help others to understand things better.
Project Management and Coordination – Testing – still way too often – is near the end of the software development life cycle. Mostly it’s about managing your own work, but too often that has influence on others. So testers end up juggling things around to improve efficiency and effectivity of a project to deliver faster or on time.
Developers – Automation in Testing is one of the terms I like most, that describes it as a whole. There are not only automated regression test suites, testers using or writing tools to monitor log files, create or maintain test data, manage deployments, and so on. Many testers might not be more skilled than the average script kiddie, but that’s okay. It helps to do the job. Others are creating test frameworks with gigantic test suites with hundreds or thousands of tests.
And also if you help with code reviews
Quality Coaches – Testers often help when there is a lack of understanding in what quality is and what aspects of quality are most important for the product at hand. Too often testers are called “quality assurance” and are responsible that a product “with high quality” will be delivered. But a tester, in his key role, is not changing anything in the product. But with this add-on task a tester can do a great deal to help build a high quality product, not only when it’s too late.
Process Optimization – I know many testers who don’t like inefficient processes, and in the average software development project there are many processes and many need adaption and tuning. Often it’s the testers who take over that job to achieve better processes. Why? Because a good tester is involved somehow in nearly every process there is in a software development project, that’s why.
System Thinkers – Testers often play a central role, don’t have split responsibilities, but need to know everything about a product, they are involved in many aspects of product design, requirements engineering, and running the product on test environments. All that comes with improved knowledge about motivations, actors, flows and stocks. Used wisely it will help in many of the other “jobs” a tester takes over.
Product Designers – Testers are often the first users of a product and play an important role influencing the product design to improve usability and user experience.
Data Analysts – Testers want to understand how the product is used in production, what errors happen in production, what typical user flows are, and so on, to improve their own testing efforts or to re-prioritize tests.
Requirements Engineers – Testers help to write and improve requirements by adding testable acceptance criteria, analyze risks, dependencies, and other influences. Or they ask questions to sharpen the understanding of requirements.
Operations and test environment coordination – Many testers are responsible for their own test environments, so they have to set up the environment, configure the tools you need accordingly, set up databases, deploy the product itself, and run it. You have to monitor your environment and take care for it. Then there are the test devices, from different browsers to huge collections of mobile devices or whatever you are working with.
Process Owner and Maintainers – very often testers own the bug tracking process, many times it doesn’t stop there. I’ve found myself more than once in the position to maintain all the process templates, and so are others. You don’t have to own a process to maintain it’s artifacts. But the influence you have when doing that is often tremendous.
Coaching – When there are new people coming into the team, I know from several places where the testers are responsible for introducing them to the product. Because they often have the best knowledge about the product and how it’s used.
Of course there are these modern approaches where testers even coach developers how to improve their testing.
Communication – Testers should be masters of communication. Testers talk with analysts, requirement engineers, developers, administrators, managers, support people, customers, and so on. And everybody uses a different language. The only one who usually adapts is the tester involved.
Decision Makers – I know that the core role of a tester is to provide information to others to make informed decisions. But all to often the testers get the role to make a decision if the product is ready for delivery or not. Might it be for blaming reasons or trust into the person who has seen the product in detail as it is now, there are many more.
In addition my point on this matter is, that a tester makes lots of decisions every day how to test the system, which bugs to report, how to prioritize things, and so on. All influence the outcome of the project. Too often we are not aware of that.
Psychologists – Testers are everywhere in a project and they speak with people. So the tester is often in there to listen to developers ranting about requirements, managers about customers, and so on. Testers just happen to be there, and when you are good in Communication, you are good in listening. So, you get that job as well.
Product Owners – I know of testers who take a mixed role of PO and tester, I know POs who are especially good at testing, I know of POs who don’t find someone else to help out on vacation, but simply assign the role to the tester, usually when there is trust involved.
And the list goes on… and this makes it so difficult to compare two testers. In the job ads you will mostly find descriptions of the core tasks a tester should do. And managers think that testers are interchangeable. Nobody speaks of the other activities I listed here, some silently expect it, some have no clue that that is what a good tester does. Oh, I could tell you some stories…
When you meet a tester, this person is all of this above to certain degrees. It’s not how testers are seen by others, nor paid. But that’s what many of the people who call themselves “tester” that I know do, and it’s what makes them get up in the morning and be the best tester they can be.
Most of the people that I know who call themselves “tester” are genuine, enthusiastic and love what they are doing, from 9-5 and often also from 5-9. No matter what others think. Often they stand in the background, take the blame, fill up empty roles, do the work nobody else wants to do, and serve the team, to make the project a better place and help to make the product a better one than in the delivery before. And in their spare time they help to improve the world of testing and make it a better place and share information and experiences.
And good testers always know where their towel is! Happy Towel Day!
PS: If you don’t believe me, look at the variety of topics at many software testing conferences. It’s usually not about writing test cases.
Test Pappy 