Why is QA necessary?

The experience of IT companies proves that maintaining software systems that accomplish complex tasks and often contain several million lines of code requires many resources. A significant proportion of these resources are devoted to testing, while the rest is taken up by porting to the continuously changing environments as well as developing for newly arising business needs. The constant alteration to the code inevitably leads to a decrease in quality. This increasing deterioration can be mitigated by the application of quality assurance methods. The goal of software QA methodology based on static source code analysis is to reduce maintenance costs, which also leads to an improvement in code quality. The technologies used make it possible to assess the state of quality the system is in, monitoring changes and identifying critical and sensitive points. It enables development and testing costs to be planned and reduced, and it supports a more efficient maintenance of the system. The experience gained in commercial and open-source systems shows that by using continuous source code monitoring, significant cost savings and improvements in quality can be achieved in the intermediate and long term.

The foundations of MAGISTER

The QA methodology is based on the widely used, multi-level and product-oriented Columbus reverse engineering technology, which continuously analyzes the source code and monitors any changes. A basic assumption is the only authentic description of the application is the source code itself. MAGISTER’S progressively interconnected components can be employed separately as well; most of them can be set to execute automatically, while manual steps require expert knowledge.

Calculating metrics

According to one of the basic tenets of software QA, the quality of the end product has a strong correlation with the separate phases of the development process. Measuring the software using different metrics is therefore an indispensable tool for successful product management, since processes without any objective metrics are difficult to control. With the help of the Columbus technology, we are able to calculate such well-known product metrics as size-based metrics (number of instructions, number of tasks, etc.), complexity-based metric (McCabe cyclomatic complexity) or coupling metrics (between tasks or between tasks and tables).

Rule violation search

One of the goals of QA is that the product intended for the end user should be free of development errors. How else could we achieve this more effectively than by pointing out actual or suspected error locations in the source code of the product during development?

With the help of the Columbus technology, we can examine development rules in Magic systems that had been compiled by Magic developers with several years of experience in development. Columbus recognizes the rule violations selected and helps to reveal mistakes with the use of SourceInventory.

Continuous measurements

So that the entirety of a development process is successful, continuous measurement of each development phase is necessary. The Columbus technology enables us to monitor the entire development process with regular measurements of even daily intervals. We have the possibility to inventory the metrics and rule violations of individual elements (e.g., programs), or even to calculate and display differences between individual versions.

IT and logical architecture mapping

Mapping the architecture of a complex system is a difficult task, but it is often indispensable for redesign tasks affecting entire systems (ex. migration). Mapping can happen by progressing from high-level representations of the system to low-level representations (top-down) or vice-versa. The typical representations of the former method are IT or logical architecture maps describing the connections between participating serves, systems and subsystems.

The Columbus technology enables visualizing architecture maps created based on case-by-case assessments.

Physical architecture reconstruction

The architecture of an actual application can be mapped on a developer level using automatic tools. The Columbus technology is suited for mapping the programs and objects of Magic systems as well as identifying and displaying connections between them that would be otherwise impossible in Magic’s development environment. E.g., launch connections between programs, connections between menus and programs, access privileges and users etc