“The World Cup experience is more than just the game of soccer. It’s an event. And it will fly by faster than you think. It will end and you’ll be saying, ‘Wow, it’s over already?’ You have to remember to take it all in …” — Cobi Jones (former player and sports analyst).
Finally, after years of preparation, emotions and growing expectations, the 2014 World Cup kicked off last week in Brazil. It has been a really interesting journey for the country, starting with Brazil selling its case and passing through years of planning, implementation and finally the execution. But, the World Cup is not just about teams, players, or games; there are also those considerations (security, transportation and logistics issues, media coverage, communications, political or military situations, etc.) that keep drawing our attention and that will influence the final evaluation of Brazil as a host.
We can take an automation implementation project and compare similarities with a world cup organization (including epic consequences, if your job is in the line): in both cases you need to sell the case, plan your project, implement an effective strategy, evaluate and contain risk and define a clear way to measure your success. Here, we analyze some of the key elements that you need to consider when implementing automation. But, now, let’s review some of those issues that often make you lose focus, waste your time and negatively affect your automation project:
Ineffective communication within the organization. An Automation project is not only about testers. For example, at some point you will need the help from your IT support area to install/move or support your testing tools or infrastructure. By increasing your regressions, will you need more deployments from your Release or Development area? What are the communication channels in your organization? When things are not working How do you communicate the expected response times? Are there language/time zone/technology barriers?
Low process compliance and readiness. You want a testing tool and automation strategy that can help you to increase coverage and regressions and one that doesn’t isolate your team isolated or create rework. Is your tool or strategy compatible with the development process or methodology or tools? Does it create a collaborative environment or force the teams to work separately? For example, one of the key processes in testing is defect management. This process involves not only testers but developers and managers. If the strategy requires you to modify the process to make your testers use two tools (Dev’s and Testing’s) so that the status or information about defects is updated/handled by both teams, then the new process will be reducing productivity—plus—developers might lose key information to fix defects or make improvements.
No organization awareness. QA/Testing is not an island. Not only are you going to require inputs from other areas, your outputs will be affected too. On one hand, the testing teams will require more information about functionality or data—is your BA area aware of those needs? Have they allocated the resources to support it? On the other hand, if everything on the testing side is working as expected, that means that you are going to do things faster and bigger—is your development area ready for an increase in defects as result of an increase in coverage? What about other areas, like customer support, IT, production support? How does this affected them? Are they on board?
Incorrect executive expectations. Testing automation promises faster regressions, high productivity, good quality, and reduced costs. Sometimes that leads to unrealistic expectations (i.e. 99% costs reduction, 100% implementation in a few days, etc.) Since you are not going to achieve those results, your automation project is set to be qualified as a failure before you even start to define your strategy. Is your goal of delivery clear to your stakeholders? Did you outline what will you cover and what you will not? Have you defined clear metrics and indicators to measure your success?
No expert support. At some point, your team will face a complex problem with your tool or application that will require a workaround or a tool fix. One way to handle this is to make your team do research and troubleshooting. That strategy backslash is that your team might get very frustrated and consume a lot of time for your project. Ensure that you have expert support to ease your path through the implementation, and train the team.
Certainly, the issues above might look like the issues that you will face in any project. That’s because an automation implementation should be a project. The most common automation implementation failures occur because the implementation was treated as an additional task or idle time task to the testing team’s existing responsibilities. In order to be successful, you need to set this as a project, with specific a scope, estimated effort, defined resources, dependencies, risks, metrics and a timeline.
In a few weeks, the world will evaluate if Brazil was able to “take it all in” successfully. Are you ready to take it all and make your automation implementation a success?
