Take control of your test environment

As CAST 2015, Ioana Serban delivered a talk titled "Take control of your test environment". It's an entertaining and animated tale of her experiences with test environments. I'd encourage you to watch the talk if you haven't seen it previously.

I chose Ioana's presentation as the basis for a recent online testing knowledge sharing session in my organisation. As we are still working as a dispersed team, it currently isn't practical to bring all the testers together in one physical location to share ideas. Instead I asked them to watch Ioana's talk in their own time prior to a discussion session where we met for an hour in an online group chat to talk about the ideas that she raised.

Though our discussion was a little difficult to follow at times, on account of the many people typing in parallel, there were some very interesting points raised. We covered four topics: our build stability, techniques for test automation triage, the keys to our environments, and the people we work with in our own test environment quests.

Build Stability

Ioana spoke about techniques for encouraging stability in automated builds. She contrasted an approach where punishment is a deterrent e.g. wear a funny hat or pay a fine if you are the person responsible for a broken build, to a more positive outlook e.g. a counter on the wall that tracks the number of days since the last time that the build failed. Rather than amplifying mistakes, celebrate success.

We started by talking about how we currently encourage stability in our teams and tribes.

The initial response was that we don't focus on the stability of our master code base but rather the stability of what we are merging to it. The testers are careful to only push change from their branches when it has been peer reviewed and executes reliably. If bugs do end up in master, the tester will take ownership of investigating the automation failure, talk to the developers in their team, and collaboratively create a fix. The testers commented that "most of the time our build is stable compared to other places I have worked" and "in other organisations, it takes days to resolve problems, but in [our product] it takes hours".

But we also had one delivery area where things weren't so rosy. One tester said that their builds are usually broken "to the point where most people don’t have a reaction to a failed or unstable build". There was interesting discussion around the approach to resolving this that touched on the willingness of capable individuals to take ownership of the problems, allocation of time to build-related activities, incorrect configuration in our continuous integration server, failure fatigue and aging infrastructure.

We talked about using the time since last failure that is recorded in our continuous integration server to track stability of our builds. We haven't historically put much focus on this metric, but this may need to change if we move to a model of celebrating success.

The current method to keep attention on stability is to push build failure notifications to a team chat channel. Repeated messages make it difficult to ignore instability. Some of the testers also run their automation every time that a developer deploys into their test environment, which keeps both the automation and the environments stable.

Finally we talked a little about how instability can be a positive thing too. If the tests pass all the time, is there any point to them? There was a comment that "a test that never fails never gives you good information". However, we want our failures to be on branches and not on master. It also shouldn't be the test code itself that fails but rather a problem in the application or configuration that is highlighted by the test.

Test Automation Triage

Ioana spoke about separating her test automation into categories and treating each set differently: a suite of known bugs, a suite of flaky tests, and a suite that works reliably. We don't use an approach like this to triage our automation and I was curious about what the testers thought of it.

It's fair to say that opinions were mixed.

In one of our products we have a relatively old automation suite that has created some stability problems in the past. Testers in this tribe were eager to try Ioana's approach, though some investigation will be required to determine whether it's possible with the tool set that we use.

In our other products instability is either extremely rare or completely pervasive. Where instability is rare, we generally have the luxury of focusing on and resolving a single problem. There is little benefit to segregating this work from our master code repository. Where instability is pervasive, we would effectively be tipping the entire suite into the flaky bucket, which negates the benefit of having a separate category.

Though we are familiar with flaky tests, the idea of having an automation suite of known bugs was not something that we'd considered before. Some people thought that it might be useful to highlight known problems and give the developers a resource to target their code changes. But there was also a viewpoint that it would be an expensive waste of time to code a suite that always failed.

Finally, we diverged slightly into discussion about failures beyond our automation. We realised that we don't have visibility of which bugs are part of our product backlogs or a centralised register of known issues with our release test environments. Both were taken as areas for action.

Keys to our environments

Ioana talked about keys as a metaphor for access to aspects of her test environments. The four keys that she mentioned were access to code, access to the database, access to monitoring, and permission to deploy. Our next discussion topic was about the keys that the testers have for our test environments and the keys that they are missing.

Through this conversation I learned that many of the testers have limited access to our release testing environments. Some can examine server logs and query the release environment database, but others cannot. In theory, every new tester who joins the organisation is granted identical permissions. In practice, it seems that there are inconsistencies in the access that has been configured for individuals. Now that I am aware of this, I've started asking questions.

The other keys that the testers identified weren't specifically about test environments. Instead they were keys to information that will help focus their testing. One tester asked for improvements in device usage analytics to better target their native mobile application testing. Another requested access to customer feedback to get a better understanding of how our customers are using our products.

The idea of keys made people think broadly about areas that were locked to them and who they would need to speak with to open these doors.

People

Ioana finished by talking about the relationships that she'd built with people across her organisation who helped her to take control of her test environments. The last discussion topic focused on sharing the go-to people that the testers would call on for help when facing their own test environment challenges.

I was expecting people to name individuals but the most common response was that the testers direct their questions to a group. One commented that asking a group opens the opportunity for someone who you perhaps wouldn't ask directly to respond. I think the order in which the groups were named in our discussion reflects the order in which people would ask them for help.

First, developers. This was overwhelmingly the immediate response. I like that the testers have built relationships with their developers where they feel completely comfortable asking them questions, even those that aren't directly related to the code. I think developers as a first response is a symptom of healthy delivery teams.

The problems that the developers cannot solve are usually resolved by a solution coming from outside the expertise of the delivery team. The next group mentioned in the discussion were "all of the testers". As a collective that spans across multiple teams and tribes, we may not always know the answer but we are well-connected to people who might. Someone else said that they would choose an appropriate online chat channel to ask their question to.

Finally, one tester commented that testers should try to build our capability to identify the problem with our environments instead of simply saying that one exists. As with raising a bug, it's easier to resolve if more information is provided. Particularly when we turn to a group for assistance, asking the question with appropriate details is important.

Conclusion

Ioana's talk is interesting in its own right, but I would also recommend it as the foundation of a team discussion about test environments. We found a lot of scope for deep conversation about applying Ioana's ideas in our organisation.

I finished our session by asking the team to share one thing that they would think more about or take action on. The points that came back were indicative of a presentation that covered attitude, approach and technical techniques, including: 

• Keep asking questions, be polite, and build relationships with your colleagues.
• "We are the processes, they are living agreements."
• Learn what keys are available for your test environments and work to get them. 
• Do your research and send good information to the support team when asking for help.
• Create a failing test to make a bug fix easier for a developer.

I hope that this session will encourage the testers that I work with to be more mindful of build stability, techniques for test automation triage, the keys to our environments, and the people we work with in our own test environment quests. Ultimately, we'll take control of our test environments.