Quality Analysts and their roles into an Agile environment

Thanks to the software testing, many drastic changes have occurred on the software development – more and more the development team is getting value from testing, i.e., they are adopting test as a habit, always worried about create test cases in order to verify if what as desired was delivered.

Additionally, the concept of quality analysis in traditional software development is not only related to the write tests just in order to ensure the quality of the product. It’s more comprehensive than this. In Agile, the concept involves the effective software analysis also related to verify if what has already been developed is in total conformity with which has been specified, and, consequently, in according to the customer’s desire.

While I was searching for some references to write this post, I find a very interesting presentation made by Syed Rayhan from Code 71, about the role of a quality assurance in a Scrum project. During the introduction, he brought some questions about the effective role of a QA. I sent him an email asking for some comments about these questions, and I’ve included his answers throughout my post below.

·  Is QA part of the development team?

·  Can we fit QA in the same iteration as development?

·  Who does QA?

·  Does QA costs more in Agile as product seems to change from sprint to sprint?

·  Do we need “test plan”?  

·  Who defines testcases?

·  Are story acceptance tests enough?

·  When do we know testing is done? 

·  Do we need to track bugs?

QA plays a dynamic role into an Agile environment – he must be active since the start of the project until the software release, working together with the developers and product owner(s) to define test cases and acceptance criteria. Although Agile testers are developers, they have a specialized set of skills.

Even though, developers can write tests (not only unit one), but QA could have the mindset to write some of the other required tests.

However, in order to increase the success rate of the project with Agile, developers and testers must be part of the development team and need to be fitted in the same iteration, it is good for testers have test automation as their core focus and not only manual testing.

A team organized like this way means more quality to the software, because it will be tested in small pieces, and the team can receive a faster feedback about what is going wrong. The picture below shows the difference between a traditional the software development model and how it could be in Agile.

                 Traditional Software Development

Agile Software Development

And NO, QA doesn’t cost more in Agile! It may seem that teams spend more time retesting, but it is a necessary evil. The earlier we can catch a bug, the better. We end up spending less time in the long run. In fact, with the right amount of test automation, we would spend less time in testing for the same level in the long run. QA will help the team to verify earlier if what's being developed is exactly what the customer needs/wants, as well as help to track bugs and other vulnerabilities on the software. It means less rework at the final of the project; less chances of exceed the budget and the time.  

The QA role within an Agile environment seems to be contradictory, because of the tools and process used are their working tools, as well as all the documentation. But when we talk about documentation in Agile, we are referring to a lightweight documentation, e.g., acceptance tests would help the team to document what's supposed to be developed, and it's the way to have a living documentation. But these acceptance tests aren’t enough to the process: a QA must have his test cases and tests scripts as part of the documentation, in order to help the team or another QA to perform a test that has already been done, without spending time in rewriting that. 

Furthermore, it’s also important the bug tracking. Usually teams track bugs after a feature is delivered. During the development of the feature, it depends on the team. Informal interaction between the QA and the developers might be easier. 

I extracted a figure from the Syed’s presentation, showing the responsibilities of each role of the team in perform the different types of tests:

The quality assurance plays a critical role to the success of the project; however, it is not the key to ensure the quality. The quality is responsibility of each one of the team, since the requirements gathering till the success of the tests performed by another members of the team (devs, support engineers, performance engineers etc.).

QA works together with the developer, the business analyst and also together with the customer, gathering requirements and writing the acceptance tests, always aware of what’s been developed and ensuring the release of quality software generally every two weeks.

The picture below shows clearly the role of a QA in a project:

The main responsibility of a QA is to make sure that the right software works right. 



Since the team is self-organized, QA is not a designated person’s responsibility – it’s a team’s responsibility, and they should collaborate together for the success of the project.

Thus, it’s important that the requirements are very well specified without noises in its writing which may cause misunderstandings. If it occurs, this noise should be mitigated as soon as possible together with all the others members of the team – BAs, developers etc. – this is the main purpose of Agile. 

The testers know that the less time there is to test, the less they will be able to test. And the less testing they can accomplish, the less the organization will know about the software before it’s released. Less information means more risk.