A tester made an interesting observation yesterday; all the testing job positions she came across required test automation experience.

She then stated, all the companies she has worked for have attempted to use test automation but have failed.  And even though she was involved in said test automation, she has yet to accumulate a test automation success story, the kind she might tell in a job interview.…unless she lies, of course (which I suspect is common).

This paradox may not exist in software companies (i.e., companies whose main product is software) because they probably throw enough money at test automation to make it successful.  But those of us working in the IT basements, on the shoe string budgets, of non-software companies, find the test automation experience paradox all too real.

...a feeling of accomplishment, directly related to my work ethic.

Back in the dark ages, with Scrum, the fruits of my testing were only given to my users once a month. It was awkward to stop testing FeatureA and start testing FeatureB because I felt no sense of closure with FeatureA. There was always a feeling that if I thought of a new FeatureA test, I could cram it in. It was a very non-committal feeling. Often, the feeling was, “I’ll finish these tests later”. And as the end of the iteration approached, it became, “wow, where did the time go?”.

With Kanban, when I complete FeatureA’s testing, it goes straight to the users. I feel a sense of accomplishment. The production deployment is the reward for my hard work…the closure…full commitment. I feel I am in complete control over how quickly FeatureA moves through development. The harder I work at it and the better I test, the more I focus, the quicker it goes out. I’m motivated to “get ‘er done”, as they say here in the south. But I also have the freedom to do more testing, if we need it.

…doing my tests in a focused chunk, then never again!

Back in the dark ages, with scrum, we would do the bulk of our testing in a development environment.  At some point near the end of the iteration, we would wrap everything up in a build, deploy it to a QA environment, and test some of the items again…enough to make sure they were deployed properly and played nicely with other critical features.  Once in QA, we had to dig up previously executed tests, set then up again, and try to remember what we had previously learned about our tests weeks earlier.

With Kanban, we complete our testing in focused chunks.  We still do the bulk of our testing in the development environment.  But when we’re done with that feature, we deploy it (that same day) to a QA environment, and do any additional testing immediately.  This is soooooooo much easier because the tests are fresh in our minds, our SQL scripts are probably still open, and other recent tools are all prepped and ready to go.  When we’re done, we deploy to production and those tests can leave our minds (sometimes forever) to make room for the next Feature.

A Test this Blog reader asked,

“Every few years we look at certifications for our testers. I'm not sure that the QA/testing ones carry the same weight as those for PMs or developers. Do you have any advice on this?”

I’ll start an answer by telling you my opinion and maybe some of my readers will respond to finish.

The only software testing certification I’ve tried to get was from IIST. Read my post, Boycott the International Institute for Software Testing, to understand why I gave up. 

Ever since, I’ve been learning enough to stay engaged and passionate about software testing without certifications.  I’ve been learning at my own pace, following my own needs and interests, by reading software testing blogs, books, thinking, and attending about one testing conference (e.g., CAST, STAR, STPCon) per year.  My “uncertified” testing skills have been rewarded at work via promotions, and this year I will be speaking at my third test conference.  This pace has been satisfying enough for me…sans certifications.

I tend to follow the testers associated with the Context Driven Testing school/approach. These testers have convinced me certifications are not the best way to become a skilled tester.  Certifications tend to reward memorization rather than learning test skills you can use.  The courses (I’m not sure if they are considered certifications) Context Driven Testers seem to rally around are the online Black Box Software Testing courses, Foundations, Bug Advocacy, and Test Design.  I planned  to enroll in the Foundations course this year but I have my first baby coming so I’ve wimped out  on several ambitions, including that.

So, as a fellow Test Manager, I do not encourage certifications on my testers.  Instead I encourage their growth other ways:

• This year we are holding a private Rapid Software Testing course for our testers.
• I encourage (and sometimes force) my testers to participate in a testers-teaching-test-skills in-house training thing we do every month.  Testers are asked to figure out what they are good at, and share it with other testers for an hour.
• We have a small QA Library.  We try to stock it with the latest testing books. I often hand said books to testers when the books are relevant to each tester’s challenges.
• I encourage extra reading, side projects, and all non-project test-related discussions.
• We encourage testers to attend conferences and share what they learned when they return.
• We attend lots of free webinars.  Typically, we’re disappointed and we rip on the presenters, but we still leave the webinar with some new tidbit.

So maybe this will give you other ideas.  Let’s see if we get some comments that are for or against any specific certifications.

You’re probably a good leader just to be asking and thinking about this in the first place.  Thanks for the question. 

I believe testers have the power to either slow down the rate of production deployments or speed them up, without adversely affecting their testing value.

1. My test career began as a “Quality Cop”.  I believed a large responsibility of my job was preventing things from going to production. 
2. After talking Michael Bolton’s Rapid Software Testing class, I stopped trying to assure quality, stopped being the team bottleneck, and became a tester.  At this point I was indifferent to what and when things went to production.  I left it in the hands of the stakeholders and did my best to give them enough information to make their decision obvious.
3. Lately, I’ve become an “Anti-bottleneck Tester”.  I think it’s possible to be an excellent tester, while at the same time, working to keep changes flowing to production.  It probably has something to do with my new perspective after becoming a test manager.  But I still test a considerable amount, so I would like to think I’m not completely warped in the head yet.

Tell me if you agree.  The following are actions testers can do to help things flow to production quicker.

• When you’re testing new FeatureA and you find bugs that are not caused by the new code (e.g., the bug exists in production), make this clear.  The bug should probably not slow down FeatureA’s prod deployment.  Whether it gets fixed or not should probably be decoupled from FeatureA’s path.  The tester should point this out.
• Be a champion of flushing out issues before it hits the programmer’s desk.  Don’t get greedy and keep them to yourself.  Don’t think, “I just came up with an awesome test, I know it’s going to fail!”.  No no no tester!  Bad tester!  Don’t do this.  Go warn somebody before they finish coding.
• Be proactive with your test results.  Don’t wait 4 days to tell your stakeholders what you discovered.  Tell them what you know today!  You may be surprised.  They may say, “thanks, that’s all we really needed to know, let’s get this deployed”.
• Help your programmers focus.  Work with them.  I’m NOT talking about pair programming.  When they are ready for you to start testing, start testing!  Give them immediate feedback, keep your testing focused on the same feature.  Go back and forth until you’re both done.  Then wrap it up and work on the next one… together.  When possible, don’t multi-task between user stories.
• Deployments are something to celebrate, not fear.  This relates more to Kanban than Scrum.  If you have faith in your testing then don’t fear deployments.  We have almost daily deployments on my Kanban project now.  This has been a huge change for testers who are used to 4 week deployments.  Enthusiastic testers who take pride in rapid deployments can feel a much needed sense of accomplishment and spread the feeling to the rest of the team.
• Don’t waste too much time on subjective quality attributes.  Delegate this testing to users or other non-testers who may be thrilled to help. 
• Don’t test things that don’t need testing.  See my Eight Things You May Not Need To Test post.

Every other development team is running around whining “we’re overworked”, “our deadlines are not feasible”.  Testers have the power to influence their team’s success.  Why not use it for the better?