Balancing Documentation With Speed

I’m sitting here thinking about my career over the last decade or so, thinking about how things once were, and how things have changed. One thing stands out to me: how much faster things are now. How fast we build, how fast we release, how quickly we have to test, how quickly we have to write. How do we balance documentation (which, let’s face it, could take a lot of time) with the need to get things out the door? How do we keep up in the continuous pipeline? It comes down to having a centralized strategy that consists of best practices, how to get through your day-to-day work, and working as a team to know what needs to be tested.

One thing I’ve found that has helped to save time is to have a centralized space to reference when nothing really changes in HOW things need to be tested. These are things that do not change across projects or releases and should be considered as long-term and used as a reference. We used to do this for each epic and it drove me nuts — it ultimately led to tons of strategies with duplicate information throughout. Now, we have a reference wiki space and go over strategies that everyone (not just QA) should be familiar with. These strategies should also be a part of passing acceptance criteria, and your engineers need to know these strategies as well.

Here is a sample of what we have focused on as the general strategy does not change frequently, and things to consider when defining it: [table id=4 /] Having a centralized space handy and only explicitly calling out when things change saves time towards your continuous delivery model. To track the work, we use checklists embedded in our stories for definition of done and acceptance criteria, and we cannot close the story until they are considered complete. Instead of having to write a separate strategy for each of these common practices, we now simply reference them and ensure they are done.

Of course you will have to write tests with the feature you are building, but one thing I have seen evolve over time is the size of the specification. Ten years ago this could have been 50+ pages defining the entire feature. Trying to digest that and create a test plan took forever, and usually generated more questions because it was a very Waterfall world, and the team was just handed the specs. Times change. Now, we are looking at extremely small stories, which helps us focus on what needs to be tested. As your team defines acceptance criteria together, it is easier (and faster) to design your tests on a small piece of functionality vs. the entirety of the feature. I’ve seen my tests plans dwindle from long-winded documents to very short tables of Given/When/Then statements that I can complete in a few hours. When we are in a world of Test Driven Development, I think we’ll see even less documentation as those tests become the driver of the code. We also recognize that our goal is to automate as much as we can (as makes sense). What we initially define is not a living, breathing document. It often serves as just enough to get through a sprint and get QA, ENG and Design on the same page, but is not maintained throughout the life of the product. If there is a change, we simply write a new manual test or edit the existing automated script as part of the change request or story.

The need for everything to become even faster is not going away in the Continuous world. How do YOU balance writing tests and getting things delivered in a constantly shortened timeline?

Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices.  Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen.  In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.