Why software testing is important in software development
Buying new technology can and should be an exciting process, whether you’re simply implementing a much-needed upgrade of current software or leading your company’s first big leap into the 21st century (kicking and screaming in some cases).
So you’ve sat down with the relevant team members and thrashed out your requirements, crunched the numbers, consulted with the experts and found the provider for you, that’s all the major hurdles right?
Wrong.
One of the biggest obstacles in the Software Development Life Cycle (SDLC) is still yet to come – testing your software. Any travel technology company you work with will factor time to test the software into the project timeline, and as well as testing internally on their side, often the software will be released to your team to test.
The goal of testing differs slightly on each side of course; fundamentally the provider will be ironing out any technical bugs before the product is released to you, it is then that you will test the software to ensure that it ticks all the boxes and meets the needs of your audience. This is particularly true if you have invested in bespoke technology instead of a standard product, in which case you will likely have already had a demo.
You may ask why software testing is important? Well, the whole point of purchasing new technology is to streamline your internal workflow with the overall goal of increasing your profit margins, especially when it comes to Internet Booking Engines (IBE). Put simply, overlooked errors or a bad user experience for your customer means loss of money for your company, and this is the main reason why software testing is done.
But why do we need to allow so much time for testing? Well firstly it’s important to remember that we all make mistakes (developers included!) and it would be irresponsible on the provider’s part to release your software to you without a proper inspection, but there are a number of reasons why software testing is used and why it is so important within the SDLC …
There are no easy fixes
It is essential that we as the provider sniff out all errors and possible limitations ahead of handing over the product because as well as finding them; we also need to fix them.
For technical projects this often means extensive coding and expert discussion amongst developers, whilst maintaining a keen eye on the original requirements. We don’t just want a solution, we want the best solution – none of us want to have to keep revisiting the same problem.
Furthermore, if your team finds during testing that while something works, it does not work or look as you expected, then we require some leeway to implement any changes.
You may worry about even more time being added on to the project and, while your provider will have accounted time to fix technical errors in the SDLC, it is possible that matters of User Experience (UX) could delay your release date – depending on how complicated the requested alteration is.
However, pushing out a system with errors, whether technical or experiential, has the capacity to cost your company more in the long-run than waiting a couple more weeks to go live. Be patient, we are all working towards the same goal!
Errors can be subjective
You may have heard about Automated Testing, which is a great way of speeding up the testing process, however there is a reason why Manual Testing performed by real-life human beings is still important.
As mentioned above, sometimes testing can flag up UX issues that are arguably a matter of opinion and differ from person-to-person. We must also take these problems seriously as the end-user is after all going to be a human being with certain expectations of how the system should function. Your provider’s testing team will look out for these issues, but no one knows your customers better than you!
During testing procedures there is one phrase that sends shivers down a professional software tester’s spine – “No user would ever do that!” From a technical perspective, it may be that an error occurs after an interaction that it seems unlikely anyone would ever carry out in the real world, however this is a moot point because if we’ve found it then there is always the chance a customer will too – especially with a travel booking engine that is available to the entire world wide web.
Testing isn’t just about finding technical errors; it is also about ensuring quality for your customers, who will all have different ideas about how the system should serve them. Brushing past this will only result in abandoned bookings and possibly damage to your company’s reputation.
We are all looking for innovation
Everybody wants something new and original these days, particularly within the travel industry where competition is fierce. We all want tech that is going to set us apart from other travel companies, while still meeting the needs of our customers.
While most travel technology companies welcome the challenge of something completely new and will consult with you about how to realise your grand idea, it is entirely possible that the project will hit limitations that haven’t been considered because no one has ever done it before.
Furthermore, “innovation” quite often means customising a standard product with extra features, or slightly altering existing features. In the case of web booking engines, for example, you probably still want to include some form of Dynamic Packaging or to integrate a Payment Gateway. This presents another potential problem, which is that new features can sometimes inadvertently throw out or overwrite existing ones.
Software and applications are held together by extremely complex sheets of code, which must “communicate” with each other in order for them to work correctly. By adding new code we risk overwriting these communications or duplicating strings.
Seeking out these errors is what we call Regression Testing and needs to be done by us every time we update or change our technology.
Testing to maximum capacity
What works when one person uses the platform may not work when there are multiple users logged on, which is a problem if the product is going to be used by the general public.
Your provider needs time to give the software a real workout and assess if the speed is affected by multiple users and what this means for your audience. Only by testing can we find out the answers to these questions, the technical reasons behind them and, most importantly, the solution.
We need to know as much as possible about how the system will react when it is live for public use and could potentially be accessed by hundreds of users simultaneously.
The important thing to remember when you are testing is to not get too downhearted when issues are found, this is exactly what the process is for and when software testing is complete we are left with a sturdier and more user-friendly product.
Here in the Billian office our testing motto is “Try to break it!” – well, rather us than your customers right?
Enjoyed reading this blog? To share your thoughts on this article, tweet us @billianIT or join the conversation using the hashtag #tech4travel