At the beginning of October, TestPlant graciously sent me to the STARWEST software testing conference in Anaheim, California. It was so nice to take some time away from testing, step back, and really focus on the trends, processes, and art of testing.
It was such an exciting time to be there! So much is going on and changing in the world of software test. That said, I definitely heard a few recurring themes, and a couple of those themes are “How do we optimize automation?” and “How do we implement behavior-driven development (BDD)?”
As far as automation goes, obviously, I’m a believer. But one of the things that was great about attending this conference was just getting a chance to talk with people about what they are doing and what challenges they face.
As far as BDD goes, on Thursday, I attended an excellent session on BDD and Test-First development methodologies, which was presented by Kevin Dunne of QASymphony.
In this session, Dunne described different types of test-first development as being technically focused, Unit Test-Driven Development (“Technical TDD”), and less technically focused, Acceptance Test-Driven Development (ATDD) and Behavior-Driven Development (BDD). He says the latter two are similar in that they try to make TDD more accessible to business users.
Dunne discussed how many of the constraints that kept us using older, inefficient methodologies, such as the waterfall, are no longer barriers. But despite the removal of old barriers and improvements in development methodologies, Dunne talked about how QA can still break down in an Agile development environment. Here he pointed out issues with QA, including communication (being “kept out of the loop”), being unable to complete tests when needed, working on different “cadences” than development, and a lack of visibility or understanding of when QA is “Done” with testing.
With these challenges acknowledged, Dunne went on to talk about the advantage of moving testing up front in the development cycle, with the key point being:
“Moving testing up front removes the risk of having to make compromises at the end of the cycle on quality or on-time delivery.” Who doesn’t want that?
Dunne continued describing how to implement TDD in an organization, providing tips and recommendations for doing so.
What I, as a tester, took away from this presentation was a lot of excitement about testing at the very beginning of the development process. Ideally, this includes development creating and refining features with testing. I understand that this requires development buy-in, and a huge shift in the process for developers. But I also see that this notion of TDD sets the expectation that testers should be involved and productive at the very beginning of the development cycle.
In our recent 16.1 eggPlant Functional release, we added support for Gherkin Features files. You create a feature file and write the steps for your test cases using the Gherkin Given, When, Then format. Then you can use eggPlant Functional to generate or re-use handlers in an associated script for each of your steps.
This facilitates the BDD and TDD processes by allowing you to begin to document and design your tests in one place as soon as you know about a new feature. Traditionally, testing user interfaces (UIs) was a task that had to wait until the coding was done. But with BDD or TDD and a Gherkin .feature file, you can begin writing your tests and generating handlers, even if they’re just place holders, with a basic understanding of the feature to be implemented. The more you learn about the feature, the more you can fill in, accomplishing the test design, test case and test in one place.
Despite my excitement about having learned about TDD, I am very new to working with Gherkin Feature files. I just started using them when we implemented this feature in our product. I must admit, at first, I found them to be a bit restrictive. But as I start to use them more, I find that they force me to think through what I am trying to accomplish with a test and be more concise and precise about my test steps. This is not a bad thing. Doing so puts me that much closer to having a test I can use.
So, armed with new knowledge and inspiration from STARWEST, I dive back into actually doing some work. I have some automation tests to finish and some new feature files to write.