In my post Are We Defocusing Our Development and Test Practices? I was talking about the various “driven-development” terms. I had brought up how Behavior Driven Development (BDD) seems to have largely come about because some people felt that the term “test” was a bit too confusing for some people or, at the very least, off putting for some reasons that are not explained very well. There was thus apparently a shift to “examples” that talked about “behavior” and this was somehow different than a test. And this somehow made everything a bit better. But did it? What was it about the terms “test” and “testing” that were just not working? I’d rather people deal with that problem before thinking we need to come up with new acronyms. I say that because, ultimately, the concepts of a “test” and the activity of “testing” is still very much there.
Category: Testing
Are We Defocusing Our Development and Test Practices?
As a tester, you’ll hear about behavior-driven development (BDD). Sometimes this goes by acceptance test-driven development (ATDD) or maybe even acceptance test-driven planning (ATDP). You may hear that these are related to test-driven development (TDD). After a while you might start to wonder if these are just different ways of saying the exact same thing.
Continue reading Are We Defocusing Our Development and Test Practices?
What Can Time Travel Teach Us About Testing?
I have long maintained that testing is ultimately about thinking. A lot of your work is going to be predicated upon spotting incongruous elements (whether in documents or application code), resolving potential ambiguities in what you read or see, and dealing with potential inconsistencies or outright contradictions. Sometimes people will frame problems in such a way that your ability to “solve” or deal with the problem effectively is compromised from the start.
A good way to practice your thinking skills is to apply them in an entirely different arena than software testing.
Continue reading What Can Time Travel Teach Us About Testing?
Acceptance Tests Are Just Tests
Some testers have problems conceptualizing acceptance tests as I described them in my post on writing tests from stories. The problem seems to be one of seeing how the concept of an acceptance test applies or translates to concepts they already know, such as test conditions and/or test cases.
Be Acceptable: Write Tests from Stories
In my post on Stories, Features, and Acceptance Tests I talked about a lot but I didn’t really cover the acceptance tests themselves. The tests are quite important. Keep in mind that the goal is to have specifications that are clear, sufficiently testable and falsifiable, and in line with client expectations prior to significant development or testing. In essence, the idea is to work out how a system would be tested as a way to check whether the requirements give you enough information to build the system in the first place. You shouldn’t dive straight away into how to implement something, but rather think about how the finished system will be used — i.e., acceptable use — and then double-check the requirements armed with that knowledge.
Acceptance tests should reflect the customers’ perception of when the application meets their requirements. This does not mean that such tests must be defined by a customer or business analyst but it does often mean that such tests are discussed with them.
But how do you write them? What do they look like? Well, let’s talk about that.
Stories, Features, Acceptance Tests: Which Am I Writing?
If you’re a tester that works in an environment where your teams practice test-driven development (TDD), behavior-driven development (BDD), or some other variation that sounds really similar, you’ll quickly be learning that people toss around terms like “story”, “feature”, “acceptance criteria”, and “scenario.” What they often won’t toss around is the context for those terms. That’s context is important to have because it depends entirely on how the terms are used in your environment. While there are not necessarily standards, there are lots of good opinions that have led to good practices in context. Liz Keogh’s Acceptance Criteria vs Scenarios and Matt Wynne’s Features != User Stories are two good examples.
As a tester, what do you have to know? How involved are you in these things? Is all this just for developers? If you’re writing stories, are you also writing tests? Is acceptance criteria the same thing as an acceptance test? Here’s my take on a few of these questions.
Continue reading Stories, Features, Acceptance Tests: Which Am I Writing?
Testers Relax … You Don’t Really Assure Quality
As a tester the bad news is that you’re not assuring quality. That’s also the good news.
Continue reading Testers Relax … You Don’t Really Assure Quality
Why Do We Test? To Communicate, Of Course
“Perfection of means and confusion of ends seem to characterize our age.” So said Albert Einstein. I think that sentiment can be applied to tests and their role as a communication mechanism. When you get involved in projects that are focusing on “agile” approaches like behavior-driven development (BDD), I’ve found that you’ll want to make sure you keep focusing on how testing will have a focus on intent (what) as opposed to implementation (how). It’s easy for testers to fall into a group think mentality with developers, who are often pushing an agile focus with an emphasis on what amounts to quality of implementation rather than quality of intent. This means testers have to have a good answer to the question, “Why am I testing?”