Quality as a Service

Producing a quality product requires more than simply producing good code. At Swan, we believe there are three main ‘threads’ that, when woven together from the beginning of a project, produce a ‘fabric’ that will ensure a quality product:

• Agile Methodology
• QA
• DevOps

We have developed Best Practices in each ‘thread’:

Everything is built around agile software development principles and values. It enables transparency, efficiency, and productivity. Our approach focuses on 4 core steps:

Swan believes strongly in a complete, end-to-end QA process. It begins in the Discovery Phase where we solidify requirements by writing acceptance criteria for the product backlog items, and is formalized with a Test Plan during the Design Phase. QA is a set of activities intended to ensure that products satisfy customer requirements in a systematic, reliable fashion. In our world, QA is the responsibility of everyone, not just the testers, and encompasses all the activities we do to ensure correct throughout the development of a new products.

Development of automated test is also a huge part of QA. Here is what the “typical” QA plan looks like for many organizations:

The problem with using visual inspection is that it’s done at the end of the process, which is really too late. The main goal here is to base it on Unit Tests, covering most of the app code core functionality with them. Especially if development is done according to the TDD (Test Driven Development) approach. So here is what the QA plan looks like after you “flip the pyramid” and place an emphasis on TDD:

One of the most іmportant parts of our development process is Test Driven Development. According to our experience – TDD project quality usually is on average 18% higher than that of the non-TDD projects, while their productivity is 14% lower. Developers applying the test-first approach are likely to write more smaller units (methods and classes) than they would write with a test-last ap­proach. Developers applying the test-first approach are likely to write more tests and achieve higher test coverage than with a test-last approach. Developers who have applied both the test-first and test-last approach are more likely to choose the test-first approach. The academic experiments revealed that test-first programmers tended to be more productive, implementing equivalent or better solutions in less time.

DevOps activities include our knowledge in Management of Code Repository, Server Management and Development Practices. Due to our rich experience Swan makes a core focus on setting up a streamlined DevOps processes erasing barriers between Development and Operations.

In our team we have Software Engineering, QA and Operations working as a single mechanism. The main concept is a day-to-day collaboration as closely to each other as possible, locating in same space, doing common meetings, sharing responsibility for the product success all together, on each phase of a product life cycle.

Best Practices that help us to achieve these objectives:

Continuous Integration (hereinafter – CI) is a software development practice, which is to perform frequent automated builds of the project for the early identification and prevention or resolution of any integration problems. This means that at any moment we always have “live”, actual, ready for demo, working product version.

That means:

CI is a part of our agile processes. It works well in combination with the TDD approach and rather than running all unit tests in the developer’s local environment and verifying they all passed before committing, we follow the concept of using build servers to automatically run the unit tests periodically and even after every commit, and report the results to the developers.

It helps us to accelerate delivery (we get informed earlier about any conflicts or issues and can fix them faster), optimize resources (less manual work) and increase system stability (if any unit test gets failed none of made changes will go to production until fixed).

We use Version Control Systems such as GIT or SVN for managing our development process. This allows tracking of any code changes and makes code review easier with pull requests. A key ‘best practice’ is that each user story is developed in a separate branch.

Is a software verification process with all main functions and steps (initiation, initialization, accomplishing, analysis and reporting) made automatically by automated tools, with no need for any personal involvement.

Each next new build is to be tested as fast as possible. The best tools for that are: Unit tests, UX tests and Integration tests. The main rule here is – they all should be automated. With the help of automated tests we can immediately receive information on whether we have any conflicts or errors in our build and if yes – we can fix them immediately.

This helps us to better optimize resources, decrease time needed from bugs detection to fixing, all while excluding the human factor impact.

Continuous deployment is the next step after a successful Automated Build and a ‘passed’ Automated Test. It includes automated installation (deployment) to the needed environment (testing or production).

The core value here is to deploy as often as possible.

Configuration Management is a detailed description and updating of information regarding software, equipment, versions, updates, hot fixes, custom configurations and add-ons, network data etc.

These are needed for having the system easily accessible and clear for support, faster detection of issues and flexibility. Without comprehensive documentation, it becomes really hard to maintain the application when adding more and more new functionality and more and more users.

The main aim of Load testing is to define the application performance and latency under high loads as well as stress resilience.

That’s the usual case for web applications: everything works just fine, a page opens really quickly and reacts immediately to any user actions when a couple of developers or QA engineers are working with it. But, when changes get to production and thousands of users start working with the same page real issues appear: long response time, terrible UI lags, server failing etc.

Load testing allows us to find problems at an early stage, before it goes to the production server. It can be done by generating a big amount of requests to the server and then analyzing its behavior.

The main value is improvement of deployment quality, finding performance bottlenecks and maintaining a constant application quality.

Application performance management is about continuous monitoring and management of system speed and availability on production.

Load testing finds most issues long before the build gets to customers. But, unfortunately, it’s not always easy to anticipate all future user actions as well as the impact of the difference between test and production environments capability.

That’s why we always need to monitor status and production to be able to react immediately to any unexpected issues.

DevOps is how the future product will show itself in a real world, on production. It’s all about its reliability, scalability, speed and maintainability. It defines how quickly we respond to changing clients’ demand and issues. How often will our cloud-based system go to “down-time” due to its updating with new changes? How much time will each update take? How many new bugs will appear after each new functionality gets deployed to production?

We are confident that a carefully thought-out and established DevOps process will reduce costs and produce satisfied customers. Swan is a customer-success-driven company and we understand the merits of a quality product being dependent upon correctly built processes.