Building tech focused around people.
The concept of software automation is not new. Since there have been flaky builds and mission-critical features, there has been the need to define software that can test it and report the results to humans.
Automation was new to me when I worked at my first corporate job. Having done front-end development for a few years prior, I was familiar with feature-focused development. Working in the quality space was totally new.
After working on automation for a few months, it became clear that writing correct, reliable automation can be difficult to implement. Flaky tests, distributed codebases, and lack of time / resource investment leads to brittle automation test suites that break every time someone wants to merge into master.
Developer skill is important to writing valuable tests. Stakeholder buy-in to invest resources keeps the test suite healthy. With only a few months of neglect, automation can fall by the wayside and result in tests that don't reflect the health of a system.
More recently, I have had the opportunity to help a couple of friends automate a project that has been easier to manage. We started out by defining a clear goal for the task we are automating. The smaller scale and investment on helping out the client of our system, a QA tester looking to eliminate meaningless toil, has led to the development of a stable, healthier automation suite.
Like most things in software engineering, automation by itself does not solve all of your problems. The coolest automated testing architecture with multiple suites, parallel tests, and easy-to-use test writing tools will not fix poorly written tests. Using the newest automation technology in the industry will not automatically fix your quality issues. If a company doesn't invest enough resources into manual testing, the value of their automation suite starts to wane.
It may seem that automation tools are solutions to the productivity difficulties of managing teams of QAs and developers doing exploration testing. Swinging too far to the technology direction without solid exploratory testing will result in larger costs long-term. The value of your automation suite is only as good as the integrity of tests it contains. This integrity is maintained by investing in people who are looking to break the piece of software you are testing.
Even the most honest engineers have subconscious bias when writing code. In the same way that professional authors send their manuscripts to editors, there will always be a need for outside input into a creation.
This bias may be negligible, but it is often easy for an engineer to dismiss edge cases in a piece of software they have written with a casual "no one will use it that way". When writing applications that need to have low amounts of defects, you must have a group of people trying to break the product.
Having trained professionals who look to break a product will harden core features you develop. If quality is dire for your business, it is important that you maintain a solid number of these people to "wreck s#&@".
Only when you employ s&*# wreckers can you isolate, solve, and write tests for edge cases that encompass large features in your software.
Finding engineers who are willing to solely work on automation may prove difficult. However, using sweeping corporate speak on how "quality is everyone's problem" tends to make it no one's problem.
Engineers often put automation and quality low on their list of priorities when they do not have solid company investment.
If one engineer on a team is tasked with automation and related tools full time, it can prove to be more manageable. Depending on the amount of freedom you give them, Delving deep into the dark arts of automation and quality can be fun for the engineer. Many quality engineers love the freedom that comes from a focus on writing solid tests and breaking the application.
Reliable automation doesn't just need planning. If you want automation tests that stay updated and have purpose, you need people who are dedicated to maintaining them.
When I say dedicated, I'm not talking about the ephemeral pictures that are put up all over you office building with eagles and wild horses running off into the mountains. Dedicated engineers are engineers whose main job is to ensure automation tests and their surrounding systems are reliable AND valuable. They need to work closely with devs who are building features to ensure that they are testing the most important functionality of a system.
Upper management tends to focus on velocity over automation and uses coverage numbers to fill each level on the way up with a sense of false security. In reality, many engineers either write fake tests and/or turn off test suites in order to get new releases . They also tend to give out automation as grunt work to college interns, contractors, or new hires.
Maintaining quality is everyone's job. It is best solved by employing people who build software and people who break it. You must have people thinking on improving the quality of a system full time. Or at least the majority of the time. 10% focus on automation doesn't cut it.