Business Processes

Abstract

As you probably realized from the previous chapters, a test automation project can’t stand on its own. Its life cycle is tightly related to the life cycle of the application that it tests. Like any software project, its existence is only relevant if someone uses it; otherwise it’s worthless. In the case of test automation, the “user” is actually the entire development team. It may seem like the main user is the QA manager or Dev manager, but in fact, they’re not using it themselves for their own good. They may require the fancy reports and tell you what they want you to do (and sometimes even how…), but as we discussed in Chapter 1, one of the principle advantages of test automation is that it helps the team detect and fix the bugs more quickly. But for this to happen, the team needs to learn how to use it effectively, which usually requires some sort of work processes. The processes can be less strict if the team is small and everyone simply understands the value behind such processes. But whether these processes are strictly enforced by management or the team understands their value, these processes need to be followed in order to allow proper collaboration and to get the maximal value from the automation.