A Tester’s Perspective on Agile Projects

Agile is a philosophy focused on delivering constant value to customers incrementally and frequently, based on communication and feedback. These two ingredients are vital to a successful Agile recipe.

Agile is no longer a buzzword or an unknown territory in the industry. Agile has progressed leaps and bounds the last few years and has matured to a widely accepted methodology. Testing in Agile projects required a paradigm shift for traditional testing roles. It required a change in tester’s attitudes from a relay race oriented approach to an upfront involved role. The Agile approach focuses on getting things right the first time, reducing the need for QA testers to get something over the finish line. But it’s easier said than done. How does it happen in reality? Does it actually happen?

Agile is a philosophy focused on delivering constant value to customers incrementally and frequently, based on communication and feedback. These two ingredients are vital to a successful Agile recipe and testers have an important role to play in creating value in Agile projects throughout different phases of iteration.

I have outlined the QA activities as three phases in Agile projects. However, this is no golden rule and it can be flexible according to the project situation. The Agile QA tester’s role is not limited to a set of pre-defined processes, as the methodology will dictate roles based on the situation.

Pre-iteration: This is the time where requirements are analyzed in detail by the BAs and acceptance criteria are detailed for that story. As QA testers are immediate consumers of those requirements, it is important to verify the requirements early and often.

Story verification (Requirement Verification): Agile testing is all about giving feedback early, not necessarily only by testing the requirements, but doing requirement testing early. QA testers really need to look at the requirement / stories upfront for clarity and testability. This will determine the requirements that are unambiguous and testable (I believe unambiguous in Agile is not much different in context compared to a typical waterfall project).

  • Requirements should be small enough to make sense in the context
  • Acceptance criteria (stories are generally used for acceptance criteria) should not be duplicated or overlapping from different stories

However, doing this can be very difficult and can only be achieved with strong communication between Development/Business Analysts/Quality Assurance.

Testable: The testability aspect of the story requires scanning through the story to see what needs to be done in order to test the story. These factors are generally:

  • Finding hidden requirements
  • Environment
  • Test data
  • Dependency on other requirement

Getting these details early helps the story to be prioritized accordingly in the backlog, and allows smooth execution of the story in the iteration.

QA testers also participate in the iteration planning meeting to give a testing perspective so the team can come up with a developer estimate. Participating in the iteration planning is a big role, as some of the implicit requirements are escalated by QA testers.

QA activities In the iteration

Once QA testers are happy with the acceptance criteria of the story, they can help define the acceptance tests for the story. Acceptance tests are requirements in terms of tests that can be executed in order to understand what is expected from the requirements. These acceptance tests are generally automated and used to drive development. Acceptance tests should not cover too many corner case scenarios as this would create unnecessary delay and could end up producing too many similar automated tests.

People often fail to understand that acceptance testing in Agile projects is different from traditional projects. Unlike traditional projects where acceptance testing happens at the end of the software lifecycle, in Agile projects acceptance testing is performed before the software is delivered. Acceptance tests also tend to be automated so they can run as regression tests.

Automated testing is very important for any Agile project. Frequent builds require short feedback cycles, hence regression testing must be quick and accurate. It needs to be noted that automated testing in Agile is different from traditional automated testing. In Agile projects, automated testing is practiced by all levels – developers, QA testers and business analysts. Involvement from everyone increases the relevance of the tests and often helps identify the right tests. But, this does not mean that everyone needs to be writing test code.

It’s always been debatable who owns test automation in Agile projects. For me, it’s more of a responsibility than a role. In my experience, the most effective test automation is achieved when developers and QA testers work together.

Use automation purposefully

Automation in Agile can be quite controversial. Many people try to automate everything and end up in a trap of having a long feedback cycle. Automation is meant to provide early feedback on the latest code, and the key is to identify what is worth automating and what is not.

Every automated test has a cost associated with it. The cost of automation should be compared to the cost of not running it. The questions that need to be asked are: what if a test is not automated? What will be lost and what would be the cost of fixing the stuff around the code for which we are losing the coverage? Is it cheaper to test manually? The answers may not always be as straight forward as finding the value of a test. It’s often a contextual decision depending on the size of the project and the number of people involved. In other words, a longer feedback cycle equals more people contributing time in getting instant feedback.

The typical QA activities in the iteration are to continuously measure the quality of the software. QA testers participate in the story handover to the developers. This helps them understand the testing requirements of the story so they are enabled for Test Driven Development (TDD). Also, handing over the acceptance tests and making developers understand the testability aspect of the story often helps catch common defects. These activities require a high level of communication between the developer and business analysts to clarify things on the fly and make sure the product is built right first time.

QA testers can help resolve issues beforehand by actively participating in the overall process. They may even pair up with developers to work on the story or tests for the story in order to get a better understanding of the requirements. It’s also imperative that once the story is delivered, it is tested properly, in a proper environment. Once the QA testers are happy with the stories/requirements, they sign off on that piece of work and hand it over for further testing.

It is also important to think beyond the written requirements and experiment with exploratory testing to execute ‘out of the box’ scenarios and undertake negative testing to help assure the software is robust. Exploratory testing is not at all about executing pre-defined testing scenarios, it is the art of exploring the software beyond test cases and at the same time keeping the focus around specific requirements.

I have attempted to cover most aspects of the basic activities of a QA tester in an Agile project. However, the role is not limited to these activities and QA testers should play more of a collaborative role when possible.

Pankaj Nakhat
Over the past five years Pankaj has worked with leading organizations in verticals such as business intelligence, banking, retail and CRM. In addition to experience with tools like QTP, Selenium and Perl, he has also developed simple and business effective automation frameworks and conducted training on automation frameworks and advanced QTP for corporations. He has lead automation initiatives from scratch and provided consultancy on different projects during his tenure with RBS.
Pankaj Nakhat
Over the past five years Pankaj has worked with leading organizations in verticals such as business intelligence, banking, retail and CRM. In addition to experience with tools like QTP, Selenium and Perl, he has also developed simple and business effective automation frameworks and conducted training on automation frameworks and advanced QTP for corporations. He has lead automation initiatives from scratch and provided consultancy on different projects during his tenure with RBS.

The Related Post

Agile stresses instant and easy communication and is built on teams working efficiently together. This necessitates an open work space environment. A characteristic of an effective team is a high level of collaboration, making the physical work environment an important factor. Cubicles should be eliminated in favor of an open work space in an effort ...
Mark Levison has over twenty years experience in the IT industry, working as a developer, manager, technical lead, architect, and consultant. He discovered Agile in 2001 and is now a Certified Scrum Trainer and Agile Coach with Agile Pain Relief Consulting. Levison has introduced Scrum, Lean and other Agile methods to a number of organizations and coaches from ...
In the decade since the Agile Manifesto, the movement has encouraged a number of best practices like test-driven development, user-centered design, iterative development, clean code, refactoring, continuous integration, and—arguably—cloud computing. I’m a card-carrying Agile zealot, and to me its benefits are unarguable. Is your IT organization ready to be Agile, seriously? Score yourself on these ...
LogiGear Magazine – November 2010
Build the right test platform including infrastructure, virtual lab and process. Testing embedded software is both similar and dissimilar to application software testing. The first eye-catching thing is that embedded software is significantly less visible to the end user. User interfaces are limited; there may be a console-based text menu, a simple command line interface, ...
Testing in Agile Part 1 – INTRODUCTION TO AGILE In case you missed the first part of the series in our last magazine issue from Michael Hackett, Agile’s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic.
As CTO of Xebia and highly experienced in offshore testing in India, Guido articulates his methods in addressing common challenges faced by the in-house and offshore teams. He weighs heavily on strategic tactics as well as key cultural aspects to execute efficient and effective Agile methods. 1. I work at a US-based company and we ...
I have worked with testers on an Agile team before and it has worked very well for both the team and the customer. In my previous role at Bank of Ireland, testers who had come from a traditional testing background worked within our teams to help ensure we had quality deliverables at the end of ...
Writing code that is easy to read and easy to test is difficult to achieve. The fact that poorly written code can function often leads to coding practices that are effective but not necessarily efficient. Too often, many programmers fresh out of school write code in the manner that was effective for passing their courses, but contains ...
To begin this article, it would be a good idea to, remember this key point: Agile Manifesto Value #1 Individuals and interactions over processes and tools Tools work at the service of people. People, particularly intelligent people, can never be slaves to tools. People talking to each other, working together and solving problems is much ...
Application development and delivery teams are under constant pressure to release quality features as quickly as possible. CIOs rate delivering applications faster, with higher quality and with strong control on application development as their key priorities. What’s more, supporting this type of agile environment is particularly complex to IT teams that are also tasked with supporting ...
Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams – from scrappy startups to big corporations ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe