Taking Control of Your Test Environment

Editor's Notes

1. Armed with natural curiosity and a flair for spotting defects the tester is our base class today. Valuing context above all else the tester knows there is no such thing as a 'best practice' and views testing as an intellectual activity. Special attack: 'Rain of questions': The tester can unleash at will a flow of questions rendering their opponent paralyzed until they can come up with answers. Weakness: Being asked to automate all the testing can send the tester into a blind rage.
2. Code writer extraordinaire the developer is responsible for implementing the product features. Cares deeply about his craft and can spend hours debating the correct position of a curly brace with other developers. Special attack: 'Works on my machine': When summoned by the tester to discuss a defect, the developer can deflect by showing the problem does is not reproducible on his workstation, buying himself some time. Weakness: Being forced to make software work on *other* people's machines.
3. Writer of user stories and master of the backlog the product owner is king. The PO is responsible for the product vision. Special attack: 'Just one tiny thing': The PO can ask the team to implement one *small* change on a feature that although appears simple covertly adds tons of work to the team. Weakness: Being asked to prioritize technical debt.
4. Also known as the Operation Engineer or DevOps Engineer, the Ops is able to summon or tear down environments at will. Master of deployments and the dark arts of monitoring many Ops spend time apart from the rest of the team and do not interact with them on a daily basis. Special attack: 'Have you logged a ticket for this?': When approached by an engineer the ops can ask this question to instantly banish their oponent from their lair. Weakness: Breaking changes in a build will cause alerts to fly and instantly cast the ops in an incident.
5. Little is known about these people. Legend has it that they are responsible for some third party service the product depends on. While often depicted as unskilled savages by the team, it is possible they are just misunderstood for being different hold the key to some knowledge the team needs but is not aware of.
6. In a land not so far away King PO was very excited he was building a new castle and had enlisted the help of the best and brightest engineers to complete the task.
7. Construction had already started and it had gotten to the point where the next thing to be built was the castle gate. ‘As the King I want my castle to have a mighty gate to allow the friends of the kingdom into the castle and keep all enemies out’
8. All of us have to deal with these things: red builds that will not go green, failed deployments, flaky environments – all things that impede our testing. Complaining about it is of no use to anyone.
9. Label as bugs – separate test suite, tag check with bug number. When the bug is closed look for the bug # in the test suite run it and if green put it back in the main suite. Developers love this too. They run the check when fixing bugs. You have automated your developers! They might not do testing but they do checking!
10. Make the flaky test fail. Concurrency issues are hard to debug. Your developers will thank you since they’ll be able to run this check too when trying to track down the issue.
11. ----- Meeting Notes (05/08/15 12:52) ----- don't waste their time, don't send code traffic capture intermitent issue -> send more reuqests
12. It took me 2 and a half years at my previous job to get all the keys to the castle. At my current job at eBay it took me 2 and a half weeks.
13. There might be dragons!