Back in the good old days life was simple: Software was written in Cobol, Fortran and C, Mail was sent in envelopes, The most popular car on the road was Ford Fiesta.
But most of all, the role of QA was clear:
You get a Functional Specification Document (usually the size of a book), and test the software for compliance to this document.
When you find a discrepancy between the code and the book- just open a bug.
Months of uninterrupted testing for every release. So simple. What could possibly go wrong?
To be honest, the good ol’ days weren’t really that good. The software created was pretty bad, and for good reason.
For starts, the specs were never accurate. Even if they were close- there’s always room for misunderstanding, and when specs are thrown over the fence from Dev to QA- misunderstandings will occur.
Very quickly, QA became the enemy of developers, for reason of not understanding that the code they wrote is right and the spec is wrong.
In many organizations, QA became an underdog, and the work of a QA engineer was living hell.
The agile revolution changed that all.
- In agile companies software is no longer thrown over the fence, but handed of in person, demonstrated and reviewed together- Dev and QA.
- Hundred-paged specifications made way for sharp user stories.
- Agile ceremonies give QA engineers the stage to provide true value to their teams.
- Software is created faster and better than it was a decade ago.
- In ‘Agile companies’, relations between QA engineers and coders are better, often characterized by mutual respect.
QA Engineers are often concerned when they hear that their company is transitioning to an Agile workflow.
There’s no reason to fear.
For QA Engineers more than anyone, this transition is a great opportunity!