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.

In Part 1 of this topic I wrote about the experiences that made me realize that Software Testing is not repetitive.  These are my experiences from over 7 years ago when I first started my career in Software Testing.

When I began to realize that skilled Software Testing was not a repetitive job, but one that required and made use of different types of skills & knowledge and was a thinking persons job – I immediately knew I wanted to become a skilled Software Tester.  I didn’t yet exactly know what that entailed, or how I would start my journey on becoming one, but that didn’t matter – I knew where I wanted to go so to speak and now I would work on getting there.

I saw two types of Testers (there are a lot more but for the scope of this post I’ll stick with two); those who wrote and ran the same test cases over and over & those who used different testing skills, knowledge, experience in their testing to find some great bugs and report valuable information.  The latter were the ones other individuals (testers, developers, product owners) would go to for input on how & what to test. They were the ones who would themselves go to ask developers for information, find information using different channels that were available to them.  They didn’t tell other testers what to do, but made themselves available to them as a good source of knowledge.

I was assigned to and chosen to test more “complex” projects – this is what led me to start working on testing different types of applications. By “complex” I mean testing applications for which there were no pre-existing test cases. Applications that nobody within the Testing Team knew much about in terms of functionality and technicality. I would talk to (ask questions) and work with developers and data analysts to determine what the application did, how it would be used and most importantly (and a learning experience for me) how I was going to test it.  I wasn’t just testing the application from the UI, I was now testing different components that made up the application.  I enjoyed being assigned and chosen for these projects.  Not only did I work hard to be the one the test manager chose for these projects but I showed that I wanted to learn and was both willing to and able to do so.

From this point on; about 7-8 months into my Testing career I knew that I wanted to learn more, get better at what I did and not just sit and execute the same tests over and over – a job that a robot would be able to do or even somebody with less knowledge & skill than me could do.