I’ve heard a lot of people in the software industry say that “testing is more art than science.” My opinion is that people who say this most likely know little about art and probably know even less about science.
Month: November 2011
Good Testers Think Operationally
When a professional discipline has a vocabulary for expressing the fundamental concepts on which it’s based, then you have a means for how practitioners in the discipline can make sure they’re talking about the same things. The problem with establishing such a vocabulary is that many people have come to use a variety of different terms or, even in those cases where the terms are the same, the definitions used are different. This is why I like to encourage people to think operationally.
So why are so many testers I meet so bad at this? Is this just not something they’re encouraged to do? Or am I just being too picky about how people use terms?
Starting to Tame Capybara
Capybara is one of those open source testing tools that, when you get to use it, is really nice. However, it’s new enough (or, at least, changing enough) that good documentation on it is a bit sparse when your goal is simply to get started and you don’t have a lot of supporting frameworks in place. Case in point: what if I want to test against a browser that’s displaying my web application? I’m not using Rails. I have no other automated test frameworks in place. I just need to get started as quick as possible to determine if this tool will do what I need.
I’ll show you how I started out here.
Testers Write Tools — Sometimes With Gems!
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.
The Ubiquity of Ubiquitousness
I really enjoyed the book Ubiquity: Why Catastrophes Happen by Mark Buchanan. This book doesn’t talk about quality assurance or testing at all, but it does talk about how things can change very quickly and how a certain context can dictate how things change. I definitely recommend the book for anyone working in a software development context because I found I could abstract ideas out of the context that the book talks about and apply them to the idea of change initiatives, faulty software, and the social context of software engineering environments I have worked within.
I’ll distill a little bit of what I got out of the book here, in the hopes of encouraging you to read it.
Action Sets in QTP
Assume you have some data that tells your scripts how to function when they run a particular set of actions. Instead of this logic being stored in a test script, common action sets are stored off in a data source. In this case, I’ll use Excel but you can use any data source at all. One thing I’ve found fairly effective in terms of an approach here is to create a class that contains the methods for building a dictionary that will essentially bring in the “action sets.” Here an action set refers to the data plus the test actions to take with that data against the application.
Testers Write Tools — Even Simple Ones!
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.
Put Some Heuristics Between Your Strategy and Your Tactics
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
Does Planning For Testing Require a Test Plan?
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?
Your Test Strategy Is A Framework
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.