Recently I came across a question from one my friend what are “Principles of Well working Test Automation in an Organisation”. So here are my thoughts on it.
To think about the above question one requires thinking from first principles(First Principles: Elon Musk on the Power of Thinking for Yourself).
Why is there any QA in the team, what problem does QA solve in the product.
QA is there to flag quality issues in the product. Earlier QA can flag quality issues; cheaper it is to build and release the product (The Cost of Bugs: Why You Can’t Ignore Software Testing — XB Software)
So what does Test Automation solve for us QA?
It speeds up the process of flagging quality issues in the product, while we(QA) are away focused on improving quality of other areas of the product.
This means Test Automation helps team(s) release new iterations of product with confidence at a pace that would not be possible without help from machines.
Thus we can conclude Principles of Well working Test Automation in an Organisation revolves around how effectively Test Automation can flag quality issues and how early it can detect that.
With this being a clear goal, here are some of the ways to apply these principles —
- Continuous Integration to check code quality…
A well organised Continuous Integration system can help check code quality at every stage of the release. This means, ways to check at unit level any potential defects introduced due to change in code. Ways to check this new change integrates well with other changes coming in and so on till the user interface layer.
- Well Architected Test Automation ( Testing Pyramid)
Although Test automation sounds potentially beneficial, it can quickly become a reason for slow release cycles due to badly architected Test Automation. To avoid this one can use Testing pyramid (https://martinfowler.com/articles/practical-test-pyramid.html) like a north star.
- Code Quality of Test code ( Oops principles, Coding Conventions, Industry Best Practices)
Test Automation is finally code. Any code that does not follow good practices soon becomes a drag on the system itself. Simple way to avoid this quagmire is to follow simple principles of Oops, apply coding conventions agreed within the team and continuously look to borrow best practices from industry
Do you agree with this, is there something you think there is to add from your experience, I would be happy to learn from you.
