Back from delicious lunch. Was so nice to walk around on the pier and get some sun, and check out the view from the venue. Golden Gate Bridge… Alcatraz… so pretty. But I have to say, as a seasoned conference speaker I can tell you the worst slot is right after lunch. The great sleep rolls into the room. But, the folks at Testbash are clever. We got Melissa Tondi up to charge up the group.
Specifically what is the do not’s of testing. They serve to remind us that innovation should always be in the forefront of our industry. Even the best playbooks become stale and should be revisited (often). Make sure that what we do is still applicable to the industry, the community, align to the industry and are generally agreed to.
First rule: Do not be “The Enabler” (sounds like the worst batman villain ever)
- We tend to make up the work that has lagged at the end of the sprint/project… this enables some bad behaviours
- We tend to perform actions that save the project team’s schedule (far too often). “Testing came through and finished all the testing on time!!!”
- These are perceived as value add to the rest of the team. However… we then become the “Why didn’t you catch that?” team. When we use enabling behaviour, we become the martyr.
Second rule: Do not "automate everything"
- It is well established that you should not (cannot) automate everything. However this is still an idea that is deeply appealing to many in the S/W industry.
Third rule: Do not have “QA-ONLY” sprints/cycles
- Sometimes called QA hardening.
- This ends up creating multiple weeks of sprints that need testing where work was done on top of work.
- This puts responsibility on QA and builds a gap between dev and QA activities.
Fourth rule: Do not "Own All Testing"
- This really needs to be part of product definition
Fifth rule: Do not "Hide Information"
- Explicit (readily available) vs Implicit Information
Explicit - Stories
- Tests
Implicit - Conversations and deep dives
- Subjective look and feel experiences… as we gather info it might not all be shared
- User information - Discussions with Customer Support and Product
How do we deal with these?
Do not be the enabler
- Be a musketeer - one for all and all for one.
- Celebrate successes together. Explore failures and learn from them
- Find ways to explore how risk based and context driven approaches are being used? Share how we do this.
- Work to understand and share how and what dimensions of testing give with the schedule, and which don’t. Have the team as a group discuss and decide on prioritization of testing
Do not “Automate Everything”
- We need to break the notion that automation actually replaces human testing. We should however embrace technology to use automation to help with the repetitive dimensions of testing, and allow humans to focus on where they are needed
- A of A - Automated of Automatable
- A selection process that shows percentage of automatable valuable tests given critera defined by the project team. This is a cool idea… it creates a much more approachable mechanism to bring the whole team into the discussion of test strategy
Do not have a “QA-ONLY” cycle
- Focus on the term “shippable”. Talk before work starts to define “what do we need to complete in order to get this to the point of being shippable?”
- Should couple dev with test
- 2 day flag: If test and dev is more than 2 days, then we increase the possibility that inefficiencies and splitting of work.
Do not “Own all Testing”
- Make an effort to fully understand the unit/api testing strategy. If we cannot establish what is being done there, how can we plan our automation and exploratory testing strategy.
- Find out who else is testing, and how. Or who should be testing through unique information or context they might contribute.
- Actually use the definition of done.Not just what product does. These should align, but we should be able to diminish risk if we truly understand how to best trust our teams based on this definition.
Do not “Hide Information”
- Rule of thumb… work with stretch goals
- if it is written and publicly shared, it is explicit. Make sure it is understood by everyone. Make sure that a passed test has an understood meaning by all.
Do be a Quality Engineer!