Rosy was working with a team consisting of developers and a product owner. Her team followed a 2-week sprint cadence, and practiced sprint planning, daily stand-ups, and retrospectives as their agile ceremonies.

Time constraints as the product grows

She was a lone tester on the team, and all the testing was manual. There were no automated tests at all.

As the product was growing, the team had to implement and deliver more new features. Manual regression tests were eating up Rosy’s time. As the only tester on the team, she could not implement automation by herself. Not that she didn’t know how to or didn’t want to. She simply didn’t have time.

Getting Some Help

The team decided to get an automation engineer to help them. Rosy was happy that she was getting someone to help her with the most repetitive tasks. Now, her time could be used in more critical test activities. “Hurrayyy!” was her feeling. 

Jack (the automation engineer) joined the team and Rosy was super excited to have him. The team expected quick magic, but that’s never the reality. 

They both started working together. The first thing Rosy did was explain the product. Then they started implementing a smoke test suite (smoke testing is a type of software testing that determines whether the deployed build is stable or not). This helped Jack to settle in, and gave him a better understanding of the product. The team used Jira for project tracking, so Rosy created a task for Jack to implement a smoke test suite so he could give an update against this ticket during the stand-up.

The First Challenge 

The first blocker Jack faced was finding the IDs for the elements, such as buttons and text boxes, that the automated tests could use to interact with them. But that got resolved on a case-by-case basis by having conversations with the developers and pairing up with them. It took a while for developers to get to the state of being strict with using unique element IDs. 

The Next challenge

The next stop was the implementation of the big beast: the regression test suite. Again, Jack started automating the regression test cases which Rosy had already documented. It was a long process as there were quite a lot of regression tests. 

Rosy and Jack were very clear about what they wanted their automation to do but they completely ignored communicating this to the team. It was not deliberate, in fact, they assumed everyone knew what they were doing and why. This is an example of when assumptions can cause problems.

An Unpleasant Surprise

One day, one of the developers, Dave, was planning to work on a technical debt task. Rosy jumped in and asked Dave if that task could be paused until at least half of the regression suite was automated - that would help her make sure that nothing existing breaks from any of Dave's changes. 

The conversation went as follows:

“What - your regression tests aren’t ready yet?? We thought you already implemented those tests, implemented all the cross-browser tests, and some performance tests as well!” 

“What?! Did you really think we had done all of that already and had been running those tests?” 

And the answer from developers was a very firm, confident: “YES.” 

So the team had a bit of an argument here. Rosy thought she has been informing the team of what they had been doing all along. Still, how can they assume that it's all done already? 

And it’s not just whether things are ready or not, but it’s about assumed expectations about automation.

Reflecting on the problems

Rosy put some thought into understanding what went wrong. She tried to understand what caused this confusion, misunderstanding, and assumptions. As part of updating and upskilling herself, Rosy came across Angie Jones’ course on Test Automation University, “Setting a Foundation for Successful Test Automation”.

She started off the course, and to her surprise, found answers to a couple of her problems within the first chapter. She became so motivated that she decided to finish all the chapters. The course was full of guidance and suggestions for anyone getting started with automation on a project. Even though Rosy had automation experience, most of the problems she was facing stemmed from how she and her team began the automation project. This course was perfect for preventing these types of problems.

Rosy realized the first problem: that she and the team did not have any specific automation goals apart from just thinking it would help her with regression testing.

Then she realized that it wasn't just about not having an automation goal, but that there were few other problems, too:

  • Not communicating or sharing the goal itself with the whole team

  • Not collaborating with the team members to come up with expectations for automation from the whole team

  • Not treating automation as a project

A new plan

She was so excited to get back to work the next day to resolve these problems step by step. She had a plan. Rosy invited all of her team members to a meeting so she could share the lessons learned from Angie’s foundational course. She decided to do a short presentation outlining the course and major key takeaways instead of just providing the course link to the team.

The title of her presentation was ‘Side effects of having no goals for automation’’. The entire delivery team was curious about the presentation, and Rosy was excited and happy to see her plan for resolving these problems received with curiosity and energy. She was delighted to see that her message was spot on. Her developer teammates agreed that they never came together as a team and communicated their expectations for the automation project. To listen to this statement itself was a win for Rosy, but to top it all off, she got buy-in for her plan.

Rosy’s team decided to revisit the automation project and come up with goals together and communicate not just to the team but to the business as well. 

They decided to concentrate on:

  • Setting a goal

  • Communicating the goal to the delivery team

  • Collaboration on an automation project

  • Measuring the value of automation project and celebrating small milestones

Rosy was very happy that she was able to identify the highest priority problem - lack of goals and expectations - find the solution to the problem, and share it with her team. The team was also incredibly amazed at the large amount of information and help available to the testing community. Though she'll still have to face many other challenges while moving forward, she is glad that the whole team now understands that automation is not a side project - it needs to be treated as a project in itself.