Test-driven development (TDD) approach
The problem in many of the development teams is that testing as a whole is done in a such ambiguous way just to be able to say it was done. Same story applies for Test-driven development (TDD), people pretend doing TDD but they don’t.
At some point I was part of a scrum team where we did try to implement TDD but there was a big gap between the developers and the QA,the mistake that we made was something that I wrote about in a previous article here :
In my belief people should look very serious in adopting TDD rhythm:
Test > Write code > Refactor
Your process should look something like this :
Share testing roles
Make sure testing role is not just a final stage before the code goes live and when it happens everyone feels a big relief , share the role in the team , adopt pair programming in writing tests between developers and testers.
Use team conventions
I feel on the team convention is more to discuss about so I will cover more details in a next article but till then make sure you guys are on the same page in regards of :
- Selector usage
- Test structure
- Page structure
I know , we as humans being , have the ability of the mind to be creative or resourceful and our imagination can go above the sky , but without prototypes you would miss important things to consider before taking the task into your sprint.
- Design images
- Design mockups
Tests drive page structure
Don’t rush to create your page structure before you don’t have your tests . Allowing your tests to drive the page structure might change the game completely.
In the next article I will talk about team convention in a TDD environment.