But do I need quality, huh?
I can imagine an unlikely but nonetheless possible scenario when code quality isn’t on your priority list. You need to build your MVP or proof of concept as quickly as possible, not planning to develop it further. At least not in a given technology and current shape. It could happen, right?
Apart from similar cases, yes, you need quality. You need it for your digital product to work (simple as that), to be able to develop it further without technical constraints, and to avoid technical debt that would be costly in the long run. And this is where we come in with a list of tests that will ensure your software quality.
First things first: a plan
Boooooring, huh? Plan, strategy, starting with why – they all are big words these days. And there’s a reason behind it. Sorry not sorry, it is a test plan that allows your team (managers, testers, and developers) to test implemented solutions, in terms of not only code quality but also business requirements. With a good test plan, everyone knows what to do and nothing is left to chance.
Your test plan should collate the information on:
- strategies for particular solutions testing
- test cases and requirements
- testing environment
- test execution and showing results
- metrics for testing-related activities
If you conduct tests for your client, the plan should be handed to them, so they know you put your money where your mouth is.
1. Code Quality Assurance
To ensure the high quality of the source code, we apply Code Quality Assurance procedures. They relate to the way of working with Git repository, performing code review, and following best coding practices. Their final look depends on the very project – its size, client, and needs.
The basic rules and procedures worth mentioning here are:
- All code is hosted on the source control management (SCM) system, preferably on de facto industry standard Git.
- The branching strategy has to be adjusted to the individual project’s needs (Gitflow, GitHub flow, etc.).
- The Continuous Integration process ensures that each code contribution is independently verified by automatic systems. This method guarantees that all existing tests pass, the code style is followed, and the established project’s code principles are met.
- All changes introduced by the team are subject to the verification process (so-called code review). To become a part of the product’s official code base, they need to be reviewed by fellow developers.
2. Unit Testing
Unit tests are used to examine the smallest pieces of source code that can be separated logically within a system, commonly individual functions or classes. Unit testing verifies if they work according to the design – and are ready for use.
This method allows us to find problems early in the development process. Components that didn’t pass should be fixed right away because they can negatively impact the whole application. However, in the end, it is a whole functionality that has to work efficiently.
Unit testing should be an inherent part of the development cycle – the first level of testing to be precise – to keep high code coverage. It leads to project predictability, process repeatability, and error elimination. They can be run by developers (which applies to all test types but manual) but performing them automatically during Continuous Integration (CI) pipeline runs has become an industry standard.
3. Integration Testing
Integration testing is the next phase that comes after unit testing. This time, system components (that have been covered by unit tests individually) are examined in groups. The process verifies that implemented components work together correctly in various scenarios.
Integration testing verifies that implemented components work correctly together.
Integration tests are a part of regular development. They take place when all components/dependencies of a given functionality have been designed and their interfaces allow us to test interactions between them.
Again, they can be run by both devs and automatically during the Continuous Integration process, the latter being advised. If we’re testing ready modules that have been already implemented, then we drift towards functional or end-to-end testing.
4. Performance Testing
Performance tests evaluate the application response time, stability, reliability, and resource usage under an assumed load. Their main aim is to identify and remove performance bottlenecks.
We do it by simulating actual and average user traffic in the system – so it reflects the real use. We do it up to their critical number – because we don’t want performance testing to change into stress testing. Performance testing is an effective way to detect system performance problems that need improvement.
Nowadays, performance testing takes place for the system that’s deployed on the environment as similar to the production one as possible.
5. Stress Testing
Stress tests are a particular case of performance testing. They verify that the system is operational and all functionalities work well even when it’s used under significant load – multiple users launching it at the same time and/or performing complex, long-running operations. The process is deliberately intense, often reaching breaking point, to identify performance bottlenecks and estimate the upper limit of users that can access the system at once.
6. User Acceptance Testing
UAT aims to ensure that the software can handle real-world scenarios and its end-users can operate the system as defined in the User Requirements document before it gets into the market.
In the case of smaller apps, user acceptance testing can be performed manually by a tester and business representatives not being members of the development team. However, usually, the process is automated. User actions are recorded as macros and replayed over and over again. Automation is highly recommended here, otherwise more and more errors would arise after a while, because human errors are inevitable.
UAT can take place independently from other test types. More, performance and stress testing can draw from scenarios written for them. In this case, a selected group of UAT macros are repeated more frequently, e.g. 1000 times per minute.
7. Regression Testing
Regression tests are performed to verify that the implemented changes and updates haven’t affected already existing parts of the system, which had worked perfectly before. This testing practice ensures that everything functions as expected (if it doesn’t, we call it regression). When a regression is found, corrective actions should be carried out in no time.
Regression testing performed manually in every Sprint would mean never-ending work. Thus, we do it automatically by running all user acceptance tests once again after a change has been implemented.
Summary: 7 test types to ensure IT project quality
- Code Quality Assurance
- Unit Testing
- Integration Testing
- Performance Testing
- Stress Testing
- User Acceptance Testing
- Regression Testing
As you can see quality is a result of a habit – regular, many-sided testing that involves developers, testers, and business representatives, but wouldn’t be possible without automation. For more on testing and its benefits, go to our Quality Assurance service site.
