Due to COVID 19, all workshops and courses are remotely given for the foreseeable future.

Janet Gregory: Agile Consultant, Trainer, Advisor, Writer, Speaker

Testing And Coding, Not Coding “Then” Testing

code then test quote

This quote was recently published with the question “Hmm😶 What’s your take on this?” You can read some of the comments here.

It made me realize that I should probably write a blog post so that people don’t take out of context what I mean. The quote is “almost” correct, but not quite. One word makes all the difference in the world sometimes.

The quote people most likely hear me say is:

“Throw away the ‘then’ in ‘code then test’ – replace it with ‘and’. And maybe, also reverse the order to say, ‘test  AND code’. Put the test first.”

This came about because teams don’t think about the term ‘code then test’ as a problem. But every time someone says that phrase, it reinforces that testing comes after coding.

Testing and coding shouldn’t be separated as stand-alone activities. They are part of the same development process. Code is not complete without testing – at least some kind of testing, although some testing activities can be completed without writing any code. An example of this might be when we do an experiment or a simulation to test an idea and the team decides not to follow-up.

I was chatting with Paul Seaman about the Linked-In conversation because I saw his name in one of the comments. He was surprised with some of the comments from folks. He asked, “Why do people think BDD and TDD are about testing? Both could be activities which help and influence testing choices but are not testing.”

TDD – it is about design and building testability into the code. BDD (behavior-driven development) and ATDD (acceptance test-driven development) are about getting shared understanding about what we are going to build. That said, I look at as these practices as testing activities since we are testing ideas and assumptions. It is a testing activity that the whole team can participate in to help make sure we understand the feature or story.

This leads into the next point that Paul was concerned about. Sweeping statements such as “the best and most efficient way to avoid bugs in code is to test the requirements” may put emphasis on the wrong thing. For example, the assumption that “better requirements (whatever better might mean) automatically reduces coded bugs” doesn’t hold for him. I like his thought that “Better quality software requires a holistic goodness in systems of development not a singular focus.”

Paul and I have shared many conversations over the past year, and we’ve discussed many of these themes. We both agree the Linked-In thread could have been a great discussion about collaborating through the lifecycle of development – how we influence, assist, and try to make sure the product that build, ships successfully.

It’s not about testing specific aspects like requirement, or code. It’s about how can we give fast feedback. It is one of the reasons, I created this diagram trying to show continuous testing.

shift left shift right diagram

I was influenced by Dan Ashby’s continuous testing model, and I am not completely happy with it yet, but it’s a start. For example, it’s not obvious to everyone what testing activities are happening in the formulate and build section. We need to have fast feedback and practices like ‘show me’ to have the programmer show what he/she coded so bugs can be found quickly and fixed immediately.

In summary, testing is an integral part of the whole development and cannot be separated from the coding aspect of building a product. I think one of my new quotes will be:

quote

 

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Leave a Reply

Your email address will not be published. Required fields are marked *