This guest blog post is part of an Atlassian blog series raising awareness about testing innovation within the QA community. You can find the other posts in this series under the QA Innovation tag.
The post is written by Lanette Creamer, an Agile testing consultant involved in software testing since 1999.
Testers are prone to argue about anything. Just last night, at the Selenium Meetup, a fellow tester, Gary Masnica said, “There is nothing worse than listening to two testers argue. Before long, it will even get down to semantics, and I’m reminded of the Bill Clinton trial as each tester ponders the meaning of the word ‘the’ or something equally as silly.” Considering the small size of the testing community in relation to the number of developers, what gives? Are these testers just a cranky and cantankerous lot of malcontents? If so, surely not 4 out of 5 of them? Well, let’s first say that the title is a joke, because I’ve done no research, so those Dataphiles among you, please don’t go looking for the pie chart and research attached. Secondly, there IS something to it.
Reasons for Disparity
Critical Thinking
First, to be effective as a software testers, you develop a different kind of critical thinking in order to find the exceptions to a given rule. It can be said that if you hear hoofbeats, think horses, not zebras. Testers know you’ve considered horses, but can you handle a herd of zebras? This is one reason why our arguments may sound strange to you, but when your code is on Safari, will you be less sorry?
Varying Cultural Norms
Secondly, testing is a HUGE profession than spans the entire globe. The education for testers is far from consistent, and there are these much debated “schools of thought” that some subscribe to. On top of that, we have testers who work in different stages of Agile transitions across the industry now. Call someone a “resource” in some company and you’d be better off to have cursed at them. Let’s just say that cultural norms vary. Even this combined with cultural differences across the globe don’t explain all that is going on.
Making the Argument
The third reason why testers often do not agree, even on things that seem simple to other people, is that testers need to convince other people in order to see changes happen. For many of us, the number of bugs we FIND isn’t important. It is only the number of bugs important enough to be fixed or that we prevented that adds value to the end user. We don’t intend to argue for bugs being fixed or prevented unless they ARE important, but when that bug is important, a good tester will be as convincing as a pitbull lawyer. There will be research, evidence, and convincing testimony from bystanders. By the time you’ve reached many years experience as a professional software tester, you are as adept at explaining risk and sharing information with others as a good insurance agent, and that is a good thing, unless you happen to be debating against one.
Don’t Take It Personally
The fourth reason I have for you to consider is that often debates between testers aren’t personal. As we work in different areas of software testing, what sounds like disagreement and discord may just be two people who like to verbally spar and consider alternatives. We’re nerds, generally, just like other computer people. Star Wars vs Star Trek and Pirates vs Ninjas still can become religious issues. I’ve recently learned if I ever want to be the Crazy Cat Lady of Software I’ve got a loooong way to go. Did you know that Sandra Lerner of Cisco Fame has 9 cats and just bought the first feline knee replacement for one of them? That is awesome! She’s also into hosting full costume ball dances at her mansion.
QA Drama
Now, for reason 5 out of 5, consider that maybe 4/5 testers do agree, but we never see them. The ones who don’t agree are just very loud and active. Also, drama draws focus, especially on the internet. Sometimes testers do feel the need to speak up, and indeed it is a key responsibility to point out flaws and possible big risks. To let important issues quietly go by wouldn’t be a helpful trait as a tester, but consider that all of the times we quietly agree, you are less likely to hear it. The memehappy testers at Mozilla appreciated my many cat photos, but the same photos with a different audience led to accusations that I’m making testers look unprofessional. Just like the word “resource”, even personal style can be considered a risk to testers. The level of risk that is normal at a web based company would be considered irresponsible in some regulated environments. Testing will be far different when working on medical equipment than when working on a free video game, and rightly so. While 4/5 testers may simply say, “I work in a different part of testing than you do,” you are likely to hear and remember the few who disagree loudly in public.
Where do we go from here?
While disagreement between testers has been the status quo for so long that it is still noted today, cooperation and teamwork are broadening testing in new ways.
As automation becomes more common, developers and testers find that their skills are merging. They may have different areas of focus, but pairing between testers and developers is one of the faster growing areas in the industry, especially on teams adopting agile practices. As developers learn to do more testing, such as unit testing, and even TDD, the testers are delving further into tool assisted exploratory testing, using innovations in visual display of data to guide them to changes and areas of possible bug regression based on changes.
Testers are participating in creation of automation, early code reviews, and also in testing requirements before the software is even created, basically preventing bugs before they can be written. In addition, due to advances in Developer technology, testers can test branches in Jenkins or Hudson continous integration servers from anywhere! This makes a new type of build, where checking in to the main branch may be gated by a person AND automated acceptance tests and multiple levels, giving teams control over how many tests a build needs to pass before going out to a client, or the public vs. how good is good enough for internal testing.
This can also be done faster than ever before. Free tools such as TestFlight allow developers from all over the world to specify and release to just the beta testers they trust, giving them control over in the wild testing, where paid services, such as uTest can literally provide an army of testers in a certain location at the time named by the team! We are only starting to see which combinations are the most useful in which situations, but one thing is certain, the need for talented testers isn’t going away. It is diversifying, growing, and many of the skills needed may have aspects in common with that of good developers, but the mindset is slightly different.
Most testers now feel that they are part of the development team, where in the past testers were more siloed. As this change has happened, testers still seek out advice and help from other testers. Strongly identifying with a team is positive, as is shared responsibility for quality. There may not be a testing “team” in your company, but the testing community is growing, and now, more than ever, it includes more enlightened developers who need to test their own code, as well as the team members who take the testing of the entire product, beyond the code, further than they have been able to do before as tools enable earlier testing.
Lanette Creamer a.k.a. Testy Redhead is a consulting software tester who is passionate about collaborative testing and is a practicing student of the context driven school. Lanette is a frequent industry speaker in the software testing community, and also enjoys agile and lean peer conferences. She has presented at StarEast, CAST, STPCon, PNSQC, and as a guest speaker at Mozilla in the past year. She also writes articles occasionally in addition to her blog, Testy Redhead. Find her on Twitter at @lanettecream.