Test Code == Code
The most important guiding principle of them all when you are running a test automation program for your project/product. Whether you are doing it from Iteration 0 or starting somewhere late in the cycle (for reasons best suited to your deliverable dynamics), this should be kept sacrosanct.
For brief introduction, I run a testing services company and hence talk to a lot of potential/existing clients on a regular basis on test automation ideas/issues/challenges that the teams on ground face. The genesis of this blog is a statement i have heard quite a few times now during some of these conversations and found it compelling to clear the misconception because it is plain wrong.
“Automation in the project is difficult as the project is changing fast, a lot of feature are being added/updated on a regular basis” .
If you are owning/running a technology program and being told this by your team/vendor, be alarmed, very alarmed. Because factually, they are just trying to hide the engineering incompetency behind the cloud of “frequently changing features”. I have worked in agile teams all my life and can say with full conviction that the statement above is completely wrong.
The whole idea of AGILE was and is to allow these frequent changes into the software delivery process and teams (devs or QA’s) with their engineering prowess should support the same. Have you ever seen a developer complaining of frequent feature changes. No, because they write code that is scalable, well abstracted and hence can be easily tweaked to accommodate changes, as many as needed.
So, as long as testers follow the same mindset and understand the importance of clean coding practices, they can 100% support automation on any project with every single story that is moving around.
Moreover, you definitely need automation if your product is changing very fast otherwise its hard to keep track of how each feature change is affecting the product ecosystem. Good automated tests and a well engineered framework can save the day for you, any day.
So, what we need is an introspection on what are we trying to build. A world class engineering team where testing supports the overall development process by making is faster, smoother and error free? Or a team where testing is done at the fag end and is treated more of a gate keeper and hence you are always challenged to match the pace.
