-
How to thrive as a QA pro in an agile organization
As the adoption of agile practices has increased in the last few years, the relationship between QAs and developers has evolved. The increasingly nebulous distinction between the two roles is a good example of this evolution.
Traditionally, a QA engineer’s role was more aligned with the job title, testing and validating the quality of code. Working under a waterfall methodology, a QA person might bat undeployable code back to developers or, once the code was tested and validated, release it to production. Testing and validation were not processes that concerned devs, and hand-offs were the norm.
Agile has brought about a new mindset, and a host of new responsibilities for developers and QA pros, which not only benefits the delivery of software, but also makes us better at our jobs.
Here’s what to expect when moving into an agile organization as a QA pro.
Dev-QA alignment
Working in agile means there is little difference between the role of a developer and that of QA. Our day-to-day is very much the same, since it starts with a stand-up meeting where all tasks in a sprint are visible on a Scrum or Jira board.
If tasks, or stories, are at the stage where they are ready—i.e., they indicate that a certain feature is usable—then the QA pro works with the developer in charge of the story to verify that this is indeed the case. You need to verify that the acceptance requirements, as determined by the architects and product management team, have been fulfilled.
After a short review of the story, you either work with a developer to refine the story, or you consult the product team or architects to ensure that the testing requirements for deployment are met. Essentially, you are working to progress stories, just as developers do. But more and more, the QA pro’s role involves test automation tied to stories.
‘T’ time
Increasingly, it is the developers who perform functional acceptance testing of their code, since this is part of what it means to ensure that a story is “done.” This is a core principle of agile development; it encourages developers to take ultimate responsibility for, and ownership of, how their code performs in production.
QA pros and developers work in the same pre-production environment, which is why you must embrace a more holistic definition of “done.” If a change must be tested at a pull request level, it is tested at this level, since the code base is the same as that of the live application.
This evolution of responsibility means that the developers you work with are increasingly T-shaped. That is, their primary function is to code, but testing and validation are key requirements for completing that function. Of course, QA pros work with developers to establish how test automation tools will be implemented, but the onus is on developers to deliver deployable code.
Naturally, developers aren’t the only T-shaped team members. Working in agile means sharing responsibility, which also means sharing work. While a QA pro’s main role might be test automation, you can pick up development tasks as well, as can other members of the team.
Automation, automation, automation
Developers shoulder the responsibility to review, test, and validate code in an agile organization, which means that the role of the QA has evolved. (If it didn’t, you wouldn’t have much to do). QA folks now spend much more of their time coding—but to a different end.
The reason developers are able to test, validate, and review code more effectively (as well as adopt these practices more easily) is that test automation tools have advanced, and this is where QAs now focus their attention. Indeed, test automation tools often require more code than the features they are designed to test!
Advanced automation may also be possible once certain tasks have been completed and are production-ready. This is where QA pros must keep a close eye on the Scrum board and the progression of stories, since there may be opportunities to introduce further automation at a later stage. An example might include automation to validate an entire feature, aligning with continuous integration and continuous delivery processes.
What you need to succeed
For any firm working with agile, achieving business objectives requires orchestrating a cadence of processes that help achieve those objectives. Key to this orchestration are collaboration and communication across teams, whether they are technical, customer-facing, or business stakeholders.
That means that, as a QA pro, you must be able to communicate with each of the agile teams involved across the software development lifecycle. Whether providing feedback in Scrum retrospectives or working with architects and product managers during the early planning stages and providing proofs of concept for automation tools, being an effective communicator is essential.
So, too, is individual learning. It’s easy for QA pros—and developers too—to stick with what they know when it comes to programming languages and tools. But the technology landscape moves quickly.
To stay on top of advancements, make time to look further afield and understand which new technologies and techniques are on the horizon. The end goal, as always with agile, is to work smarter, not harder. Advancements in technology and tooling enable this, so be sure to keep up.
-
0 Replies
Sorry, there were no replies found.
Log in to reply.