What Goes Wrong When You Forget About Testing? Part 1. Pre-release
3 reasons to test your product before the release
Some companies treat the testing process like the visit to a dentist. No one cares until nothing hurts, but when the pain comes…oh, we just prefer to use some painkillers and wait for another week, do we? ;) For good or for ill, the software development project isn't a bad tooth, and if you want to have your product all stacked and money making, you don't have the luxury of postponing the testing.
Testing should be carried out both throughout the development process and after the release in order to maintain the quality of the product at the appropriate level and not to accumulate loads of critical errors.
At the same time, we often encounter the misconception that the product is good to go after the functional testing only. And hiring a full-time or outsourcing tester for the continual software checking is a waste of money and time.
So let's move the testing from the "Costs" column to the "Investments". When developing software, you invest in future profits. As the causes for testing before and after the release differ, we’ll start from the beginning. In this article, we’ll describe the main reasons for product testing before the launch.
Reason 1. Compliance with the Deadlines and Planned Release Dates
If the tester can’t find a place in your team, then your product also might not find its place on the market.
For example: someday your project manager reports that builds crash one by one, programmers can’t identify the problem on the spot, and don’t want to do it at all. Therefore, they can't launch the project in July, maybe in September.
What Can Go Wrong?
Not all cases require the launch in scheduled period, but let's review this ultimate goal situation. Promotion strategy is already thought through a few steps forward; banners in major online publications are booked for the near future and are confined to July. Competitors don’t waste any time, so your currently original content and advanced functionality would become a common thing by September. IT market is growing like it's on steroids, so if you won’t jump in your niche first, the dream of extra profits and eternal glory will remain just a dream.
Sure, developers are able to find obvious errors, but the most insidious critical bugs are far too often hiding deep in the code. Therefore, it’s up to the tester to detect a sequence of actions that cause crashes and unstable operation of the product.
Reason 2. Big Plans
In your opinion, the product is just perfect – it runs like clockwork, it’s functional and useful. Right. However, the user might have a drastically different experience! And if you are hoping to leave the competition far behind or break into a world market – you need to check the product for bugs.
What Can Go Wrong?
The user finds the bug instead of tester. Ideally, he will notify you about it via email, contact the support team or group administrator in social media and ask for help! When you earn such a loyal user, cherish him and never let go.
But let's review some less positive situations. The user will delete your mobile or desktop application, stop using your service and forget about its existence for good. He will use your rivals’ software with less rocking functional, but it’s stable and checked for errors a long time ago. It’s just like in real life – we prefer to find another company with similar services of high quality rather than try to get what we want by conflicting.
Reason 3. Questionable Product’s Quality
Acceptance tests are carried out in two cases:
1. When the product is being developed within the in-company team, but there are doubts about the readiness of the project for the release, and it is a good idea to use some independent testing.
2. When the software development is outsourced. If the project is large, then individual teams from several companies might create each separate module. Each team might has its own tester, and who knows how responsible or competent are all these guys? In this case, independent testing is also applicable for collecting all product’s parts in one structure and checking it as a whole.
Let us justify the meaning of the third party testing.
The end customer takes the decision on the readiness of the project. The client must determine whether the product meets the requirements, performs the necessary functions, and doesn’t contradict the common sense. But most of all, the customer can check only some superficial aspects, such as convenience and appearance of the interface and functionality.
This is insufficient to ensure the quality of the product code and its “purity”. As we have said, the in-company or third party team has its own testers and developers. They can provide you with their user scenarios; promise you oodles of money together with an immediate correction of errors, if users will suddenly find any.
What Can Go Wrong?
If your product isn’t tested enough, then after the launch it will make new users “happy” with crashes, non-working buttons, infinite loading and other more or less annoying bugs. It is fraught with huge whataboutery, along with time / financial expenses.
It doesn’t matter, whether you a newbie or a seasoned player – you can’t afford to risk your reputation and name. Therefore, testing is entrusted to an independent third party company.
Apart from the usual ways of testing the product, there is also the User Acceptance Testing (UAT), the final stage of acceptance tests. It sometimes requires preparing both the end user and the software:
- Develop individual testing methodology for the project to generate the relevant and full user scenarios.
- Prepare the tests.
- Conduct an independent testing to be sure of successful product's customer acceptance.
The competition on the software market is too high to afford producing buggy products. After spending a good part of budget on development, you surely don't want to miss out your profits because of any minor errors, which removal would take an hour or two.
Checking your project in due time, you don’t wait until the toothache comes. You directly enter the dentist's office with a big beaming smile! And leave it with the confidence that everything will be fine.
And if you still decided to be patient and managed to launch the product without the adequate testing, well. It's no use crying over spilt milk, but something can still be done. And this would be the subject of our next article.