Most of us have had to deal with red builds blocking our testing or have been told to test on flaky environments where half the issues you find would ‘never happen in production’. As a tester, I used to think this wasn’t my problem. What happens though when a thinking tester decides this is her problem and wants to be part of the solution?
This talk exposes some of the possible causes why builds stay red or an environment is “flaky”. For instance:
1. There are bugs in your build.
2. You are dependent on a third-party system that is not functioning correctly.
3. Your deployment may have gone awry, something may be missing.
4. Your environment is not set up in a consistent way.
We’ll look at some approaches that target each of these causes and show testers how they can acquire the skills necessary to take control of their test environment. In case of bugs in existing functionality, you need to ask yourself: Are you running automated checks against the build? If yes, either you don’t have the right checks in place, are ignoring failed checks, or, even worse, the issue is intermittent. Testers that seek out a deep technical understanding of their product can be capable of chasing an issue down the whole technology stack without relying on a developer.
Stubbing out a third-party service can counteract uncertainty about the functionality of your own product. To deal with the real issue though, a tester can communicate directly with the third-party team, providing information to and from both sides.Testers can get involved with the automation of both the deployment and environment setup, which are traditionally Operations roles. This is also often the realm of “magic scripts” that are not considered part of the deliverables and are not properly tested. A tester’s input can be very valuable here.
Video producer: http://www.associationforsoftwaretesting.org/