In my previous post on human and automated testing working together, I showed an example of test design by humans that could be executed by automation. However, the focus point was making sure that the automation helped the humans adhere to an unambiguous domain model of what is being tested. Here I’ll follow up on that practical example with some of the theory.
Category: BDD
Human Test Design, Automated Test Execution
One of the obstacles to covering the gap between principles of testing and the practice of testing is the mechanics of writing tests. This is particularly the case if you work in a business domain with a lot of complex business rules. This is even more particularly the case if you want to use automation. So let’s dig in to this a bit with a case study.
Continue reading Human Test Design, Automated Test Execution
Levels of Description
I’ve talked about the notion of test description languages quite a bit. A lot of these discussions get into debates about being declarative versus imperative, or focusing on intent rather than implementation. All good things to consider. But such “versus” terminology tends to suggest there is a “right” and a “wrong” when often what you have is “What makes sense in your context.” And you may have to flexibly shift between different description levels. Let’s talk about this. Continue reading Levels of Description
BDD Tools for Human Engagement and Test Purpose
Awhile back I wrote up some context around the question of Is Cucumber Truly Misunderstood?. There is a wider concept here that makes these tools quite applicable in the modern testing context, so I want to cover that here.
Continue reading BDD Tools for Human Engagement and Test PurposeThe BDD Lure and Trap
The whole notion of BDD is something I’ve talked about in a series of posts. I recently did an exercise with a group of business users, testers, and developers. We used a contrived example but the example was certainly a realistic portrayal of the activities that tend to occur on “real” projects. So let’s talk about that.
Continue reading The BDD Lure and TrapGood Tests vs Bad Tests with Description Languages
I’ve talked about “being lucid” and using description languages before. I have a whole category here devoted to TDL (Test Description Language) and I’ve worked to present examples that are not your standard “shopping cart”. In this post, I’ll cover an example of how I helped testers go from a “bad test” to a “good test.”
Continue reading Good Tests vs Bad Tests with Description LanguagesAbstraction Levels for Tests
Previously I talked about the testing craft and abstraction and here I’ll expand on those thoughts a bit more.
Continue reading Abstraction Levels for TestsThe Testing Craft and Levels of Abstraction
Previously I had talked about the craft of testing, focusing on the balance between the creativity of an artist and the methodology of a scientist. In both cases, however, the focus is on communication. To that end, it’s imperative we can express what we test in good English. (Or whatever the native language of your environment is.) So let’s talk about this key skill.
Continue reading The Testing Craft and Levels of AbstractionWhy Cucumber? Why Gherkin?
Many people feel that tools like Cucumber are a waste of time. But are they? Let’s talk about that.
Continue reading Why Cucumber? Why Gherkin?Is Cucumber Truly Misunderstood?
I’m tired of hearing how “Cucumber is misunderstood.” If that’s the case then it’s terribly ironic that a tool that is supposedly all about revealing intent did such a bad job of doing this for itself such that it’s become completely “misunderstood.”
Continue reading Is Cucumber Truly Misunderstood?BDD Specs and Parameterizing Phrases
If you plan on using a BDD tool (like Cucumber, SpecFlow, Behat, etc) you are going to want to have some guidelines for how and to what extent you allow parameterized and conditionalized phrases. This is an area that I’ve found can become a rat’s nest of bad habits unless you establish early on how much and to what extent to use these features.
Continue reading BDD Specs and Parameterizing PhrasesA Spec-Based TDL Primer
There are many references out there that discuss Gherkin, which is a structuring element for your test description language (TDL). So what I’ll be offering here is really nothing new. This post is simply a relatively concise look at the TDL pieces and parts in terms of how these elements can be used in the context of Lucid or related tools.
Continue reading A Spec-Based TDL PrimerSeeking Conditions in TDL
Regarding my post on Seeking Requirements in TDL, a comment was made regarding the question of whether or not I was focusing on the conditions as part of the scenario and whether or not this tied into how I view requirements being made manifest in a test spec. The answer to both questions is “yes” but since that response may require a bit of elaboration, this post is my attempt at that.
Continue reading Seeking Conditions in TDLSeeking Requirements in TDL
Regarding my previous post on this subject, a tester I work with asked me a great question regarding the readability of the TDL and the ability to discern the actual requirements from it. This post is essentially what my answer was. Whether my answer is good or not is up to the individual reader.
Continue reading Seeking Requirements in TDLA TDL Communicates Intent and Describes Behavior
The goal of a Test Description Language (TDL) is to put a little structure and a little rigor around effective test writing, where “effective test writing” means tests that communicate intent (which correspond to your scenario title) and describe behavior (the steps of your scenario). Since those attributes should be what all statements of requirement strive for, this means that requirements and tests, at some level of approximation, can be the same artifact. That “level of approximation” is the point at which you get down to specifying the behavior that users find value in.
Let’s dig into this a bit more. Continue reading A TDL Communicates Intent and Describes BehaviorCommunicating In a Test Description Language
A TDL (Test Description Language) is a constructed language that we use to describe, and thus specify, our requirements as tests. Or our tests as requirements, if you prefer. This is what allows testing to be a design activity. What makes a style of writing a TDL is adherence to a structuring element and a set of principles and patterns that are used to guide expression.
Current forms of TDL swirl around various BDD concepts, such as Given-When-Then. But it’s clear that just having that focus in place does nothing for you by itself because there is a lot of thought that goes into how you want to express yourself. I’ve found many testers really struggle with this but, equally, I’ve found I struggle in being able to adequately teach at what level you work at with a TDL.
Continue reading Communicating In a Test Description LanguageWhen Business Needs Become Specs That Become Code
There is a distinction I want to make in this post regarding what you change in a test specification and how a test specification itself my change, in terms of the role it provides. That leads into a nice segue about how team roles also change. Here by “test specification” I mean the traditional “feature file” of BDD tools like Cucumber, Lettuce, Spinach, SpecFlow, and so on.
Continue reading When Business Needs Become Specs That Become CodeTest Specifications and Fluid Test Writing
I have been introducing Cucumber to testers who have little exposure to such tools. I was looking at whether The Cucumber Book would be worth having around the office. And while it may or may not be, one thing I notice is that it (like most resources on Cucumber I find) don’t really address some of the heuristics regarding how you can start thinking about writing test specifications.
Continue reading Test Specifications and Fluid Test WritingSpec Workshops, Collaboration, and Test Writing
I’ve found myself in a position lately of having to explain a lot of concepts that are “obvious” to me. I found myself getting frustrated but then I considered my own words regarding the “obvious” nature of Quality Assurance and I realized that maybe I wasn’t establishing the context of what I was talking about. So I took step back and I started to look at whether many of the testers I work with and meet these days are aware of, much less practice, the idea of requirements being tests; of acceptance test specifications that drive development; of specification workshops. As it turned out, no, most testers were not practicing these concepts and many were not even aware of them as a shift in the dynamic of how testing can be done.
Continue reading Spec Workshops, Collaboration, and Test WritingSpecifying Application Workflow Activities
Lately I’ve been writing a lot of specifications and by that I mean test specifications. And by that I mean the specifications you tend to write in tools like Cucumber, SpecFlow, Lettuce and so on. What’s been interesting is deciding at what level of intent to write at.
Continue reading Specifying Application Workflow Activities