Testing

Testing gets its own section because it is so important. Whenever you are designing, or developing any non-trivial software application or component, one of the first things that should be taken into account is how the different people or groups involved in the development process are going to test their work. Any design that is produced must facilitate being tested. This is of fundamental importance because what we need to do is to shorten, as much as possible, the feedback loop for the people involved. In plan English, what this means is that if something is broken or gets broken then the sooner we can check and find out about it then the cheaper it is to fix.

By incorporating repeatable, well documented tests which lend themselves to being automated we can reduce the time it takes to detect bugs while at the same time increase the likelihood of finding them, significantly reducing both the time taken and the risk involved in the software development process.

The amount of investment required to implement a robust suite of tests depends largely on the type of project and where it is in it's life-cycle. For a project at the start of the design phase the cost of implementation is low and would include, for example, the selection and configuration of the testing framework/tools, the training of the developers (in both the use of the framework/tools and in the mindset of testing) and the training of the architect/technical lead in designing for "testablity". The cost and complexity of introducing testing increases with the length of time that a project has been around, exactly how much it increases is difficult to say, but it depends on things like; the quality and size of the codebase, the quality of the documentation, the number of external dependencies that a system has, the architecture of the system, if the original developers are still around, etc.. We have had great success in the past incorporating all types of testing into projects at all stages of their life-cycles and the choice of whether to go ahead or not has always been based on the cost involved in maintaining and modifying the system plus it's life expectancy versus the cost of implementing the test suite or a subset of the test suite.

If you're starting a project and want to know the best way to go about testing it, we can help. If you're halfway though a project and would like to start testing, we can help. If you're a manager or a customer who is tired of hearing "The project domain is too complicated to test", "The database is too big / complicated for us to be able to write tests", "Changes break unrelated parts of the software" or "The system has (too many) external dependencies so we need to deploy it in order to test anything" then we can help. What these phrases really mean is that the system has not been designed to be testable and that's why elements of it can't be isolated and tested.

In our opinion all software should possess a suite of tests that can be run individually, in groups or scheduled to run automatically. For most modern programming languages there are free frameworks and other tools that facilitate these types of tests and automatically generate reports of their outcomes. Tests also help to document the inner workings of a system and can help to insulate your projects from the problems associated with having lots of specific programming knowledge stored in the minds of a few key developers. For an outline of the types of testing that, depending on the type of the project, you should be taking advantage of, please get in touch with us.