This, I’m afraid, is how testers (myself included) often see software modules…like black boxes. Their relationships are hidden from us. We know the programmer just changed something related to the seeds inside the orange, so we ask ourselves, “How could changing the seeds inside the orange affect the toaster?”. Hmmmm. “Well, it sure seems like it couldn’t”. Then, after a deployment, we’re shocked to discover the toaster starts burning all the toast.

Why didn’t the programmer warn us? Well, just because the programmer understands the innards of the orange, doesn’t mean they understand the innards of the toaster. In fact, based on my experiences, if there is enough work to do on the orange, the orange programmer will happily take it over learning to code for the toaster.

So here we are, left with nothing better to do than regression test the toaster, the jointer, and the flash light, every time the orange changes. No wonder we spend so much time regression testing.

In conclusion, maybe the more we learn about the architecture behind our software system, the fewer regression tests we’ll need to execute. Instead, we’ll better focus our testing and make the invisible relationships visible for the rest of the team…before development even begins.

I’m trying to fill two technical tester positions. It’s exhausting. All the resumes are starting to look the same. They all tout:

Extensive knowledge of the SDLC. Who cares? I’ve been testing for 15 years and I’ve never encountered a situation where extensive knowledge of the SDLC has come in handy…I’m not even sure what it is. Who is motivating this? Are there that many Test Managers out there saying, “what we really need, is a tester who knows the SDLC”?

Understanding of test automation tools like QTP?“Understanding of”?

Ability to map test cases to requirements in Quality Center.It’s been 6 years since I’ve seen Quality Center but I don’t recall it being that difficult a task.

Performed different types of tests like Functional, Regression, Smoke, UAT, White Box, Black Box, Grey Box, and End-to-end. Darn, I was really looking for someone who could write “integration tests”. Oh well.

One resume said:

Extensive QA experience via hands-on testing? Is there a way to gain experience without being hands-on?

Another said:

Fixed tested bugs and coordinated with developers in release of bug fixes during every Sprint Run.Hmmm. Perhaps you should start by testing your resume verbiage.

During an interview I asked:

Me:According to your resume, you worked on a team using Test Driven Development. Was it effective?Candidate:Oh yes. At the end of Sprints, if the developers had time, they would write some unit tests for Stories we were about to release to production.

During another, I asked the following easy question:

Me:What are some attributes of a good bug report?Candidate:Documenting the bug is the most important attribute.

Finally, after an interview with me, for a programming position, the candidate remarked, “That’s odd, I’ve never seen a man in a QA role.”. It reminds me of a little post I made years ago that almost lost me some friends.

BTW - If you live in the Atlanta area, have excellent DB and SQL skills, and are capable of testing something without a UI, please drop me a note. I may have an awesome job waiting for you.

Who am I?

My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.