Continuous Testing in 2022. It’s the stuff that Continuous Delivery is built upon. Do it right, and you deliver software at pace. Do it (CT) poorly, and you get nothing but a script to deliver crappy software just like we always have. CD without CT is just a pipe(line?) dream.

So how do you do it right? Lets take a look at 10 ideas that make Continuous Testing effective and successful:

1. Automate your acceptance criteria
   • Start with a great acceptance criteria. Now take test automation and prove that you did it. Don’t stop short, don’t wave your hands and say it will work. Prove it with a test. Check it in with the code and run it every time you build. This is your oracle for the future. This is where you start putting coins in the bank for the future.
2. Make your tests focused and fast
   • Forget end to end if you can. Focus your test on a single thing. Sure, write great unit tests that help show function level quality, but strive to create a test that proves working components. System level functionality (not system integration) – make your tests fast. Make them small, with limited scope. Get in, prove, clean up and get out. If you are doing setup to get to your point, you have failed. Think testability and architecture. Refactor so that your test is small, focused and fast.
3. Develop and live by a definition of done that includes testing in your sprint
   • Your team must live by the fact that you are not done until you have delivered test automation that proves your code is going to work. Sure, that might not happen but that is the cliff we march to. We may find out that our test was not good enough, but the sprint is not done until we have the completed code and tests to go with it checked in and passing. No excuses.
4. Make the entire team responsible for quality
   • People say this all the time and don’t live by it. Many times we sit around waiting for quality guy or gal to get the testing done. Wrong. If you are waiting for testing to complete, you are doing it wrong. Complete the testing. Make the testing faster. Do the test yourself. Build better testing. Make the framework measure. Your job is to deliver new features with high quality. Whatever your expertise is, use it. You are responsible. I once heard that the best way for a developer to get better at testing is to give them a pager. Give everyone a pager.
5. Get skilled. Quit pretending that record and playback works
   • Laugh at the sales guy that brings the record and playback “we can make automators out of everyone” BS. It’s a lie. Always has been, always will be. Get some skills on your team – it takes code and hard work by well paid professionals. Big projects will have quality roles for SME’s and analysts with deep product knowledge but we are talking about Continuous Testing here. Automation. It takes engineering – don’t lie to yourself or get lied to by vendors.
6. Tell your sponsors that systems without tests will not be delivered
   • Hey PM or Product owner. We write quality code. To do that, we have to write tests. It’s part of our estimates. We won’t be done with the sprint without the test automation. There is no CD without CT. Get over it. No, we will not start working on another feature until this one is done, tested, automated and complete. If you need us to skip test automation, please see #6.
7. Listen to the tests
   • Thou shall not comment out, delete, cripple, or ignore your tests. You built them. If they are complaining, make them better. If they are failing, listen to what they say.
8. Fight fragility. Mock, isolate, make the tests small
   • Fragility is your enemy. Make your tests boringly pass all of the time. If fragility is your problem, think testability, observability and architecture. Take the battle to the system under test and the way it is designed if there really is no way to stabilize your tests. Mock and isolate your testing using responders or other service virtualization if you can. Resist giant integration tests when small tests will cover the risk. If they are fragile, get everyone in the room and figure this one out – it’s too expensive to live with.
9. Co-exist your tests
   • Never, ever let your test automation live in another place. They are first class citizens that should live with your production code (I didn’t say deployed with) and should most often be written in the same languages that the system is. Everyone whould be able to fix them. Never let there be an excuse of “i don’t understand that code” or “that harness is in another solution, get Jane/Jack to look at it”. Nope. Not Continuous Testing. Let them co-exist.
10. Monitor everything, measure FTW
    • Monitor your systems. Measure your testing. Continuous Testing really works when you instrument your systems from production down to have machines looking at things that may help you diagnose and fix quick a problem that is on tested for initially. When you find problems this way, maybe you should go back, and write some test automation. FTW.

Copyright 2022 HeadRevison.com