Recently, I commiserated with a developer on missed opportunities in past projects. This was a great chance to spitball ideas for test and assurance design. What follows is a bit biased towards righting old wrongs, but may be good enough to revisit for future projects. Anyway, this is what I came up with:
Welcome to another blog post! As usual, these are my opinions. Not facts. Disagree with anything I’ve said? Get in touch, let’s talk. Happy to have my mind changed. Having said that…
Today I have been thinking about why I prefer the phrase “good practices” over “best practices” in test design. My preference is so tenacious that I exchange the word “best” for “good” when the topic comes up, as if I’m trying to change people’s minds in a subliminal way. But why?
It’s frustrating to go from 0 to implementing automation in testing at any scale. For some, this is down to a lack of experience with programming or scripting languages, for others it’s the pressure to get some testing work done and move on to the next priority. It could even be both. In any case, the effect of neglecting automation in software delivery is well-documented: increased risk.