This is a guest post by Peter G Walen.
How DO people become testers? Can testers with non-traditional backgrounds and paths succeed?
At one time, for many development groups, the question of “Where do we get people to test the software?” was answered – the people writing code also tested. For many shops, the “done thing” was to have developers test their own code (unit and functional) then have a colleague test it as well. The ultimate arbiter was the customer or their representative.
Time went on and the need for testing, other than what the developers were doing, grew. Some organizations created testing or “quality” groups. Sometimes they created new groups called Quality Control or Quality Assurance, loosely based on manufacturing models.
To staff these groups, it was not uncommon for developers to be “reassigned” into testing. Sometimes willingly, sometimes by simply being put there. What had been one small part of their work now was a huge part if not all their work:
- Figure out what needed to be tested for each project
- Figure out HOW to test each project
- Figure out how to talk with people about what each project was really supposed to do
- Figure out if the project “worked”
- Figure out all the ways the project might not work.
The First Challenges
This certainly was a start. It helped most organizations for a while, at least until the workload grew so it was unsustainable.
Why would the workload grow? Loads of reasons.
Sometimes developers moved into testing were better at finding problems than their peers. This might result in their finding issues to address even after the original issues had been “fixed.”
Other times people doing development stopped testing their own code or perhaps did enough to say they had “tested it.” After all, there was now a group dedicated to testing the code that other people wrote.
In some companies top performing developers stayed writing code and those that were not quite “up to snuff” were moved to testing. This often resulted in poor, inefficient work, even following simple checklists instead of considered, thoughtful testing. This in turn often resulted in bugs being found long after they reasonably could have been expected to be found. Sometimes even after the release of the product.
The combination of these issues and others related to them, often resulted in testing and the testing group, being blamed as the bottleneck in releasing good quality software and for all problems found after release.
To fix this, many companies introduced a “training” method. Developers new to the company — or those with little experience — landed in testing as a “gateway” to “real” development work. The ruse, of course, was that testing was an entry-level path to development work. People wanting to be good developers were placed in testing roles so they could “learn the ropes” and work their way into “real” software development work.
Never mind that training in test techniques and approaches were usually limited and consisted of stock phrases like “don’t worry about the edge cases” and “just focus on what most people do.”
The Current Challenges
For many organizations that have a tester role, the above describes the current state. Many see testing as a “trainee” or “fresher” role for software development. People who want to get into software development, even with a degree in Computer Science or Information Systems get sent to testing as a way of getting into software development and gaining “real-world” experience.
When a new developer is coming with a code academy certification, things are not much different. They may get shunted into a “test” role to “learn the ropes” and see how things really get done.
In both instances, candidates, let alone new hires, may not be interested in a position involving a stint doing testing because it is seen as something less than “real development” work.
The challenge involves a mix of issues.
First is the split of “development” into component pieces. Making testing completely independent of software development is problematic, at best. When particular skills and abilities are less valued than others, a class structure will likely develop.
Putting people into positions where they do not want to be, even if they are stepping-stones to the “next level” does not guarantee good work or growth.
It may result in a level of understanding of the complexities in good testing. It could sway some to take on testing as a career, instead of a transitional step to development. It could even result in improved long-term code writing and higher quality software.
It is possible that people intending to take the path of testers becoming developers may choose to stay in testing. Unfortunately, companies with such structures usually see testers as less important than developers. Instead of being co-workers, testers tend to be viewed as “not quite good enough.”
For organizations like these, the core problem is often a poor understanding of software testing itself. With effort, that can be changed. However, these types of organizations often see little to no value in testing.
One Path Ahead
There are positive signs.
Software development organizations are not all like those described above. Even those eschewing the idea of “testers” in their Agile environment are recognizing the challenges and opportunities good testing presents.
Some look for “technical training” as expectations for testers. Is this really needed?
Probably not.
The key traits of being able to be a good, and likely outstanding tester, might break down something like this:
- Curiosity – An insatiable curiosity helps a tester look for possible paths to explore and a wide variety of “What happens if…” scenarios.
- Tenacity – Once you find something, follow it. Follow it until it no longer makes sense to do so.
- Observation – The ability to watch what is happening. Observation and consideration can help find the difference between “interesting possible problem” and “rabbit hole.”
- Logic/logical analysis – Framing thought processes in a way that help keep the tester on track and focused on the needs of the team and customer.
- Flexibility – Being nimble of mind and mindset is needed as shifting perspectives can help inform the tester and shape their thinking and decision making.
- Thinking – Beyond intuition, thinking clearly can encompass the other traits listed and shape how the tester approaches everything.
Why do these traits count more than technical “skills?” Many of these are less easy to teach than, say, learning to read or write code – in any language. The challenge is rarely about “learning to code.” It is more often framing the information in a way that makes sense to someone with little or no background in technology.
What About Degrees and Certificates?
What have successful testers studied and been trained in?
Surprisingly few have studied computer science or information systems. Those who have studied areas requiring deep scholarship and logical reasoning have had great success. Many don’t realize how good they are.
Backgrounds in political science, philosophy, language, arts, music (both performance and education), history, accounting, and general business all help shape the logical processes used in testing. These can, and will, prove fruitful in many ways as long as the individual keeps an open mind.
What does it take to have a successful career in testing?
An open mind and commitment to keep learning new things. Everything else can be picked up along the way.
For more on this topic, check out our popular blog post: 25 Challenging Tester & QA Interview Questions.
Peter G. Walen has over 25 years of experience in software development, testing, and agile practices. He works hard to help teams understand how their software works and interacts with other software and the people using it. He is a member of the Agile Alliance, the Scrum Alliance and the American Society for Quality (ASQ) and an active participant in software meetups and frequent conference speaker.
