6 Common Myths around Agile Testing

6 Common Myths around Agile Testing

Agile development methodologies have been at the center stage for many organizations, and with DevOps evolving, testing in agile environments has gained momentum However, there have been a lot of myths and misconceptions around “agile testing”. Some of the very common myths are discussed below in this blog:

Myth1: Testing in Agile is ad hoc

Agile involves planning sprints, budget and resources ahead of time. It definitely is different from the planning required for waterfall model. The test cycles in Agile are in sync with the development cycles and are an inherent part of the sprint planning. The test cycles are planned to address each user story implemented as part of a sprint. Although the user stories might be included or removed from a sprint, testing is based on the user stories developed, and never ad hoc

Myth2: Testing in Agile is undocumented, quick and dirty

Documentation is considered important in an agile project as well just like in case of other projects. Agile insists on swift communication and collaboration which are very important elements for a successful project, more so when it is agile and distributed. Proper infrastructure for effective communication, and deploying tools to enhance communication play a very critical role in agile projects. The only difference is that agile gives more important to face-to-face interaction than extreme dependence on written communication. Also, the agile teams are usually provided with guidelines and requirements on the level of documentation and coding comments that they need to incorporate.

Myth3: Testing in Agile does not have defined strategies

In agile projects, testing is synchronized with development sprints, and the test cycles act as quality gates for the sprints. Multiple approaches are followed to quickly test the user stories for a specific sprint before release. The approaches also help in continuous monitoring of the application after release ensuring a complete feedback loop, for the next sprints

Myth4: Testing in Agile is about right tools

Agile gives importance to people over process and tools. While tools can enable efficiency, in Agile it is important the collaboration happens between individuals, irrespective of which tools are used. Streamlined development and testing practices are more important than just being able to use tools. Test teams need to be part of the daily sprint meetings, right from the start of user story identification, to be able to identify issues early in the sprint.

Related :   4 Critical Things to Consider for Agile Test Automation

Myth5: Testing in Agile is best done by developers

In an agile-based distributed team model, the distinction between the developer and tester, in terms of boundaries of their job responsibilities, grows thinner. Testing is instilled throughout the agile methodology; it’s done by both developers and testers. It’s more of a collaborative work approach between developers and testers. Testing teams are seamlessly integrated with the development lifecycle. The role of a tester in agile becomes more proactive; testers seamlessly collaborate with the developers to meet their goal of delivering an effective and operational software by replicating the bug, fixing it, and verifying it before the end of each sprint. This collaboration between the core teams helps identify the software quality risks and weaknesses of the project at very early stages reducing the costs and efforts for both the teams.

Myth6: Testing in Agile should all be at same geo location

It is definitely good to have the whole team in one geographical location for smoother communication and exchange of information. However, when an organization is becoming global, and teams are distributed across the four continents, it becomes highly impossible. In a global company, teams are assembled from different geographical locations with the help of technology that has come a long way. Meetings can be held involving people all around the world at the click of a button. There are a number of tools available for collaboration and file sharing. Testing teams should be ready to accommodate different time zones and leverage technology to adopt efficient meeting practices. With a little effort, flexibility, adaptability and the proper mind-set, distributed teams can just be as agile as the co-located teams.

Related :   Practical Approach for Improving Agile Testing Maturity – Part 1

Organizations are increasingly going agile to achieve improved quality, faster time to market at reduced costs. Get in touch with Gallop’s Agile Test Specialists who can guide you well about the myths and realities of agile testing and help you truly realize the potential of an agile environment.

The opinions expressed in this blog are author's and don't necessarily represent Gallop's positions, strategies or opinions.