Sunday 7 June 2015

Please, stop telling testers how to test!



Let me start with a scenario.

A programmer works away on a new feature or a bug fix. They finally feel like they're finished and it's time to move the user story over to a tester. They update the user story with an explanation of the work they did, any assumptions they made and one final thing: 
"Testing notes: Try exercising feature X by using entry point A as well as entry point B and assure that the output is the same."
Now let me explain my problem with this. I have a gut-wrench reaction when something like this occurs, because my first thought is, "Wait! If these scenarios have been identified as important, why didn't you try them?"

That's right. I'm proposing that if a programmer can identify a risk area, wouldn't it make sense that they ensure their code works under those conditions? Even better - shouldn't there be coded tests for these scenarios, if at all possible?

I don't mean to lay blame here. As far as I'm concerned, in development there is no "us" vs "them". "We" are a team. So if testing is playing out like this, it is up to everyone to correct it. But, I AM advocating that it gets corrected. Allowing testers to be told how to test is basically boiling down their job to executing steps that others don't feel like doing. It is removing what I believe is the core expertise of testers - to think critically and creatively about how features have been implemented, how they integrate, and how to stress the shit out of them!

So please, stop telling testers how to test - and start collaborating with testers on what to test! In an Agile environment, we have the luxury as programmers and testers to sit together and chat about a feature or a bug fix any time we need to. Theres a few times when these talks can be mutually beneficial and help us build the best products as quick as possible.

  1. Before programming begins: This is an excellent time to discuss what the problem being tackled is (new feature or bug fix), and how both parties see it being solved. The programmer can explain how they are going to approach the implementation of the solution and the tester can talk about how they plan to test it. This gives the programmer the chance to keep those scenarios in mind during development. It also gives the tester the chance the develop a test plan based on the intended implementation.
  2. Demoing before testing: When the programmer believes they're done, a brief demo to the tester can be extremely helpful. (In fact, you wouldn't believe how many times we've caught a glaring bug during these demos...BEFORE any formal testing has begun). This is an opportunity for the tester to ask about integration points, and think about how to exercise those.
    The other thing that could be discussed at this time...UNIT TESTS! Talk about what unit tests have been written and if any more coverage would be beneficial. If certain things aren't unit testable, the programmer can explain why that is the case and the tester can plan to focus on that area (since we know there's less coverage there than other areas).
  3. During development: And of course, in true Agile fashion, any point in time is actually a great time to talk about roadblocks that arise, and possible solutions! Keep the communication up and leverage eachothers' skills early and often! 
Tell me what to test. Tell me where to test. But please, don't tell me how to test!

Wednesday 14 January 2015

Looking beyond the titles (and an explanation of my QA CAN'T CODE movement)

In every facet of my life, I'm a self-proclaimed "jack of all trades, master of none". And being a jack of all trades often goes hand in hand with being a fast learner. While there are many people out there who identify their skills and abilities, and hone them to be a master of their craft, I am not one of them. However, I have always believed that this has actually been a key factor of my success in software testing. I have had experiences in software and hardware, script-directed manual testing and self-directed exploratory testing, planning testing and executing testing, reading and yes, even writing code. 

I have written at least some code in over 12 programming languages. Couple that with exposure to various frameworks at work, attending workshops and doing projects in my spare time and I'd say I have at least a basic level of understanding of some programming concepts. But I bet most of my coworkers don't know this about me. And why should they? - I am, by current title, a "Software Quality Assurance Specialist" and to most people that means I am a blackbox, manual software tester.

That is not their fault. It's a labelling issue. It's a perspective issue. Dare I say, it is a stereotype issue. I almost feel as though the industry has done a disservice by adding modifiers and variations to the title. Quality Assurance Developer, Software Developer in Test, Test Engineer - what do all these titles have in common? They perpetuate the belief that "typical QA can't code". And herein, I believe, lies the problem. 
If I am a Software Quality Assurance Specialist*, then I believe my specialty is anything that can help contribute to the quality of the product. 
This spans a far wider range than functional testing of features and products. If you look upstream in the development process, this means advocating quality in design meetings and helping build testability into new features. If you look in the "middle" of the development process, this could mean smart functional testing of the product or tool development to ease the workload with scripts or other tools. To me, smart functional testing means testing complex scenarios and applying automation where automation is best suited. Looking further downstream, the responsibilities could include being involved in the support process to analyze escaped defects, close the feedback loop and iterating over the whole testing process for constant process improvement.

I'm not advocating that every member of the test team should have all of these skills - that would be a little too Agile Utopian. But if you're a tester, building up your skills toolbox never hurt. So it would be wise to keep in mind the full range of areas where testers can contribute, and seek to improve skills across those areas. Then work your ass off to apply the skills within your current team, so that the rest of the team is aware you possess these awesome skills! I'm sure it will net you new and exciting challenges, more respect from your team members and leaders, and a bump in product quality (which surely no one is going to complain about).
I once volunteered to write an in-house tool that plugged into another system being used, in a language I had zero experience with. It was desperately wanted, but no developer time could be spared on it. I whipped up the tool, learned a new language in the process and in the eyes of management, "saved the day". Suddenly, that "Quality Assurance Developer" title I had been asking for was granted, and I was being given more time to work on tools, automation initiatives and more!
Anyways, the point is that titles mean nothing - so don't let the lack of a "developer" title stop you from learning to code and finding ways to apply that. In a previous post, I revealed that I've chosen to use the phrase "QA CAN'T CODE" (ironically, of course) - because QA can and should code, among many other things.



*Despite being a Software Quality Assurance Specialist, I typically don't associate with the term "QA". I usually try to refer to myself as a Software Tester.

Monday 12 January 2015

A rant - QA CAN'T CODE

So...this is happening:


I've heard it too many times. So now I plan to wear it in irony. There's this notion that lingers and hasn't been dispelled yet - one that perpetuates the belief that "QA can't code". 

I'd like to send two messages with this simple statement.
  1. This is a push for a re-branding. I am not a fan of the job title QA (aka "Quality Assurance"). I've said it before - "I don't assure quality; I test software." Maybe quality inspectors can't infact write code, which is fine. But then I don't want to be a quality inspector.
  2. This is also meant to be an ironic statement to spark a discussion. Why can't QA code? I'm a QA Specialist by title..and I can write code. So why then do I often hear amongst the industry that writing code is reserved for developers? In the modern "Agile" era, where every member is responsible for every stage of the development process in one capacity or another, QA can code. Infact, QA should code!

There's a larger and more well thought out blog post to follow on this topic. For now, I'm just going to mention that these shirts will be available for sale (at no profit to me) for anyone that agrees, and feels like making this bold statement with me.

*EDIT*: Design has changed thanks to a suggestion from Jim Hazen!