Gone are the days where throwing the code over the wall to QA sinks the SDLC schedule. Continuous Testing helps the entire SDLC by not only not being an impediment, but also being an enabler for the other SDLC functions.
Automate everywhere you can – This may seem extremely obvious, but it is still a basic tenet worth stating. This not only applies to the testing itself (which obviously run faster when automated), but also to the build and deploy. The reason is simple: the human element is slower and more likely to accidentally introduce mistakes. Maximizing speed and minimizing problems is all part of a clean Continuous Testing process, beyond what mere automated testing can achieve.
Smallest component testing – It’s easy to pinpoint root cause at the least granular level such as a business API, instead of at the master application. Testing was once limited to the monolithic master app, but no longer. Testing a GUI and called back-end business API’s separately provides a shift-left benefit that both prevents defects from spreading throughout production, and simplifies the root cause detective work. After all, if the API is spitting out wrong answers, you might as well catch it there, not at the GUI level. Hopefully, this shift-left concept catches defects in the branch prior to merging, thereby minimizing potential impact. Employing a feature toggle can improve QA’s deductive reasoning, or eliminate a problem area that is damaging too many test results.
The communication thing – Continuous Testing is a feature of DevOps, and another feature of DevOps is good communication between the Development, QA and Ops. Too often, Ops sees Dev+QA as IT, and Dev sees QA as those annoying people who find trivial bugs. Viewing QA as separate or the enemy only hurts the overall process. QA isn’t a poured-in sauce; it is a lubricant of the SDLC engine. That means asking the tough questions during design and development when specs are lax; that means pairing with Dev to ensure that tests are meaningful in addition to be passed; and that means letting Ops know how testing is going.
Implement and practice test optimization – The “Keep It Simple” philosophy extends applies to test optimization at both the test case and test suite levels. By building tests that do what they’re supposed to do, you avoid yielding unnecessary false negatives and false positives. Sloppiness in one’s tests is like intentionally creating technical debt, and a little forethought can prevent this. The test scenarios test the code, not the test scenarios. Logical variables (platform, browser, device, etc.) should be included, and non-functional test (security, performance, etc.) should be included, with performance results tracked over time (“Yikes, our query time just doubled!”), preventing bad practices from invading and infecting more of the code.
