This website uses cookies. By using our website, you agree to the use of cookies.

banner blog

/

08.02.2018

To structure, or not to structure, that is the question (for agile testing)

A common prejudice concerning agile that was spread ca. 2010 was that it is not very structured and that you need not to document anything. And like any prejudice, it can hardly be removed and you can still hear it in 2018.

Although, in my perception, the focus has shifted away from frameworks like Scrum or Kanban (which are more or less mainstream by now) to certain practices in the agile world such as refactoring or agile testing. And sorry to say, but if you think that these practices are unstructured and need no documentation, well, you are wrong again. Oh wait, that is not totally true. It pretty much seems to me that many people think that agile testing is quite the same as testing in a more classic environment.

What do I mean by that? Well, often people still want testers to write heavyweight test plans or very detailed test cases - weeks or months in advance of course and probably in a tool that most people do not even take time to look at because it has also shown itself as heavyweight. So the misunderstanding that no structure and/or documentation is needed has somehow not found its way into agile testing. This is in itself a good thing. The mere thought that you still need all the big upfront structuring and planning is probably not as good. At least not for me.

This often goes along with something like „oh, we paid a lot of money for the tool, so we need to structure everything as the tool suggests us to do so“. This kind of thinking has some merits if you think of agile testing being isolated from agile development, but even then it is somewhat questionable. If you think of agile testing as being a part of agile development (that’s what you do, right?), this kind of structuring probably does not help you delivering value to the customer as quickly as possible.

So how should agile testing be structured then?

Simple answer: it depends on your context!

But in fact this answer is not so simple: It really depends on your context and you should take the following ideas into consideration:

 

1. Adapt it to your development process

You have certainly spent some time thinking about you development process and your testing process should be an integral part thereof.

Are you doing TDD? Fine, how do you need your tests documented? Do you pair on these tests with testers and developers? Do you need those tests documented outside of the programmed tests? I am asking this because I have seen projects where even these tests needed to be documented in a tool beforehand, despite the fact people then paired on with writing them and never looked at those documentation parts again, just at the executed tests.

Do you use gitflow or some other workflow? The structure of your testing should follow that. I think it is a good idea to do all your testing on feature branches and have only regression tests running on the develop branch. 

 

2. Don’t be a slave of your tool

Some of the tools out there are pretty heavyweight and it takes a lot of time to set them up and keep them running. Ask yourself if you really need all of that or is a leaner approach just as good? Sometimes there are plenty of input boxes configured into highly customized screens and after a few years no one really knows what these are good for, but they need to be filled as they are mandatory. Instead of using your time for testing and having the tool support you, it blocks you from doing your work. What I like to do is to have a regular check on tooling to see what I really expect from a tool to support me. What is necessary? What is maybe mandatory because of my context? In most cases you can trim down on what you have and you still get whatever you need.

 

3. What documentation do you need

There is a popular joke among testers that goes like this:

Project manager: „Can you show me your manual testing script?“ Tester: „Sure, if you show me your project managing script first.“

This doesn’t mean that testing scripts don’t have any value. There are certainly contexts – like highly regulated medical environments – where manual scripts are needed. Or maybe you are writing tests for other people to execute where scripts might be helpful to a certain extent. In agile context that shouldn’t be the case too often, though. Especially when practices like pairing are promoted it is way better to extend those to testing as well. And if you put all the effort into creating those scripts, why not automate them? Document your ideas in leaner ways and communicate your thoughts and ideas while executing. Mind maps are pretty popular for this as they help you cluster your ideas. Whatever you choose, keep it lean and accessible.

 

4. Make your tests visible

Sometimes projects hide their testing documents in restricted repositories and therefore keep people away from important information. As with everything else in agile: Make it visible, if it creates value. But as always, keep it as lightweight as possible. The 3C principle of card, conversation and confirmation fits nicely in here as well – even if your card is an issue in a tool. You can’t put down everything. It will stall you and that is something we can’t afford in agile contexts. Chances are high that there is a lot of implicit knowledge on topics that can’t be documented at all.

 

To sum it up, there is not one way to structure your testing. But there are some common denominators which you should adapt to your individual working context and keep them lean and visible.

And maybe a tool like TestBench Cloud Services can help you to establish a lean approach!

 

Christian Kram for TestBench Cloud Services