Stories from a Software Tester

I recently talked about testers writing tools. That particular tool, however, was a simple script. You can definitely improve your career options by being able to write more substantive tools.

As a tester I’ve recently had to start writing some Ruby programs that would serve as effective test frameworks. As it turns out, it was best for me to package up my logic in the form of a Ruby gem so that I could allow others to install it easily along with any dependencies.

Continue reading Testers Write Tools — Sometimes With Gems! →

I was in an environment where it was clear some of the testers were struggling with the idea if comparing Excel workbooks: either as actual Excel files or CSV files that were imported into Excel. Expensive automation tools were being used to try to handle some of this. What I immediately thought of is simply: this is why testers do need to have some technical skills in the programmatic arena.

Continue reading Testers Write Tools — Even Simple Ones! →

I like to consider a strategy and tactics distinction when you have a test team that’s striving to operate within the sphere of quality assurance. When you have that situation, then operationally considering strategy and tactics (or logistics, if you prefer) becomes important. The emphasis needs to be on a gradual implementation of good testing practices that then filter up to a full quality assurance process. Since any such quality function, in my opinion, starts with good testing practices of some sort, I’ll mainly make my distinctions here in the context of the idea of testing.

Continue reading Put Some Heuristics Between Your Strategy and Your Tactics →

I previously talked about test strategy and I made it clear that in my opinion the test strategy and the test plan are two entirely different things. I’ve had a love-hate affair with test plans over the course of time, mostly because I’ve seen them become an end unto themselves. I’ve seen them become monolithic documents that people who need a sense of control use when they feel they can’t get that control in more effective ways or can’t deal with projects that are more fluid in nature.

But I wonder if I’m too reactionary in nature on this topic or if I’m just reacting to seeing a lot of badly written, rarely read test plans.

Continue reading Does Planning For Testing Require a Test Plan? →

I see a lot of testers — and their managers — misuse the phrase “test strategy.” I say they misuse it not because they don’t agree with some definition I have but rather because I rarely see a good distinction made between test logistics and test strategy. I often see a test strategy equated with a test plan. I hear some testers say that having a test plan is part of your test strategy. I hear others say that it’s the job of the test plan to indicate the test strategy.

So let’s talk about test strategy a bit.

Continue reading Your Test Strategy Is A Framework →

In my post “Can I Function Test My Units?”, I talked about how testers often promoted a misuse of the phrase “functional testing.” I’ve found the same thing happens with the phrase “performance testing.” What I’ve found is that many testers don’t realize that performance testing, just like functional testing, is a test approach. This means there are various testing techniques that you can apply to the approach. If testers don’t have this kind of focus, I believe that the purpose of performance testing can be lost.

Continue reading Can I Stress The Load On My Volume? →

Many testers entering the field get nervous when they consider the need to test at different levels of an application, particularly if that involves working with developers. Many testers will enter into environments that claim they are practicing Test-Driven Development (TDD) and/or Behavior-Driven Development (BDD). What I want to do here is show that this stuff isn’t really all that scary and it’s really not that arcane. Further, if you want to be competitive as a tester and continue to add value, it’s in your best interests to learn what it means to test at different levels.

Continue reading The Art of Testing at Different Levels →

Many testers will tell you that they eventually had to work with their development group to draw the line between unit testing and functional testing. This, of course, implies that there is some sort of a difference between the two. And, in fact, if you go by the literature — professional or otherwise — of the testing industry, there supposedly is a difference.

I’ve just never liked that fact because “functional” is such a broad term. To my way of thinking, unit testing is a form of functional testing. I think testers who use the term “functional” as a separating category within tests are stuck in an “old school” mode of thinking.

Continue reading Can I Function Test My Units? →

I think the question of what makes testing a complicated discipline is a good one. It’s one all testers should be able to answer about their profession and, further, answer in a way where the answer couldn’t be applied to just about any other profession. The problem I’ve found is the answers you get are usually simplistic. You’ll hear people say “miscommunication” or “unrealistic schedules.” Well, that’s great but miscommunication can make any profession difficult as can an unrealistic schedule or poor estimating. I bet day traders, doctors, police officers, lawyers, military strategists, nuclear power plant operators and so forth could make the same claim.

Surely we can do better than that, right?

Continue reading What Makes Testing Complicated? →