Develop a specification
Writing specs is like flossing: everybody agrees that it’s a good thing, but rarely do people do it. It’s probably because most programmers hate writing documents. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. Luckily, most modern frameworks include first-class test suites that express specifications through tests.
Unfortunately, these specs do not include the human element or business logic that is spread across many areas found in integration or system testing. At the design stage, when you discover problems, you can fix them easily by editing a few lines of text. Once the code is written, the cost of fixing problems is dramatically higher, both emotionally (people hate to throw away code) and in terms of time, so there’s resistance to actually fixing the problems. Software that wasn’t built from a spec usually winds up badly designed and the schedule gets out of control.
Manual Testing, Separate Testers, and User Acceptance Testing
At Vaporware, our Product Managers, Designers, and Developers jointly create specifications in User Stories, Training Documentation, and automated Testing Suites. Test-driven development is a dream for many front end development technologies, but a simple unit testing can go a long way to express the intent to code. While we do not have separate manual testers, User Acceptance Testing is jointly performed by Product Managers and Clients.
The most important thing about user interfaces is that if you show your program to a handful of customers, (in fact, five or six is enough) you will quickly discover the biggest problems people are having. We call this Hallway Usability Testing, but only use it with people familiar with the context of our applications.
We recommend building automated testing into a Continuous Integration / Deployment (CI/CD) Pipeline. This enables all builds to be automatically checked for breaking functionality, and reduces the time to problem-solve bug fixes, which ultimately saves the organization money.
Code Coverage and code-churn metrics are great identifiers of risky areas of code and help new developers spin-up on complex areas quickly. We recommend CodeClimate integrated with CircleCI, or GitHub for a modern, easy to manage CI pipeline.
Automated Vulnerability Checks
Most open-source languages have security checkers, like Bundler-Audit, that can be added to CI pipelines to prevent new releases while security issues exist.