As more and more agile practices are adopted in the tech industry, the line separating the role of developers and QAs is becoming less and less distinct. This has led to an evolution in the definition and responsibilities of these two roles.
Earlier, the QA engineer would be responsible for testing and validation of quality code. They would be working under a waterfall methodology and would send back undeployable code to developers and validated and tested code to production. Conversely, testing and validation were processes that did not concern the developers and they would typically be hands off in the testing and validation processes.
With agile practices, the mindset has been revised and that has opened up a host of new responsibilities for both QAs and developers that benefits the delivery of software and makes the professionals much more competent at their jobs.
So, what should you expect when moving into an agile organization as a QA professional? Let’s find out.
Developer vs. QA
In an agile environment, the role of a developer and that of QA doesn’t differ much. Both set of professionals start their days with a stand-up meeting where all tasks in a sprint are visible on a Scrum or Jira boards.
In case any task or story is at a ready stage, indicating that a feature is usable, then a QA and the developer work together to verify if that is truly the case. The QA will have to verify if the acceptance requirements have been fulfilled as set out by the architects and the product management team.
After briefly reviewing the story, the QA is required to work with a developer to refine the story or consult the product team or architects to make sure that the deployment requirements are met, as far as testing is concerned. In an agile environment, the QA is effectively working to take the stories forward, much like the developer. However, and QA professional’s role is getting more and more tied to automating tests related to stories.
More and more developers are performing testing to ensure functional acceptance of their code. This is because this ensures that a particular story is “done”. This is an inherent part of agile development and encourages developers to take responsibility for and ownership of the functionality of their code.
However, since QA professionals and developers work in the same environment one is forced to accept a more holistic definition of what is “done”. This evolution of responsibility makes the jobs of developers more and more T shaped, that is, while their primary function remains coding, but testing and validation remain the key functions to enable completion of the primary function. The responsibility of delivering deployable code is on the developers even though the QA professionals work with them to establish methodologies of test automation implementation.
Since working in an agile environment means sharing work and responsibility, a QA should also have a T shaped work responsibility and should pick up development tasks to augment their key role of test automation.
With the evolution of the role of developers, it is a natural progression to expect the role of the QA professional to evolve and encompass a different dimension of coding. QA professionals now spend much more time coding than before, however, this coding has a significantly different end compared to the coding the developers do.
The QA professionals now focus their energies on coding for test automation tools that often require more coding than the features they are designed to test. These automation tools and their effective usage by the QA are what enables the developers to test, validate and review code more effectively.
QA professionals must also keep a watch on the Scrum board to be able to identify advanced automation possibilities in certain tasks that are production ready. They must be able to recognize opportunities to introduce automation at later stages.
The Ingredients for Success
Firms working with agile need to actively keep collaboration and communication thriving across their teams to be able to achieve their business objectives through a perfect synchronisation of activities between them.
Thus, as a QA professional your ability to communicate across teams involved in the SDLC takes on paramount importance. Starting from providing feedback in Scrum retrospectives or liaising with architects and product managers in the early planning stages and providing proofs of concept for automation tools, effective communication is crucial in a QA professional’s role.
The same can be said for personal learning and growth. It is an easy trap to fall into to stick to what one knows as far as tools and programming languages are concerned, but as we have seen again and again, the tech language changes rapidly and leaves behind those that refuse to adapt.
In order to stay on top and ahead of your role, keep abreast of the new technologies and techniques that are developing and are yet on the horizon. Agile organizations are always looking to work smarter and not harder, so there will always be evolution of automation and tools. As a QA professional, you need to keep up!