Subject: Testing of enterprise application software
Keywords; testing, enterprise application software, enterprise software
Title: Testing the Enterprise, Written by Robert Oakley
3 Minute read
Did you know that the term ‘Enterprise software’ is, in fact, a reference to Star trek?
This is not a joke, “Enterprise software” used to be called “Information Systems Software” and although the term “Enterprise” had previously been used to describe complex systems it was not widely adopted until a marketing campaign and content rights deal between BMC Software (then known as Boole and Babbage) and Paramount pictures. Watch the Original infomercial here.
What is Enterprise software?
Enterprise software is the term used to describe a collection of software and applications used by an organization to solve its company-wide issues rather than the issues of individual departments or users – so rather than creating software that does a specific job in one department, we use a large complex system that facilitates the needs of the whole company. Done well this is a perfect cost-efficient and integrated solution, done badly it means that the whole company is forced to use the same software that doesn’t quite do the task well – which is why testing and planning are so important.
Examples of enterprise software are ERP solutions, CRMs, Marketing Automation, and Business Intelligence systems – these systems are now commonly found packaged as Cloud-based (SaaS) implementations.
These days there is so much data that is easily accessible due to technologies such as cloud computing, that the software that a company uses can quickly become very complex and difficult to maintain.
About 20 years ago I worked at a company that developed real-time online auction system software (yes using painfully slow dial-up internet connections) and our testing process involved writing test scenarios, developing a test plan and then getting a developer to write a test script. Our load testing was getting as many employees to log in to the system and ‘use’ it as much as possible at the same time to see if it broke – very time consuming and not very robust. Sometimes when things did go wrong it was not always possible to find the cause, which kind of defeats the point of testing.
Thankfully these days the science of software testing and test automation tools are highly developed to take away much of the manual work. However, systems are also infinitely more complex, and therefore testing is still a major task requiring lots of planning.
What are the common types of testing to be carried out on enterprise application software?
Let’s start with the tests carried out by developers – these are commonly called Unit tests and they test that small parts of code (units) do what they are supposed to.
Next, we have integration tests. These are used to demonstrate that different parts of a system actually work together.
Regression tests are used to test a system after changes have been made and are a combination of unit and integration tests.
Acceptance tests make sure that features or the intended use cases have been correctly implemented. You might want to get the users involved with these tests, as they should closely match real-world use.
There are many other types of testing for; performance, functionality, business logic, usability, hardware compatibility, and stress tests like load tolerance.
With so many things to test it is surprising that any software makes it to production. This, of course, means that you need to draw the line under your tests at some point and get systems up and running, which is why all software contains bugs.
There is one other type of testing that you should not forget which I recall from a story one of my university professors told, which served to highlight the importance of understanding users behaviour and processes and in testing documentation also. The story was about the development of a medical device in a hospital. People had been using a device for years and several workarounds had been implemented and adopted by its users to account for failures in the software or mechanical design. The company wanted to develop a new machine and software – which they did and it worked perfectly. But the problem was that when the new machine was used it wasn’t necessary to do the now habitual ‘workarounds’. The user documentation expected that users would carry out the procedure in a certain way and did not take into account the way it was actually used. The result was that the new and perfect system did not work at all.
The point is that you really need to understand your users and how they use the product when you are testing. I am not saying you need to build in existing faults, what I am saying is that you need to know what issues exist and make sure that your documentation is fit for your audience, and it too passes testing.
Yes, test your documentation too!
What is this post?
Thank you for reading this post. This is an example of my writing that tackles a highly technical subject but in an easy to understand and fun way. It was written as an example for a client as part of the application process, for a project. They loved this article but they didn’t need to publish it, so I thought I would share it on my blog. If you liked this article and are interesting hiring me, please drop me an email, or leave a comment below.