I’m getting serious about delivering fast with quality!

How long time does it take for you to deliver your application after you are ready with a new feature? How sure are you that your updated application really works after you added your new feature? For me the answer to those questions are way too often “To long” and “No, I’m not sure that everything works”. But now is the time to get really serious about delivering quickly with high quality!

In this blog post I will give a foundation on coding - testing - delivery process and in upcoming posts I will go into details in this process and also talk about specific tools that could be used.

Overview

What can I do to deliver changes to my project quickly with high quality? There is one obvious thing that will help me to go faster and that is automate as much as possible of my development and delivering process. Unfortunately going fast could also mean that I will be delivering my project with bad quality, so I need to automate my testing also, to be able to go fast and still be delivering with high quality. A third way of going fast is to get feedback while I'm writing the code if I'm doing something wrong and getting feedback directly.

Improvement areas in my development and delivery process:

When writing code

If I make a mistake on my first line of code in my project, I would save a lot of time if I could be notified directly about the problem. The reason behind this is of course that it’s much faster and easier to fix the problem directly when I have the thought in my mind about what I wanted to accomplish with this line of code. If I will be notified about the mistake that I did even in as short time period as 15 minutes after I wrote the line of code, could easily triple the amount of time it will take to fix the problem. So, already at the stage of writing the code it’s important to try to get as much feedback as quickly as possible about any mistake I could make in my code.

My first line of defense is to have a code editor or IDE with syntax highlighting. You might think that colors are a silly help, but the colors easily help you to detect spelling mistakes in your code. An IDE with some kind of code IntelliSense that will help you find the class, method, variable that you want to write will help you write faster and make fewer mistakes. If the code is written in a statically typed language the IDE will be able to help you much more with suggesting the correct class, method or variable and setting a correct syntax highlighting.

With Static code analysis I can take the next step of detecting simple mistakes like code conventions, memory leaks or bad code constructs.

That was the steps that could be taken before the code is compiled, and then after the code has been compiled more advanced testing of small coding unit’s behavior should be done. This is done by writing test code that is then executed by a Unit Test framework. The Unit Test framework will give a simple way to execute your tests and produce a test result report. There are also several development methodologies that will encourage you as a developer to write Unit Tests with complete test coverage of your code and to write your tests early in the process. The methodologies are for instance Test Driven Development (TDD) and Behavior Driven Development (BDD).

The tools and techniques that I have described so far are all things that I as a developer should be able to easily setup and execute directly on my development machine.

Commit stage testing

So, what is happening after the code modification is done? Well, what you need at this stage is a version control system where you can commit your changes to. The version control system is a safe place where source code is stored and it will help if you need to go back to a previous revision of the code. It’s also possible to use it for example for doing release branching of the code. I recommend doing as little branching as possible, the reason why I recommend that is that it could be hard to merge back a branch. If you are in a branch longer then one day, then that also means that you are no longer doing continues integration. Also remember to commit often, at least once a day, otherwise it will be like your own local branch on your computer that is not continually integrated with the rest of the code.

Today there are basically two types of version control systems to choose between and that is centralized version control like CVS and decentralized version control like Git. I don’t think that a pessimistic looking version control system any longer is an option.

When my code change is committed to the version control system the automated build should be automatically triggered. This means that I need to traduce a new tool that can trigger the build and the rest of the testing and delivering parts of my pipeline. This new tool is called a Continuous Integration tool. This tool will help me with monitoring and executing the rest of the pipeline. The artifacts that are created in this stage in the pipeline should be used for the rest of the testing and deploying of your application. So, this is the one and only build that should be performed for the commit that was done.

Once your code change is committed and the build finished correctly, it should automatically trigger the automated unit test and static code analysis to execute. The commit stage testing must be executing in less than 10 minutes, otherwise no developer will sit around and wait for the result to arrive. If they don’t wait for that, what was done in the commit will be forgotten and harder to fix and maybe you will end up with a broken build for a longer time then needed.

It could be good in this stage to deploy the application in a test environment and do a small smoke test to see that everything is fine before putting a green light at this stage in the pipeline and move on to the next step. If not all tests are green here, you should not move to the Automated Acceptance Test stage, instead you should fail the build and test process.

Automated Acceptance Test

Do you need more automated testing than Unit tests? Yes we do, we need to do integration testing, end to end testing, performance testing, security testing... well as you see acceptance testing, can be a lot of things. I decided in this part to divide these kinds of tests into the two parts Functional test and Non-Functional tests.

Functional

The purpose of the functional acceptance test is to verify that the application is doing what the application is specified to do (note it does not need to be a specification document). Creating these kinds of tests can be done with help of for instance your unit test framework but you create integration tests with it. You could also use a tool like Selenium or a GUI testing framework. Or most likely you need to do a combination of all 3 of these types of tools.

Non-functional

An application can have many other demands that it needs to fulfill, besides of the functional demands. So, for instance the application could have some kind of performance demand that need to fulfill, like it needs to be able to be able to handle a certain amount of transaction in an hour. To test the performance of an application you need a separate environment for that, to be able to know nothing else is disturbing the test execution. The easiest way to perform the performance test is with your unit test framework and then measure the times that it takes to run a test. A good practice is to have test data that is very like the data that the customers are using, since the application can behave very differently depending on what data that is used.

Security tests are another kind of Non-functional tests that you need to execute.

Manual Testing

Humans easily get very board if they need to do repetitive tasks, for instance if they need to test the same thing many times. Then it’s very easy to miss some details when testing. So, this is the reason why you should try to move as much as possible of the type of testing called “Checking” to automated part of the pipeline. Checking is the type of testing where you check if a text field has a specific value or if the background has a specific color. That means that Checking is something that is easy for a computer to verify.

So, if humans get board at doing repetitive Checking of the application, then what should they do to verify that that the application is working. Humans should do Exploratory Testing of the application. But what is Exploratory Testing? Well it simply means that the tester freely explores the application under test and one of the focus areas here is to let the tester learn as much as possible about the application during the test. If it’s a larger application that is being tested it’s a good practice to give the tester a certain area of the application to test and then time box how long he / she are allowed to spend on that test.

Delivery

After all tests have been completed with a green light, its’ time for a human to push the delivery button. Remember that all tests have been done with the same artifacts that were created in the compilation step in the beginning of the pipeline and it’s the same artifacts that should now be delivered. When I use the word deliver the application this could mean different things depending on what type of application you have. If it’s a web application the artifact files should be uploaded to the webserver or if it’s a phone application the artifacts should be uploaded to the app store. No matter what type of application you have one common thing should be that you automatically deliver your earlier created artifacts to the place where they get installed / published.

So, is delivering the end of the pipeline? Well not really, a modern application should continually give feed back to the developer when it’s in production mode also. The kind of feedback that I’m talking about is things like sending back crash report, what parts of the application is being used for instance.

Summary

This was an overview of how I will code, build, test and deliver an application, now when I’m serious about delivering an application with high quality quickly. You will probably soon see posts that dig into details in certain areas from this summary description.

Interesting Links:

• Continuous Delivery book