I find it belittling…the notion that everything must be tested by a tester before it goes to production.  It means we test because of a procedure rather than to provide information that is valuable to somebody.

This morning our customers submitted a large job to one of our software products for processing.  The processed solution was too large for our product’s output.  So the users called support saying they were dead in the water and on the verge of missing a critical deadline.  We had one hour to deliver the fix to production.

The fix, itself, was the easy part.  A parameter needed its value increased.  The developer performed said fix then whipped up a quick programmatic test to ensure the new parameter value would support the users’ large job.  Per our process, the next stop was supposed to be QA.  Given the following information I attempted to bypass QA and release the change straight to production:

  • Testers would not be able to generate a large enough job, resembling that in production, in the available time given.
  • There was no QA environment mirroring production bits and data at this time.  It would have been impossible to stand one up before the one hour deadline.
  • The risk of us breaking production by increasing said parameter was insignificant because production was already non-usable (i.e., it would be nearly impossible for this patch to make production worse than it already was).

Even with the above considerations, some on the team reacted with horror…”What? No Testing?”.  When I mentioned it had been tested by a developer and I was comfortable with said test, the response was still “A tester needs to test it”. 

After convincing the process hawks it was not feasible for a tester to test, our next bottleneck was deployment.  Some on the team insisted the bits go to a QA environment first, even though it would not be tested.  This was to keep the bits in sync across environments.  I agree with keeping the bits in sync, but how about worrying about that once we get our users safely through their crisis!

As I watched the email thread explode with process commentary and waited for the fix to jump through the hoops, I also listened to people who were in touch with the users.  The users were escalating the severity of their crisis and reminding us of its urgency.

I believe those who insist everything must be tested by a tester do us a dis-service by making our job a thoughtless process instead of a sapient service.

When I was 6 years old, I went bluegill fishing with my uncle Kevin in Wisconsin. Uncle Kev knew how to catch bluegill and every time he got a bite, he handed me his fishing pole and said, “Tug the line!” then “Reel it in, I think you got one!”

I’ve been coaching a member of our support staff on a testing assignment. When she completed her testing, I ran some follow-up tests of my own and found a bug. Rather than logging the bug, I gave her some suggested things to try and hinted that there may be a bug. She found it! What a thrill! She also got to log it. Cool!

What’s the lesson?
  • As with fishing, testing without catching bugs can get boring. It’s important to let newbies catch some bugs.
  • When someone finds a bug you missed, it’s humiliating. When the tables turn and you find the missed bug, maybe it’s time to set your ego aside and put your coaching hat on.

The users found a bug for something that was marked “PASSED” during the test cycle. I made this remark to my programmers and one of them said “Ha ha, testers just mark tests ‘passed’ without doing anything”.
He was joking but he raised a frightening thought. What if he were right? What if you gave testers a list of 100 tests and they just marked them PASSED without operating the product? How would you know? The sad truth is, 95 of those tests probably would have passed, had the product been operated, anyway. The other 5 could arguably have been tested under different conditions than those deemed to raise the bug. And this is what makes testing both so unsatisfying to some testers and so difficult to manage.
If you can get the same result doing nothing, why bother?
We have an on-going debate about working from home. Let a programmer work from home and at the end of the day you can see what code they checked in. You have something substantially more tangible than that of a tester (even if that tester takes detailed test notes). It’s not an issue of trust. It’s an issue of motivation.
I believe testers who are uninterested in their job can hide on test teams easier than other teams, especially if their managers don’t take the time to discuss the details of what they actually tested. They may be hiding because they’ve never gotten much appreciation for their work.
Having a conversation with a tester about what they tested can be as easy as asking them about a movie they just saw:
  • How did George Clooney do?
  • Was it slow paced?
  • Was the story easy to follow?
  • Any twists or unexpected events?
  • Was the cinematography to your liking?
If they didn’t pay much attention to the movie, you’ll know.

I’ve got a test automation engineer and a bunch of manual testers. The plan, of course, is to teach the manual testers to write automated tests were appropriate; a plan I have seen fail several times. I figured I would take a crack at it anyway. In the meantime, I’m trying to keep the automation engineer busy writing valuable tests.
Everybody knows, choosing the right tests to automate is tricky. But what I’ve really been struggling with is finding the right skillset to actually design (determine the detailed steps) of each test automation candidate.
It turns out, the test automation engineers suck at it, and so do the manual testers. Who knew?
You see, manual testers live in a dream world, where test setup can be customized on the fly, validation can be performed with whatever info the tester decides is important at that moment, and teardown can be skipped altogether. Try asking those manual testers to stub out some repeatable tests to automate. I suspect you will run into a problem.
The test community loves to poke fun at traditional, script-happy, manual testers. Some testers (myself included) talk about exploratory testing or test case fragments as being the cool way to test. They scoff at testers who use rigorous step-by-step test cases. Have you ever encountered said traditional testers? I certainly haven’t. I’m sure they exist somewhere. But I think most of them only exist in a myth we’ve created in order to feel like test innovators.
Why am I such a skeptic about these folks? The truth is, writing repeatable, detailed, step-by-step test cases is really really really hard. If you’ve attempted to automate end-to-end business facing test cases for a complex system, you’ll know exactly what I mean.
On the other side, the test automation engineers are bored with manual testing and obsessed with trying to achieve the near-impossible ROI goals imposed by management. They want the manual testers to write them detailed tests because they don’t have time to learn the AUT.
A tester who makes time for manual testing and test automation has the magic skillset necessary to be an effective test automation author. Each of us should strive to achieve this skillset.

Have you seen this?
Type “psr” in your Windows 7 run prompt.
Click “Start Record” and every input you perform will get described, along with screen shots, then packaged into an MHTML zip file. The file can be viewed in IE or just as raw XML (for more details like mouse click coordinates). The little “Add Comment” feature is a good way to embed Expected vs. Actual results.

I used Problem Steps Recorder (PSR) today, to add details to one of my bug reports. PSR may also work as a personal test tracking tool. IMO, we can do a better job of capturing the relevant info ourselves in most cases. I rarely capture my entire screen and normally don't bother capturing steps unrelated to issues. Nevertheless, it's a good tool for your toolbox.

We encountered the following fixed bug today. Call it Bug100.
“The word ‘Unknown’ is spelled incorrectly in the dialog the user sees when sending an error report.”
Bug100 was spun off the larger issue (i.e., why the error was thrown). Bug100 was logged by a BA after noticing the spelling error, and easily fixed by a developer.
Unfortunately, the developer could not determine an easy way to trigger the error message described by Bug100. After a few failed attempts by the tester, the tester and I had a brief discussion. We decided to rubber stamp Bug100 and spend our time elsewhere. “Rubber stamp” is the expression we use to describe situations where the tester does not really do any testing, but they still move the bug report to the “Tested” status so its fix can proceed to production. We make a note on the bug report that says nothing was tested.
Would you have bothered to test this bug fix? Use the voting buttons below.

Would you bother testing this fix?

I promised I would post about my Lightning Talk, Programmer Profiling, per my Our First Tester Lightning Round post.
I came up with the notion of programmer profiling after listening to the Intelligence Squared podcast called “U.S. AIRPORTS SHOULD USE RACIAL AND RELIGIOUS PROFILING
The TSA is responsible for finding bombs among some 3 million people participating in 20 thousand US airline flights per day. The TSA takes heavy criticism from people who believe racial profiling is wrong. But the TSA also takes heavy criticism for the opposite, searching little old ladies and children. Some firmly believe racial and religious profiling is one approach that should be on the table. Based on prior terrorist attempts, searching old ladies may not be the best use of the TSA’s time.
I noticed some vague similarities between the TSA and software testers.
  • The TSA protects passengers by finding bombs among 3 million people.
  • I protect users by finding bugs among 3 million lines of code.
Then I realized I already practice my own form of profiling to determine which areas may need more of my test attention. I profile the programmers. Not just based on their prior code quality history, but also based on their current behaviors.
For example:
  • If I ask ProgrammerA how she tested something and she shows me a set of sound unit tests, and a little custom application she wrote to help her test better, I gain a certain level of confidence in her code.
  • On the other hand, if I ask ProgrammerB how she tested something and she shrugs and says “that’s your job”, I gain a different level of confidence in her code.
When the clock is ticking, and all other things are equal, where do you think I’ll focus my time?
As is the case with potential TSA racial profiling, it should only be used as one of many approaches to finding the problems. It should be balanced with other considerations. But perhaps it should be on the table.

I call this “Programmer Profiling” and I think testers should not be afraid to use it.



Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.