Building quality-in and keeping technical debt in check are two of the most important goals to support long-term sustainable product development. Adopting the right engineering practices allows teams to focus on innovation and value delivery, rather than wasting time on fixing problems or avoiding quality issues.
BookingBug faced a near-death situation when it had accumulated too much technical debt due to poor engineering practices.
The product suffered from too much accumulated technical debt. It made it hard to customize things, and caused all sorts of problems. Because the company had no regression testing in place, as it built new features for the bank, other things started breaking up. It also had no documentation ready, so the development teams within the bank had a very hard time integrating with the BookingBug’s API.
Case study: BookingBug, https://www.5dvision.com/post/bookingbug-technical-debt-and-engineering-practices/
BookingBug did complete reboot by rewriting its core app from scratch and adopting regression testing and continuous integration. By adopting the right engineering practices it was able to overcome the issues accumulated and position itself on the market. Today, rebranded as JRNI, the company is doing well in all major markets around the world.
Ever since BookingBug implemented regression testing, it runs more than 1,000 tests on every build. This allows the company to maintain the quality of its product and keep technical debt in check.
Deliver Great Products that Customers Love
Read more: BookingBug case study
XP engineering practices
XP (Extreme Programming) defines a set of engineering practices that elevate the performance of the teams and create products of higher quality. These 12 engineering practices were originally defined in an article by Ron Jeffries: What is Extreme Programming?
The core engineering practices in XP are:
Whole Team, Planning Game, Small Releases, Customer Tests, Simple Design, Pair Programming, Test-Driven Development, Design Improvement, Continuous Integration, Collective Code Ownership, Coding Standard, Metaphor, Sustainable Pace
These practices are widely adopted by high-performing teams. While they were born in software development contexts, they have meaningful complements in other applications as well. Many of these practices are now at the core of DevOps.
Here is a quick description of a few practices that are fundamental for any team that approaches software development today:
Regression testing
As your application becomes increasingly complex, so is the task of testing every new functionality. Not only do you need to verify that the latest feature you built works, but also that everything else is still working fine. Without proper testing procedures, you risk that a recent change to the code impacts a feature that was built months ago. Unit testing is not enough as it is limited to the latest developments. To ensure quality and minimize technical debt, you need regression testing and automated testing.
Regression testing is a type of testing that verifies that software previously developed and tested still performs correctly even after it was changed by a recent development. Changes may include new features, new libraries, software patches, OS and API upgrades, configuration changes. Any of these changes has the potential to affect any of the functionalities of your application. Often, the most difficult issues to catch are those created by changes in areas of the application not directly affected by those changes.
The goal of regression testing is to verify that any recent change has not introduced new problems. It’s very unfortunate to see potentially great apps ruin their customer experience when a new feature is released and suddenly something else in another part of the app stops working. No matter the tool you use, regression testing should always be part of your toolkit.
Regression testing is, however, not a magic wand. It can save a huge number of work hours and headaches, but it works its magic only when properly implemented. As most things in life, it is up to you to make good use of it.
Running regression testing manually can be a huge endeavor, especially in large or complex applications. For this reason, automatic testing tools are often used to simplify and speed up the regression testing of an application.
Read more: https://en.wikipedia.org/wiki/Regression_testing
Automated testing
Most testing procedures, including regression testing, can be laborious and time-consuming. In Agile environments where the development cycles are very short and resources are scarce, manual testing is usually limited to unit testing. Automated testing is becoming increasingly important for software projects of all sizes to automatically verify key functionality, conduct regression, and help teams deliver a great user experience at all times.
Automated testing tools offer to speed-up testing procedures, and to make them more effective. Whereas performing manual regression testing on a full application is not usually a feasible option, automated testing can do this with ease and speed. With automated testing we can perform a broader set of tests, at a deeper level, than what would be possible with manual techniques.
There are many tools for test automation. Depending on the type of app you build (web, mobile, stand-alone, custom) and your organization’s preferences, you may find a suite of testing tools that fits your needs. A Google search offers many ways to discover and compare testing tools, for almost all possible needs.
Learn more about different tools: http://www.testingtools.com/test-automation
Test Driven Development (TDD)
Test Driven Development is an Extreme Programming practice aimed at optimizing the passing rate of tests. TDD flips the usual concept of development-then-testing on its head.
The idea is that a developer begins by writing a set of tests. Then, they write the code that is needed to pass the tests. Once all tests pass, the work is completed, and the developer can begin work on another work item.
Because the code is not accepted until all tests are passed, TDD ensures 100% passing score on all tests. Also, it minimizes the amount of work done, as the developers just need to complete the work needed to pass the tests, nothing more. Yes, the quality of the result depends on the quality with which the tests are written in the first place, putting more focus on the right tests (another benefit).
The other key factor is that TDD enables automation. Therefore, tests can be automated, including all tests that have been run in the past. From this point of view, TDD supports regression testing and helps build a more robust application over the long run.
Acceptance Test Driven Development (ATDD)
Acceptance Test Driven Development or ATDD is a technique used to bring the customer’s point-of-view into the testing phase, before development is even started. Test cases are written in a human-friendly format that represents the expected outcome, benefit, or behavior of the test. The format can also be interpreted by a machine, and hence becomes automated.
The key benefit of ATDD is that it incorporates the customer experience into the design of the tests. It also expects a close collaboration between the members of the team in writing acceptance tests and describe how the system should work.
Read more: “Acceptance test–driven development”
Acceptance Criteria can be written in a format that allows for automatic testing. One such format is defined by Gherkin, which is a language supported by the automated testing tool Cucumber. Gherkin uses the format:
Given …. When …. Then….
The use of Gherkin provides not only a machine-readable format for automatic testing, but also a business-friendly documentation that’s easily readable by humans.
Read more:
https://github.com/cucumber/cucumber/wiki/Gherkin
https://en.wikipedia.org/wiki/Cucumber_(software)
https://cucumber.io/
Pair-programming
What would happen if you removed the keyboard to 50% of your Development Team members? I know, this idea is almost unthinkable, unless you want to risk a revolt.
In essence, that’s what pair programming does. You pair up your developers so that they work together on one computer. One person writes on the keyboard, the other stands behind the first and tells them what to write. They switch roles every 20 minutes to an hour to avoid fatigue and ensure sharing of ideas.
On the surface it looks like a drop in productivity. Now we have two people using one keyboard and only one of them can write? Wasn’t the whole goal of software development to increase the quantity of code written?
Let’s pause for a second. If you think about it, writing a ton of code that may potentially be ineficcient, affected by technical debt, or potentially full of bugs, it’s not in the interest of anyone. You will have to fix it, improve it, and potentially rewrite it in the future, slowing the overall process down.
Instead, if you were able to write the right code, with a high quality level, so that you minimize the chance for rework, you may improve the overall productivity. Because you are not slowed down by all the fixes and changes you need to make. This is the goal of pair-programming.
In addition, because two developers are working together and sharing ideas, you foster cross-collaboration and cross-learning of new skills, helping your team grow.
Continuous Integration/Continuous Delivery
Continuous Integration (CI) is the process employed by developers who check-in their code at frequent intervals and trigger an integration of the project. By doing this frequently, developers greatly reduce the risk that a late change may have a big impact on the project.
Continuous Delivery (CD) is designed to automate the delivery process, so that software can be released at any time. Companies that employ a Continuous Delivery methodology release new features on a daily basis, sometimes even multiple times a day.
The goal of Continuous Integration/Continuous Delivery is to build, test, integrate, and deploy software faster and more frequently, reducing the risks, costs, and time required for integration and deployment of larger increments.
One tool that has surged to fame is Jenkins, an open source tool available for many platforms and that was spun-off from an original project at Oracle. Jenkins is a continuous integration platform. It is also an automation server that can do much more with expansion plugins to the most common automated testing tools. Jenkins supports unit testing, automated testing, and regression testing.
Read more:
https://jenkins.io
https://www.tutorialspoint.com/jenkins/index.htm
