Keeping complex testing simple
Updated: Dec 3, 2018
Yes, the KISS is a Rodin sculpture, set in stone - but for testers, developers and product owners, KISS can be something else just as solid: Keep It Simple Stupid.
Over the last few weeks, I have had several meetings with developers, testers and managers discussing choosing testing tools. What are the best tools to tame the complexity of software development?
As a tester, I want the best tools to help me do my job. But I hate tools that slow me down when doing my job.
The good news is we have more tool choice than ever: JIRA, Asana, Slack, Trello, and so many more. And the good news for us is that these tools are cheaply priced for small organisations and the vendors provide all the support you need online to get them up and going. Software tools, like the world, are becoming Uberized.
However, taming software is still a complex business. Choosing the right tools and deciding how to architect them is the KISS challenge.
Here are the KISS criteria I look for when choosing tools and architecting them.
The workflow must support a consistent view of "source of truth". That is, everyone in the organisation agrees where the master copy of any information is, including its state and its owner. For example "its not a bug unless its in JIRA", "the master copy of the spec is in Confluence", "its not done till its tested done", "its not actionable if its just in email".
Ensure that the tools and processes are tuned for various granularities of "truth". For example, Slack can be perfectly appropriate for tight communications about how to solve a particular bug. Not every code change may need its own JIRA bug. Standups are really effective to get things decided, there is no need to document them. Pair testing and pairing a tester with a developer are highly effective ways to transfer knowledge and skill. Confluence Task Lists obviate the need for JIRA tasks. Also critical here is how to write a spec - if the software spec is too detailed, it may not work - it may become not-truth the minute the real code varies from that spec ( software is guaranteed to change!) . Specification by Example is an excellent example of appropriate spec granularity.
Transparency. Within reason, the whole team can see all the relevant information about their work. I advocate making everything visible internally, tracking all changes (never never delete), and allowing everyone on the team to comment directly on and/or correct the "truth". Dial back transparency with reticence.
Pull not push. The best tools don't get in the way. View dashboards and reports that extract their data from the "master copy". You spend your time doing your work in the tools, the tools capture the relevant information about what you do without you doing anything extra. Everyone else can pull relevant information from the system and also control their own alert notifications. Everyone is in control of what they need and want to see.
Agree on a cadence. For distributed teams, an agreed upon cadence really helps minimise confusion and miscommunication. For example "we release to testing every Thursday ( NZ time) 9am", "we run complete regressions every weekend", "input for the next sprint must be in by Monday 9am". One of the reasons Sprints are effective is because they let everyone else know when is the time to give input, when is the time not to speak to the team and when is the time the team will show what is "done". Brilliant.
Agree on the process. I find effective organisations have healthy and open discussions about their process. "Here is a whiteboard showing how we work together", "It would really have helped me if you had told me about this planning document earlier", "what does 'done' mean?", "only use Hipchat or JIRA or Confluence tasks, I will ignore all email requests", "we have 2 week sprints".
Be able to change the process. "I will change my Confluence notification settings so next time you update the planning document, I'll see it." "I have to update that field everytime I update a ticket, so please automatically fill that field in". "we could spend more time doing work if... "
Keeping It Simple is not always simple. It requires work, just as it did for Rodin. Even when we have the most marvellous tools.
