Quality Assurance and Testing with Continuous Integration

To ensure efficient and timely Quality Assurance (QA) in software development we combine a mix of unit, integration and functional tests on a test server environment with continuous delivery. Thus, we achieve direct cost savings during development and fast development cycles.

To guarantee the quality of our software and products ABTO Software goes through continuous quality process during development applying Continuous Integration (CI) rules to provide developers with the means for checking their code quality and being warned about any problem.

Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. It helps merge all parts of the system as often as possible during the lifecycle of the project.

Continuous Integration Process Overview

CI Diagram

The following diagram shows how ABTO Software applies the features of testing and deployment on .NET Web Applications stack which fit into continuous integration.

ABTO Software's Continuous Integration Process Diagram

1.  Part 1: Developer’s part of work

Team Process at ABTO Software

  • We use Scrum methodology for the whole Quality Assurance and Testing process.
  • The Development Process in each team starts when each developer gets his own “story” for development which includes the following stages: Investigation, Development, Code Review, and Deployment.
  • All the changes are fulfilled in three (or other quantity) different Source Code Repositories (for code, configurations and databases correspondingly).
  • Each developer commits his code to a specific Feature Branch on the basic remote repository depending on the needs (code, configurations or DB).
  • After each development step, the code is tested by Unit Tests. All smoke tests are performed on developers’ local IIS. Integrating the code and then running smoke tests right away let developers know that their project is testable and that they are free to continue with their work, passing the build off to QA.
  • After publishing the code turns into its “visible and acceptable” form for the website.
  • Someone from the team (and from other teams in case of a major story) reviews all the committed code. In case code review isn’t successful, a developer makes necessary modifications and commits the code again. Code review is performed until it gets successful.
  • Then each Feature Branch is merged to Team Integration Branch correspondingly (code to code, etc.) So all the data appear to be in that branch on which Team Integration Server is working.

2.  Part 2: Team’s part of work

Team Integration Server

  • Team Integration Server is the server where all latest modifications from each developer inside a team are merged.
  • We use TeamCity/Jenkins tools for automated builds and QA Units.
  • All the stages described in “Team Integration server” part of the diagram are fulfilled including Selenium and Manual Tests.
  • If our QAs’ testing results are successful, then all the committed code, configs and DB scripts are merged into System Integration Branch. Otherwise, the developer reopens the development cycle including coding, smoke tests, code review and merging into team integration branch. The cycle continues until the manual tests of the QA team pass.

3.  Part 3: QAs’ part of work

System Integration Server

  • System Integration Branch is the branch where stories from different teams are merged together and automated regression tests are run upon (using verifaya.com).
  • For the most complicated stories some manual testing is performed as well to cover all possible test cases.

4.  Part 4: Operational part of work

  • Release Branch is built on the basis of the committed and tested code, which later on is deployed to production.


Load Server

  • Load Server tests the website’s performance under high load. Performance tests are conducted by means of various tools, e.g. JMeter, for testing all visible website pages.
  • Sometimes Staging Server, whose architecture is similar to production, is also needed. It has several web servers and database servers.

Continuous Integration Benefits

We find Continuous Integration extremely beneficial and best fitting into ABTO Software’s quality assurance lifecycle. Our both development and QA teams see a number of advantages in using a CI system, such as:

Reducing risks: The CI system helps us detect system development problems at the very early stage and identify builds that contain errors for our test team not to waste time working with and installing bad builds. So our QA team can focus on higher areas of risk while the CI system runs automated regression tests.

Reducing costs: an automated smoke test (as well as regression, performance, load, and stress testing) by means of CI system takes twice less time than manual one, leading to sufficient cost savings.

Project visibility: Using CI system’s powerful reporting abilities, we can observe some trends which help us make effective decisions with reduced time but increased accuracy of planning and execution.

Code quality: A CI system allows our team to produce a deployable piece of software at any time as long as it has no defects or errors, ensuring measurable and visible code quality. As our team continuously integrates their software changes, better software is produced and tested more often.

Reducing repetitive manual processes: Without the CI system we would have to manually investigate each build including smoke testing and regression testing. Though now practically any test is automated and executed by the CI system.

Call, Skype or just use the Contact Us Form to get in touch with us today!