Test-driven development can be the saving grace of startups and small companies, allowing them to save time and money, and deliver much sleeker apps to users. If your new product is full of bugs, how likely is it that early adopters will stick with it and promote it among friends? Not very. This is why early testing is 100% worth the investment. Find out how to implement it without making the 5 most common testing mistakes.
Startups and young companies should begin testing as early as possible
The sooner you discover errors and bugs, the easier and cheaper it will be to fix them. You can start well before development begins by testing your project specifications and documentation, or client requirements in the case of outsourcing. Testers can discover potential issues at this stage, before implementation or even the start of the development process. Thanks to this approach, it’s possible to predict problems and devise solutions in advance.
Tests help discover issues with understated or underdeveloped specifications, too. Testers will ask questions someone involved with the project wouldn’t think of, thus their perspective will be closer to that of a user. Unit tests are also important. Developers create them as a first step that will let them know whether their code works according to specification and whether regressions has occurred, that is, whether existing features work as intended despite the addition of new ones
Do integration testing and system testing next, focusing on the capabilities of the whole product, then fix any emerging issues. This won’t take much time, compared to going through the same process later on. And it will be easier to deploy a well-tested app. The whole testing process will also help with building new features. The development team will know whether regressions happened. This way, you can catch problems as they appear and address them immediately.
Test-driven development creates the opportunity to reduce feedback loop, thus reducing costs: errors are found through tests, and developers can fix them before submitting the task for review. The reviewer doesn’t then have to spend valuable time on bug reporting or providing the details on the issue.
Mistake 1: Rushing the release and/or fixes
In one of iRonin’s internal projects, we use a certain app built with Ruby on Rails as a repository and for code management. For a time, code review was impossible because there was no way to add comments: the comment icon in the app wouldn’t work, and the comment window wouldn’t show. This was caused by the too-fast release of the app without proper testing. After we made the creators aware of the issue, they quickly fixed it, but a new issue cropped up: this time as the user attempted to save the comment.
Unit testing would have likely prevented this from ever happening. A commenting functionality is usually quick to test, but here, it was obvious that untested code had been implemented in the production environment. This had a disastrous effect on user experience, and definitely caused a lot of stress to the people who needed to fix it.
Mistake 2: Not committing to regression tests
With bigger and more complex applications especially, regression tests done wrong can have serious repercussions. Important functionalities can stop working and valuable data can be lost. Obviously, this could end up being very costly to fix and manage. We learned about a case where the basic functionality of the app worked, but one module made available to only a small group of users wasn’t tested as well as the rest. This group of users did not received certain data, which meant their module wasn’t being kept up to date. This was caused by lacking regression tests, where a new functionality unrelated to what eventually stopped working was introduced and caused mayhem.
Mistake 3: Omitting unit testing
A lack of unit testing, which should be performed by developers, might not seem to be an issue early on. But should the app be developed and upgraded, old functionalities may stop working or stop being compliant with specifications. Adding unit tests later (rather than during development) comes with a much higher cost. This is because developers who write the tests after some time has passed need to go back to sections of code, consult the specifications, find out what each functionality is supposed to achieve, analyse the code, and only then can they write the tests based on their conclusions. This is obviously time-consuming and wasteful.
Mistake 4: Not having dedicated testers
It might be tempting to dump most of the testing on alpha and beta testers, and have no one on the team solely responsible for testing. But users will only test the parts of the app that interest them, which means the most rarely used functionalities won’t be tested well enough. And when the need to use them arises, there might be a plethora of errors that will ruin user experience. A dedicated QA engineer or a team of testers can easily prevent this by applying a methodical approach and testing all parts of the app equally.
Mistake 5: Beginning testing after development starts
Functionality planning is when the first stage of testing should happen. Without a tester looking through the functionality plan (documentation of what the app is supposed to do) and finding potential problems, some issues might remain unnoticed throughout development, and even through many iterations. At that late stage, when most elements of the app are already implemented, fixing a single mistake can involve rewriting a large chunk of code. But if a tester were available at the planning stage, this could be resolved before any code was written. And costs could be significantly lowered.
Prevention is better than fixing mistakes
The most important part of testing might happen early in the product life cycle, before development begins, at the planning stage. Many issues can be caught very early on - issues that are easy to miss by the developers or stakeholders. And after these issues are identified, it’s easy to plan around them and prevent heavy losses in time and money.
Another crucial thing is automatic acceptance testing, where some manual tests can be exchanged for automatic tests, which are much faster and eliminate human error. Once implemented, automated tests can easily be run after every change made to the code, which significantly lowers human involvement and the cost of testing, while improving the quality of the testing process.
A good tester needs an outside perspective
Your tester shouldn’t be someone who has been working on the project from the start. They need a fresh approach to the code. This way, they won’t be biased, won’t have an emotional attachment to the code, and they won’t know what each line of code should do at the outset, so they’ll need to figure out the logic on their own and will be able to discover issues a developer would have missed.
An external testing team may work better than an internal one. They will have less experience with the app, which will make their approach fresh and unbiased. They will also have more experience with testing various types of apps and a better process for it. These are very good reasons to consider outsourcing the testing of your app.
If you want to develop a Ruby on Rails app and start testing early on during the planning stage, we can help.
iRonin’s QA testers have a breadth of experience with various types of apps. We always strive to make our development process smooth and prevent issues from occurring, to save our clients’ money.
