Definition of a Tester
Throughout the software industry there is a preconceived understanding of the role a tester plays. This has been derived through many years of necessary tailoring of the role to fit the needs of the projects and products built. As an example, a company building some software needed someone to verify it prior to releasing it into production and hence employed a person to manually check each requirement had been met. With the advance of project management techniques, the role then required knowledge of the management of defects found, the skill of regression testing defect fixes from a large pool of predefined test cases and the time management in order to provide the quickest turnaround possible in order to meet deadlines.Further skill advancement in certain companies has meant the addition of writing and maintaining automated tests suites as well.
Definition of a QA
The traditional software quality assurance role involved the management of, and adherence to, development and test practices within a project. In order to ensure that a product had been built using the standards defined, the project needed someone to research techniques and ensure that a seamless line of traceability and auditing was followed throughout every piece of work. This included work executed by business analysts, developers, testers and release engineers.
Where are we now?
In today’s software industry, the use of iterative management techniques has radically changed the way we build software, from how we define what to make to how we ensure it does what it’s meant to and, most importantly, that it’s the right thing to build. This has meant a change in what the traditional tester was asked to do, and also what the traditional quality assurance person was asked to do.
For the former, they are now required to be involved from day one on the project, not simply listening and gathering documentation from which to write tests but also to ask whether it’s feasible to build the product at all. Does it fit the needs of the customer? Do we have the right understanding of what we’d need to build it? Do we have those tools at our disposal? If not, when will we and will that impact us delivering anything and/or the customer’s needs? Etc etc. For the latter there is a new process to be learned, and a radical shift from defining processes pre-project kickoff and enforcing them, to ensuring enough process is in place for the team to function. This is then assisted by continually reviewing, adapting and updating processes to meet the changing needs of the project and company.
OK, I’m with you but so what?
It’s clear to me that, as my role has changed throughout the years, I can no longer classify myself as only a tester or only a QA. I perform both roles and do more than their initial remits combined. Should I not then call myself something to reflect the much greater scope of work I perform daily and the increased benefit I provide to the project?
If the answer is yes, what would that name be? I’d want a word that encompasses all the benefits I bring to the project, my reason for being there, my main focus each day. And for me, the answer to that question is Delivery.
When I test something, it’s with the view to validating it is ready for the team to deliver it, be that straight into production via a continuous delivery mechanism or delivery to a release management to deploy it. When I provide questions and input to shaping stories, it’s with a view to the team being able to deliver valuable functionality (another post here describes a method of doing so). When I shape the testing strategy it’s with a view to the team having the correct feedback mechanism so that it can deliver as quickly and reliably as possible.
Is delivery not everyone’s responsibility?
After reading the above, I’d imagine the first question would be “Surely everyone is focused on delivery?”. Whilst this is a correct statement (surely everyone wants to deliver what they’ve worked on?!), it has to be viewed in the context of the individual roles within a team and the historical need for the tester and QA described above.
A business analyst is focused on the shaping of a product that fits the business and end-users’ needs. On their minds are the overview of the completed product and fine detail of what each feature should provide. In executing this work, they require feedback, validation, critiquing and assistance in clearly describing what the developers should build and deliver.
A developer (both non-UX and UX) is focused on building this product, turning the business concept into functioning code/infrastructure. Foremost in their mind is how to architect the idea into a working ‘thing’. In executing this, they also require feedback, validation, critiquing and assistance in clearly ensuring the correct product is built and delivered.
The Tester/QA person provides these supporting functions to the disciplines. Would it not then be prudent to name that person after their key remit?
Does it matter what we’re called?
Calling the discipline Delivery encompasses the full range of tasks, responsibilities and focus asked of in the role. So what? Does it really matter what we’re called anyway?
Referring to the historical definitions above again, there are still many people performing those individual roles of tester or QA within the software industry. They largely work using traditional methodologies. When talking to companies who have these staff and relating them to what I do, the use of either name pigeon-holes me into only parts of my job.
This can result in companies not initially seeing the full benefit that someone from the discipline brings, and can lead to staffing issues. An example experienced was when a company switched to small iterative teams and believed that developers and BAs would be able to ‘pick up the testing work’. They misinterpreted what a Delivery person would bring to the team, having not experienced or realised the proactive work that the role also brings.
Using one of the traditional names can also mislead those who wish to transition to use iterative techniques into believing that their staff can seamlessly switch to the expanded role. As the role encompasses more than the duties of one or the other, people transitioning can be intimidated by the change if they thought it would be business as usual.
An argument could be that the opposite can also result if a Tester is asked to move to a Delivery role. The key point is to make everyone aware of the difference, to avoid any assumptions being made.
Another reason for naming the discipline more accurately is to provide the industry with expectations on what a Delivery person brings to a project. As an example, if a government is building a new electricity substation and employs an electrician, there is a different expectation from what this person can do than that of an electrical engineer. The electrical engineer can perform the same tasks as that of the electrician but can also discuss proposals, design the substation, discuss budgets etc as part of the whole project perspective.