Testing is a crucial element of a good development process, and here’s why.
By testing your app thoroughly and early, you can make sure your project requirements are sensible and will allow the app to meet users’ expectations. Proper testing can help you avoid technical debt, improve team flexibility, take on a modular approach and reuse code, and more.
So why are good testing processes so rarely implemented?
The benefits of proper testing
Testing should begin before the first line of code is written. It’s worthwhile to make sure every feature on your team’s to-do list is both doable and necessary, and that there are no big functionality gaps on it. Considering the fact that testing at this stage can prevent huge losses without almost any extra expense, omitting this step seems neglectful at best.
Once that’s done, the testing process should still be well planned out. Issues may have been prevented, but new one are always likely to appear. Neglect, especially early on, can lead to technical debt and huge losses down the line, when extra work needs to be done to deal with the issue. Additionally, a bug-ridden app is less attractive to users, sometimes to the point of driving them away. Investors are less likely to bet on a service that’s not working properly, and resources (like CPU and RAM) can be wasted to deal with performance issues that never would have occurred if the code were bug-free.
Testing should be an integral part of a continuous delivery & deployment approach. This will allow you to provide new features much faster and make users happy without introducing app-breaking bugs with every new version. It’s crucial if you don’t want to alienate users and create unnecessary extra work (and stress!) for your development team.
Technologies that prioritise testing
If you don’t know where to start with introducing a better testing culture to your team, consider picking a tech stack that supports good testing practices. Two frameworks deserve for a spotlight here: Ruby on Rails and Vue.js. Rails boasts a mature testing culture, as well as gems for automatic testing, feature tests and UI tests (RSpec, SidePrism and Capybara). Vue.js, on the other hand, contains a tool for debugging that works as a browser extension. Both are just examples, but features such as these are worth looking into when you’re planning out your tech stack and development process.
iRonin’s step-by-step guide to testing
1. Static tests
As the name suggests, static testing happens while the app isn’t running. It involves checking project requirements, performing code reviews, and everything else that can be tested without running the application. Requirements are probably the most important part to test thoroughly - and the part that’s often neglected. Don’t make that mistake and check for any redundancies in planned features. Finding future defects and spots of trouble as early as possible can reduce the cost of fixing them and significantly speed up development. It also helps to make certain fragments of the requirements documentation more precise, as it will answer developers’ questions and help them work faster.
2. Unit and component tests
Once your requirements have been tested and cleared, and programming work begins, it’s time for unit (or component) testing. This is actually the first stage of testing performed by developers (although in some cases, e.g. particularly large projects, a separate team might be created just to write tests). It’s focused on particular components of the app, and not on the workings of the whole system. The main advantage of conducting this type of testing is that it limits development cost, because these tests can be run very quickly and developers don’t have to hand off untested code to a quality assurance team. The back and forth between the teams is reduced to a minimum. Each iteration is thus less costly, and developers can focus on moving forward rather than on fixing mistakes.
Finding problems with a feature while it is being built limits the time necessary to fix these problems. TDD (test driven development) is a technique which assumes that, before code for a feature is written, the tests for this feature are created - and only then it’s time to write the code. Thanks to this approach, it’s possible to find out whether everything will work as intended before it’s even written!
For unit tests, code reviews (code analysis done by a developer on the team but not the author of the code, performed before the next stage of development) are used to make sure the code meets established standards and that the solutions used won’t cause technical debt or security issues. This is a way for the development team to tidy up after themselves before they move on. Then, when they need to return to a feature or work on something that interacts with it, they aren’t likely to encounter a huge mess.
3. Integration tests
Most apps are built out of components that interact with each other. Testing the integration between them is another important step. Just like with unit testing, developers are usually the ones conducting integration testing. Their focus should be on how an app’s modules communicate with each other, and not on how each functions separately.
4. System tests
It’s finally time to bring the quality assurance team fully into the process (they should have been present since the requirements stage, of course, but this is where they take over the heavy lifting). System tests focus on the behaviour and capabilities of the whole application - how it works, how the components interact and how this affects user experience. These tests are usually divided into two groups: functional, dealing with what the application does, and non-functional, centered on the UI, UX, performance and security of the product. The goal is to find as many defects as possible (ideally all of them) and fix them to improve the experience of interacting with the app.
5. Regression tests
Regression occurs when a previously implemented feature is negatively affected by new code. This can be due to a number of factors, like a team that doesn’t follow established best practices. The whole app undergoes thorough testing, focused on potential bugs and defects introduced with recent features. It’s an integral part of maintaining a high code quality. The testers are able to confirm whether a given version of the app is ready to be released on production.
6. Acceptance tests
This is usually the final stage of testing before launch. It focuses on making sure that the application serves users’ needs and that all its features perform their intended functions. Testers pay attention to the behavior and capabilities of the whole product. The goal at this stage is not to find defects (that has already been achieved in previous stages), but to make sure that the product delivers a satisfying experience to users.
There are many types of acceptance testing, but two of them are the most commonly used. UAT (user acceptance testing) has the client test the app using simulated data equivalent to production data, to check whether the system works as intended. The goal is to run a simulation with “real” users (the client) and data. User acceptance testing helps build the client’s confidence that the app meets their expectations.
The second type are alpha and beta tests. They involve testing the app on real users who interact with the product as they normally would. Alpha tests are ran in a closed environment with a selected group of users, while beta tests are usually open to the public and run on the real production environment (usually the client’s infrastructure).
7. Maintenance tests
Finally, once the app is live and used by real people, there’s a type of tests that help to make sure that all issues have been fixed, all changes work correctly and regression hasn’t occured. At this time, the app is polished and prepared for future growth, by taking measures against hidden problems.
Automation
Automated tests should most likely be a part of your testing process, as introducing them can save time and reduce the effort developers have to put into repetitive tasks. In particular, regression test suites are run many times and generally evolve slowly, so regression testing is a strong candidate for automation. The automation of these tests should start early in the project.
Writing automated regression tests can be a big process at the start, but they are a lot faster that manual regression tests. They can be executed with every new change, even a minor one, and eliminate human error when testing.
Conclusions
In our opinion, most development teams should put effort into properly testing their work. The benefits are numerous, from saving time and money, to keeping users happy and engaged. Many defects in the code can be prevented before they occur, omissions or redundancies in project requirements can be polished out, and the total cost of maintaining a high code quality over time can be reduced. Finally, it brings order into the lives of development teams and allows for better communication and smoother cooperation.
There will be cases when all of the seven stages and automated tests won’t be necessary, but it’s often better to err on the side of caution - or consult an experienced development team to establish a proper testing process tailored to a project’s needs.
If you want to leverage the benefits of testing, like high code quality and reduced development costs, you need experienced testers.
iRonin’s development team puts heavy emphasis on technical excellence and good practices. We’d be glad to share our experience with you.
