Automated Testing — A Primer for Software Engineers

Are you testing the apps you’re creating ? No matter how you think about it, there’s always someone doing so (unless no one uses your app, which is sad). And sooner or later, someone will notice a dysfunction. Some will ring the bell but most will just leave and never come back.

What’s the conclusion ? The earlier you catch defects, the easier it is to solve and the cheaper it is for the company to run the business.

And there’s different stages at which these defects can be caught, from worst to best :

• Never : some just don’t happen, at least until now. And you can’t even measure the gravity of the bug before it happens.
• Once in the hands of end-users : and you’d be lucky if they have you noticed about it
• In the QA phase : if you have a dedicated team (which isn’t always the case), they may test your app against their own manual test suite, but that’s typically weeks after the code that provoked it was written.
• In the Build Pipeline : you may catch it by the end of the day or a few days after the code was committed and tested against various high-capacity tests
• Before the commit : typically minutes or hours after the code was written, so it’s still hot and is still easy to solve.
• During the code : that’s literally minute one. That’s the cheapest moment to solve the bug.

In a few lines, we covered quite a few topics, all related :

• Manual Testing
• Automated Testing
• Test-Driven Development
• Continuous Delivery
• Unit Tests
• Integration Tests
• Acceptance Tests
• End-to-End Tests
• Smoke Tests

If all of that sounds cloudy to you, then you’re at the right place. We’ll take a good peek and sum up at all things related to tests.

Read the rest of the article on blog.thelonearchitect.com.