Testing

Well, you don’t want obvious bugs. Releasing fast doesn’t mean we need to release things that breaks the application or looks bad.

To test something before release is a good idea. Testing is as with everything else — a big topic and there are different schools on how to do it. We are obviously not talking about a "testing phase” here a la old school project management.

To wait to test everything until the end of a project may come off as hilarious today, but it was a common practice and still is in many Waterfall projects. Luckily most have moved on. Wait with testing and the developers have moved on and forgotten and it’s almost a new project to fix all the small things.

Today companies use continuous testing which needs to happen in a testing environment before the ticket/story/fix goes to production (gets released).

In this way, we can code features, test them, give feedback, code again and continue testing until we are happy with the result. We can release whenever it’s ready on a per-feature basis.

In many development processes the developer codes something, then tests a bit on their local computer and then commit the code and make a Pull Request for peer review (in the best case). Then it's on the testing environment.

Here, some developers like to hand over to a QA (“Quality assurance”) team that takes over the testing responsibility and “make sure" that it has “the right quality”. This looks good on the paper. Don’t do it! At least not like that.

Read more in "The CTO Playbook" available on Amazon/Kindle.