Not too long ago I was describing the role of the test group at a company I have worked for to a group of Software Testers outside of the company. Now before I go any further I will say this – I’m not “bashing” any individual or group of individuals at the company.  The majority of people I’ve met in the test group are actually great individuals.  I am referring to the behaviours and attitudes towards testing.  I had mentioned the role of testing in the company and how it contradicted with what I did (including what I did at this company) and what I believed in as a proud and passionate software tester.  I described how there was a lot of checking going on that was labelled as testing – checking that applications and features would work as per requirements – and calling that testing.  I have a chart posted at my desk showing the difference between testing and checking as I learned from Michael Bolton’s work.

I also went on to describe some of the key responsibilities of the test group – which I explicitly stated were not things that I necessarily did. Responsibilities such as signing off (my post on testers signing off here), extensive standardized documentation in the form of mindless test plan and strategy templates, and mindless heavily scripted test cases pre-written before any testing was even done. (I have included more details to the responsibilities here than I did when I described them to the group of software testers).

I made sure I stated that I did not take part in all of these activities, because I spent (and still do) a lot of time and effort arguing my case, my reasoning, explaining what software testing really is, its value and that it involves skill, and thought, and isn’t just some mindless task just anybody could do.  I won’t lie, because I dealt with it every single day, at times it’s difficult and can even be draining to have to fight and disagree and have to prove and mention my reasoning over and over to different people in different positions within the company.  Sure, after some gruelling days I have even asked myself “is it even worth fighting for testing at this place?”.  Those next days, I still did stand my ground and fought for myself as a skilled tester who was there to provide testing with some type of value and not engage in mindless activities.  I had presented this to management a few times but unfortunately the situation and reorganization at the company prevented anybody with the power to actually do anything about it.

I received some nice and encouraging feedback from some of the software testers in the group I was describing this too, and one that got me thinking came from Joep Schuurkes who told me to “keep up the good fight”.  Now up until that point I considered myself fighting against incompetence in testing, against template junkies (I got that term from Rob Sabourin), and against testing zombies (I got that term from Ben Kelly), and stated it as such.

I was fighting against all of these things and I still do, every single day – but another good way to put it as I now do – I am fighting the good fight, and will do so as long as I am a Software Tester!

A few months ago an acquaintance of mine asked me what I did for a living, and so I replied “I’m a Software Tester … A Skilled Software Tester”.  There was a noticeable pause between the 2 parts of my answer – mostly because I feel that there’s sometimes a false belief amongst people that don’t know any better that being a Software Tester doesn’t require an individual to be very skilled (this is something I believe that’s changing as the community of skilled software testers continues to grow, learn, promote & learn skills, challenge old ways to doing things, and focus on testing that has value).

I continued my answer to the question with a brief explanation of what I meant, without going on for an extended period of time making it seem like a speech or a lunch & learn.  I explained that I don’t spend my testing time doing things “the old way” (I actually found a better term for it thanks to Keith Klain – more on this in a separate post), of filling out templates, spending hours writing and executing heavily scripted test cases, or writing 30 page test plan documents that nobody will actually read.  I spend my time testing, what & how I test will depend on the application and the different situations surrounding the application. I don’t test everything the same way because I don’t believe in best practices, I believe in good practices in certain contexts. I work with developers, project managers and other testers to provide information about the quality of the software. That was my explanation.

In the weeks that followed, I spent some time thinking about that explanation and how I could explain it better in the future. The content of my explanation was composed of conversations I’ve had with many people (testers and non-testers), explaining to them that there was more to testing than templates, documents and scripted test cases – that skilled software testing and testers did indeed exist and were really good at what they did. I had spoken about testing skills and shifting focus to testing that added value to the project to quite a few people and was looking into ways to do it better. I came across a post written by Keith Klain The skilled testing revolution … which explains that things are changing, the old ways of doing things are on their last legs, and that skilled software testing is starting to gain momentum and recognition. I’ve send the post to some people as it highlights, and better explains the message I’ve been aiming to get across.

As I continue to learn, apply what I’m learning, and talk to other testers – all of which contributes to me becoming a better and more skilled software tester everyday –  I’m glad to say that I’m part of the skilled testing revolution.

Throughout my Testing career one of the things I’ve learned (and learned early on in my career) was to never report or identify possible causes of a problem without proper knowledge based on investigation and facts to back up my claim.  This “rule” can be based on a “finding” during testing or discovering a defect during testing.  Part of my job (and approach to testing) is to explore, discover, learn about the application I’m testing and investigate it – this includes investigating behaviours and defects I come across so that I can provide knowledgable information about what I’m reporting. I’d never identify a defect and then list possible causes with uneducated guesses – without any investigation, or facts of some kind to explain why I believe something would be the cause of the problem.

While I’d never do this during any type of testing – this is exactly what I did in a scenario involving my car recently.  About a week ago I had identified a burning smell coming from my car after I had driven it.  I’ve had a few cars and encountered my fair share of different problems with them but I had never encountered this type of burning smell before.  I had just changed my wheels and tires but I knew this wasn’t the issue behind the problem – the tires were the correct size and the rims weren’t rubbing against the shocks nor the callipers in the front or back.  The days went by and the burning smell was still present.  For some reason I was convinced that the burning smell was a result of either: 1 – oil burning somewhere in the engine or 2 – an electrical wire burning somewhere.

I’m not sure what I based the possible causes on – I don’t have a mechanical lift or any other type of equipment to diagnose the cause of such problems.  My reasons were based on uneducated guesses. I decided to visit a buddy of mines who’s a mechanic with his own shop and told him the problem and what I believed the causes to be.  We took a road test, came back to the garage and he smelled the burning smell and decided to put the car onto the lift right away.  Took him less than 30 seconds to identify the cause of the issue (burning smell) – there was a plastic bag or some type of plastic that had gotten stuck under the car and melted onto the exhaust pipe towards the front of the car.

So much for what I thought and was almost sure the causes of the burning smell were. It was a good reminder for me to perhaps apply what I apply in my testing to other parts of life.

Lesson learned.

There have been a few instances where I’d be working on a task related to my testing of a feature of application and I’d overhear something that would make me ask myself “Is Testing a bad word?”

Things like “this will have to be qa’d” or “we’re going to have to quality control this application” or “we’ll send this off to qa”. Once I even heard a software tester say “hey we’re not quality assurance”,  I smiled for an instant until I heard the second part of the statement “we’re quality control”.  While I do realize these statements are made due to miseducation or a misunderstanding of what these “software testers” actually do and the purpose they serve, it doesn’t stop me from asking myself if testing is a bad word.

There are some individuals with whom I’ve had conversations with to try to help them distinguish between the two and maybe even enlighten them to the fact that they aren’t assuring quality or controlling quality as Software Testers. I’ve even used some examples I’ve learned studying Michael Bolton’s work to illustrate my point “The role for us is not quality assurance; we don’t have control over the schedule, the budget, programmer staffing, product scope, the development model, customer relationships, and so forth.”  I’m often told “well here we are quality assurance”.

But on the other side, there are other individuals I’ve spoken to – smart, enthusiastic Software Testers who want to think when doing their job, who want to do meaningful work and have the results of their efforts serve a good purpose, who are enlightened by some of the content I’m sharing with them – I like to refer to this as the bright side.

So is Testing a Bad Word?  Hmm I guess that depends on who you ask.

There have been a few times in my career where I’ve had somebody (Test Manager, Test Coordinator, Development Manager etc)  tell me something along the lines of “testing this shouldn’t take more than n hours or n days.”  This can be conveyed (and interpreted) in two ways; we have n hours or n days to test, or it can mean that you should be able to complete your testing in n hours or n days.  More often than not, it means the latter. The statement conveyed in that manner completely disregards the fact that complete testing is not possible (I won’t be going into this detail in this post).  Furthermore, the statement is often made without a real understanding of the feature to be tested. Sometimes the test manager or coordinator can make the statement without knowledge of the technical details, the risks, and without any consideration given to the details for the specific feature or application.  Other times the statement is made based on what somebody else, for example a developer or business analyst has said.

In my opinion this is similar to somebody making a personal recommendation to try a restaurant based on what somebody else has said without ever having eaten at the restaurant themselves.

Either way it leads to unrealistic expectations, inaccurate estimates, and a lot of misunderstandings & confusion (not to mention a poor understanding of Software Testing) – unless the Software Tester takes action to prevent that. This can lead to a lot of explanations, disagreements, meetings and more which ultimately cuts into testing time.  The first time I was in this situation, and every subsequent time I’ve always made it a point to speak up and explain to the individual making the statement what the testing for the particular situation actually entails and why the statement may be inaccurate – those with a stake in the project (Product Owners, Business Owners, Project Managers) should be aware of what was developed, what was tested, what wasn’t tested, along with relevant and valuable information discovered during testing so that they can make the appropriate decision regarding the feature or application.

A good understanding of what Software Testing is and what it should set out to accomplish – the mission, goals, and purpose is something those with an influence on testing activities within an organization should be aware of – as it may dictate how valuable testing time is spent.