When you’re building a web or mobile application, there are tens of things you need to think of: what problem it solves, who will use it, how to market and monetise and many more. Next to these strategic business challenges, there are also those connected with the quality of software development process. Even if you’re not a developer, you want to release a product that is maintainable and coded in a rational and predictable way.
How to check if you’re keeping the quality of software development process?
As much as every project is individual, the process of development doesn’t have to be. A solid team has a well worked through approach to the quality of their development process and a set of monitoring tools in place.
The most important ones are:
Continuous Integration (CI)
A practice allowing the team to regularly integrate the code to a common repository. Each integration is verified which results in keeping the updated version in one place. Thanks to CI all completed tasks are merged into the application.
A consistent integration process has a direct impact on a dextrous application development and on decreasing the project cost.
The biggest advantages of continuous integration is the immediate feedback the development team receives about the functionality, quality and overall impact of their code.
An experienced software house will have the practice in place and will ask their partners for the same. Even if you’re negotiating with a small and young software partner, make sure they use CI.
We set up continuous integration with SemaphoreCI early in our days and it turned out to be one of the best quality-driven decisions about our process.
One of the ways to prove the quality of software development process is testing. It’s not my intention to dig deep into this topic. Some people write their PhD thesis about testing so for now let’s stick to a very simplified division of tests.
- Tests written by developers aka automated tests. In short, through these tests developers are able to verify whether particular pieces of code work as expected and how they affect the existing code.
- Tests performed by manual testers. Manual tests help the team see whether the code actually does what it’s supposed to do. Manual testers click through the application and check it against the business requirements and browser or device compatibility.
Thanks to testing we know that the code works as it should when it comes to business logic (and syntax, too) and that the user can do exactly what we wanted and how we wanted.
Depending on the test coverage (and type), testing can take different amount of the entire time of the development. For example, manual tests take usually 10%-15% of the development time. When it comes to automated tests, it can be much longer and expensive.
Each line of code goes through a mandatory review and acceptance by another pairs of eyes. This way the team cares for actually using the good practices and watches one another. Code review is also a great learning tool that leverages the skills of the entire development team.
Code documentation can take different forms. The most important thing is that you keep it transparent.
- Code standard – at Briisk we have our own standard based on community-driven style guide to keep the code consistent,
- Name convention – all names of variants, methods, modules and any other components are descriptive and clear.
- Project documentation – we store it in one central place and update regularly.
- API documentation – so it’s clear how to use the service. It helps new developers to understand the application or external teams to connect to your application. We use Postman to document our APIs.
- Tests – like them or not but they are also one of the ways to document the code.
A good practice is to separate the code the team is working on from the one that’s already accepted. This way, there’s a coding playground, testing playground and production environment.
The first one (usually called workspace or development) is the place where new features are added. One can call it a working environment with unit tests and code reviews. Thanks to continuous integration, accepted pieces of code are automatically merged to workspace.
The next one (staging) is the environment for the manual tester. The release from workspace to staging happens when a set of features is developed and ready for manual and compatibility tests. While testers do their job, the developers can continue working on new features and preparing for a new release.
In the last step, tested and approved work from staging can be safely pushed to production server where your users enjoy new updates and can share feedback.
Developing an application is much more than just coding. If you want to give your users a high quality product, you need to make sure that people who write the code also follow good practices. A good way to do it is to ask questions about strategies and standards the team uses. Continuous integration, code reviews, testing and documenting the work are the foundations of a solid development process which in turn affects the quality of software development process. Take the time to talk about them with your development partner and you’ll be surprised how much of a difference they can make.