Learn more about our software quality training.

Find out more about our Software Risk Assessment service.

Test cases play a crucial role in the software development process, as they validate that the program and its functions work as intended. With thousands of test cases, it is particularly important to rank them appropriately to maximise the effectiveness of the tests focusing on:

• testing the most critical and high-risk areas of the code
• prioritizing tests that provide the most value to the users
• code-level changes that have the highest risk to delivery

In this document you can read about how TestNavigator can help you meet these expectations

Source code cloning, also known as copy and paste programming is believed to be a major threat to software systems, mostly the ones currently in their implementation phase. The problem is often overlooked due to the true danger lies in the clones' long-term existence, specifically in their unmonitored evolution – hence the immediate negative impact cannot be observed. When a clone instance of a given method needs maintenance (bug fixing) or further code development (enhancement), usually the tasks would require to be performed on the other clone instances as well for the consistency to remain.

Estimating development costs could be a problematic task. There are a huge number of details that should be taken into account for the calculation, the most important of which probably is the maintainability of the source code. It is axiomatic that maintainability has an immediate effect on development cost, because the less maintainable the software system is, the more expense is needed to develop it.

Code clones (the products of code cloning or copy and paste programming) can be a menace when it comes to long-term source code maintainability. While they seem harmless at first, they will do their damage after a few development iterations – exactly when it is too late for an easy fix. Neglecting to manage clone instances along with each other during a bug fix or a feature development of any of them will likely result in the inconsistency of the source code.

The following case study shows how QualityGate gives an objective, important quality characteristic which was somehow rarely calculated in the past. This characteristic helps the client choose the development company suitable for his needs. The case study also shows how this newly introduced attribute affected a client’s decision. We recommend it to anyone who thinks to find the best developers is of key importance.

In this case study, we demonstrate how Qualysoft – a software development company present on the international market – determined the future development and maintenance costs of a software project using QualityGate.

The following case study shows how the QualityGate source code analyzing and management system has been introduced into a bank environment as an SLA measurement tool – as well as the installation process and the most important experiences of the introduction and pilot period.

In this case study, we demonstrate how Qualysoft – a software development company present on the international market – determined the future development and maintenance costs of a software project using QualityGate.

The TechEmpower – FrameworkBenchmarks GitHub project provides representative performance measures across a wide field of web application frameworks. The project presently includes frameworks on many languages including Go, Python, Java, Ruby, PHP, C#, F#, Clojure, Groovy, Dart, JavaScript, Erlang, Haskell, Scala, Perl, Lua, C, and others. The current tests exercise plaintext responses, JSON serialization, database reads and writes via the object-relational mapper (ORM), collections, sorting, server-side templates, and XSS countermeasures.

The Iluwatar – Java Design Patterns GitHub project provides a codebase with Java design pattern implementations. The implementations have been developed by experienced programmers and architects from the open source community. The source code examples are intended to be programming tutorials on how to implement a specific pattern. Next to the implementations of the design patterns, this open source project also helps developers with textual descriptions of the patterns.

The CTrip – XPipe GitHub project (https://github.com/ctripcorp/x-pipe/tree/master) provides Redis multi-data center replication management. It realizes low-latency, high-availability Redis multi-data center replication, and provides one-key computer room switching, replication monitoring, and abnormal alarm functions.

The popularity of this open source GitHub project can be described with more than 1400 stars (indication of how many people like this project), more than 432 forks (indication of how often the codebase was accessed).

The Google – Auto GitHub project (https://github.com/google/auto/tree/master) provides a collection of source code generators for Java. A Java implementation is usually full of code that is mechanical, repetitive, typically untested and sometimes the source of subtle bugs. The Auto subprojects are a collection of code generators that automate writing such code without bugs.

The Alibaba – Sentinel GitHub project (https://github.com/alibaba/Sentinel/tree/master) provides a powerful flow control to increase the reliability between the services of distributed systems. It takes "flow" as the breakthrough point and covers multiple fields including flow control, concurrency limiting, circuit breaking, and adaptive system protection to guarantee the reliability of microservices. The popularity of this open source GitHub project can be described with more than 16200 stars (indication of how many people like this project) and more than 5600 forks (indication of how often the codebase was accessed).

The Dropwizard.io–Dropwizard GitHub project (https://github.com/dropwizard/dropwizard/tree/master) provides a Java framework for developing ops-friendly, high-performance, RESTful web services. It contains a glue code which makes a set of stable and mature libraries from the Java ecosystem working together, like Jetty for HTTP serving, Jersey for REST modelling and Jackson for JSON parsing and generating. One of the main goals of this project is to enable creating fast Java web applications efficiently. The popularity of this open-source GitHub project can be described with more than 7900 stars (indication of how many people like this project) and more than 3300 forks (indication of how often the codebase was accessed).

The Apache – Shardingsphere-elasticjob GitHub project (https://github.com/apache/shardingsphere-elasticjob/tree/master) became an Apache ShardingSphere sub-project on May 28 2020. Through the functions of flexible scheduling, resource management and job management, it creates a distributed scheduling solution suitable for Internet scenarios, and provides a diversified job ecosystem through open architecture design. It uses a unified job API for each project. Developers only need code one time and can deploy at will.

Hopefully, the reader is convinced by the earlier blog posts that software maintainability is a relevant topic that needs careful attention and also actions taken. In our previous post titled “Improving Software Maintainability”, we focused on those actions which can be carried out to increase the level of software maintainability. Executing these actions costs significant effort. What we should keep in mind when reasoning about such investments is the main topic of this blog post.

Lines of Code is one of the most controversial source code metrics in software engineering practice. It is relatively easy to calculate, understand and use by the different stakeholders for a variety of purposes – that is why it is the most frequently applied measure in software estimation, quality assurance and many other fields. Yet, there is a high level of variability in the definition and calculation methods of the metric which makes it difficult to use it as a base for important decisions. Furthermore, there are cases when its usage is highly questionable – such as direct programmer productivity assessment.

In our previous blog post titled “Sufficient Level of Software Maintainability”, we looked at the different approaches one can use to determine when the level of maintainability is sufficient. In case this level is not reached yet, actions need to be taken. Based on the results of the direct and indirect measurements of software maintainability, one may decide to invest in improving the level of maintainability. This blog post explains how it can be done.

Whether you are an owner, a manager or a developer of a software company, the extent to which you succeed in reaching your short and long term professional goals also depends on how maintainable the developed software is.

Since software maintainability is such an influential concept, we strongly believe that everyone should have a clear picture about what it exactly is, which factors are influencing it and how it can affect your goals set. In order to minimize the negative effects of a poorly maintainable system, one also needs to know what the current level of software maintainability is, evaluate if that level is sufficient and take the necessary corrective actions.

By publishing a series of blog posts, we intend to provide you with all the relevant information on software maintainability that is needed to understand and control it. This very first blog post introduces the subject of software maintainability.

In our previous blog post titled “The Effects of Software Maintainability”, we reviewed what maintainability can potentially influence. To manage the actual consequences, we must be able to control maintainability itself. This requires decision making and the execution of all the supporting actions. The decision making process applied can either be intuition- or fact-based. In this blog post, we will learn about how to measure the maintainability of software systems to extract facts for reliable and well informed decisions.

In our previous blog post titled “Measuring Software Maintainability”, we explained why it is important to measure the maintainability of software systems and how it can be done. Based on the measurement results, some questions arise. For instance: Is the measured level of maintainability sufficient? Which level of maintainability should be targeted? How far is the measured level of maintainability from the targeted one? By when do we want to reach the targeted level of maintainability? Answering these types of questions is crucial since the answers given determine the decision and actions one must take to properly control maintainability. If you are interested in those answers please keep on reading through this blog post.

In our previous blog post, titled “What Is Software Maintainability”, we introduced the concept of software maintainability and argued that it is important to control it. Carrying out the necessary control actions is only possible if we know which the influencing factors are. Describing these factors is the topic of this blog post. By monitoring and influencing those factors, one can control software maintainability.

In our previous blog post titled “Factors Influencing Software Maintainability”, we analyzed the main factors having an impact on software maintainability. It helped us enumerate those things that we can monitor and change to get in control. In order to properly understand the importance of such control, we need to know what and how the level of software maintainability affects. This is the topic we are about to explore in this blog post