Testing Enterprise-Grade Software: 5 Pitfalls to Skirt and How to Do So

Enterprise-grade software cannot only be a major development challenge, but also a formidable challenge for one’s QA & Testing team.

Are there any specific problem areas to pay attention to or specific QA approaches that can help?

Our QA Team Knows the Answer

“Enterprise software…” The phrase conjures up a bunch of associations, ranging from sprawling legacy enterprise systems to development challenges that spell years of arduous work and just as much hassle.

While a lot has been said about the approaches and techniques that facilitate enterprise software development (and we’ve offered our mite in this department too), less attention is paid to the testing peculiarities of enterprise-grade IT projects.

Simultaneously, as these projects are usually implemented by more than one development team using a boggling variety of technologies, they become bug-infested shortly after the kick-off. In many instances, what was initially seen as a long-term cash cow turns into a resounding flop.

Can anything be done to help avoid time losses, extra costs, failed deadlines and dilapidated projects?

Our QA experts answer this one in the positive, and they’ve pretty much seen it all when it comes to enterprise stuff.

Here’s what they’ve told us.

Problem 1

As we’ve already mentioned, enterprise-grade software development projects tend to represent major and pretty variegated affairs. Multiple project teams that have varying qualifications, programming styles, and work habits create a diverse panoply of functionality that seldom stays unaffected by all these factors.

Wide-ranging team locations, different languages and different time zones all add to the roster of the factors that impact the project quality. They make the informal communication between the members of the different project teams a lot more difficult.

Remedy

Do not undertake the testing of any of the system functionality without an agreed-upon documentation package. Among other things, this package can include:

• A Test Plan – a document that describes the testing process in a formal way and enables a QA team to prepare for the testing to be performed in advance.

  With a Test Plan, one can easily list the project requirements, while making sure they are sufficiently clear prior to the beginning of the testing process.

  Similarly, one can determine the types of testing that need to be employed, and come up with a list of the tools and techniques, required to conduct them. Thus, the team will be able to prepare the required testing environments, distribute the testing tasks between themselves, and define the input and output testing criteria already at this point.

  What are the benefits of doing all the above beforehand using a Test Plan, and not when the testing is just about to begin, or, still worse, is already underway?

  These benefits are quite many and quite significant:

  1. You can determine and try to eliminate the factors that are likely to ill-impact the quality of your testing or even make this testing entirely impossible.

  2. You can order beforehand any lacking tools and environments that may take quite long to fine-tune and start using them earlier.

  3. You can estimate the testing time more precisely, and, therefore, be more precise in your forecasting and reporting. Your task allocation will be a lot more efficient as well.

  4. You can continually adjust the testing process on the fly in order to minimize the risks involved.

  5. You can forecast the risks that are likely to arise and have plenty of time to ponder/recommend ways of mitigating them.

  6. You can make the testing process more transparent to your development team and some other project stakeholders.

• A Test Report, - a document that is intended to inform one about how compliant a product is with the project requirements.

In some instances, a Test Report can also provide detailed information on the testing that has already been performed. For example, they can include the time spent, bugs that persist and still require fixing, and the types of testing that have been used to date.

A Test Report can be used to determine whether a product is ready to be released.

Problem 2

Being typically an amalgamation of diverse (Web, backend and mobile) functionality, almost any enterprise application is also planned to be integrated with multiple external systems. This generates a multitude of related defects, strewn along the “seams.”

Remedy

If you need to test an enterprise-grade software application, you should:

• Pay special attention to Integration Testing and conduct a sufficient amount of this type of testing.

• Make sure that the QA & Testing team, involved with the project, has a sufficient amount of Integration Testing experience. Actually, the more, the better.

• It may prove hugely helpful to involve your Business Analysts in your Integration Testing. Their knowledge and holistic view of your system can help pinpoint the problem or prevent some adjacent system areas from being impacted.

• Your Business Analysts should create as many Business Cases for testing purposes, as possible, before your Integration Testing is underway. This will promote an integrated testing approach and help ensure that the different parts of the system functionality, involved in a business process, interact with one another and support this business process as planned.

• We could also recommend using an awesome y BA tool, invented by our Business Analysts and called Integration Case Studies.

  In short, Integration Case Studies describe how the different systems interact within a workflow, initiated by one of these systems. The system, which initiates a workflow provides a data input, thereby causing the other systems to interact with one another.

  Our QA and BA teams have collaborated on several enterprise projects through the medium of Integration Use Cases, and this approach has, really, given our testing efficiency a huge boost.

• All the required system integration must be prepared and arranged for before the solution goes in production. If the integration effort needs to involve an external system that cannot be integrated with before the production phase, the party that owns this system must provide real-time data, required for the integration, beforehand.

Problem 3

The wide-ranging functionality and large number of developers and other experts involved make it difficult to trace bugs to those responsible. It is difficult to keep track of what has been done in order to fix these bugs and to manage the outcomes. Sometimes, it is even hard to identify the developer, who is responsible for, or just familiar with the problem area and to whom a bug can be assigned.

Remedy

Try to increase the amount of end-to-end testing. From the beginning, try to involve those QA engineers, who are skilled in end-to-end testing.

It may help to use two differently experienced QA teams simultaneously. One of them must be more experienced in business value-related testing, while the other one must be more versed in development related-testing.

Big-Time IT SOLUTIONS to BIG-League ENTERPRISE CHALLENGES

Problem 4

Any complex enterprise system provides a lot of diverse functionality and there is always a myriad of features to be tested.

In the majority of instances, these features look the same to a QA team in terms of their business value to the client. The QA engineers either process them mechanically one by one, or make the blunder of giving precedence to what is more bulky and complicated and not more important.

The feature set behind a small button, appearing on a mediocre-looking screen and hidden in the bowels of your system, can be one the rest of the system is just of no use without. By contrast, something big and complicated may well be something your client can do without during the next couple of years.

Remedy

• You can request the Business Analysts, working on your project, to make a detailed presentation of the project to your QA Team. This will help your QA engineers gain a better understanding of the business value of the system's different parts to the end user.

• You should create a knowledge base for the project and make it available to your QA Team. This knowledge base must contain all existing project-related documentation. It must be supervised and regularly updated by your Product Owner.

• Your Product Owner must put on your QA Team’s radar any newly appeared functionality that has a greater-than-average testing priority.

Problem 5

The functionality of any enterprise solution covers a large number of intricate and complex business cases and workflows. Only real-time data can allow you to test your system’s ability to adequately support them.

However, this data is, often, difficult, or, even, impossible (for instance, in the case of the Defense and Healthcare industries) to obtain. Many clients baulk at the idea of putting this data at the disposal of their enterprise software contractors.

As a result, enterprise software vendors are compelled to use artificial data sets that do not only fall short of ensuring the expected system performance, but may also leave large parts of the functionality (including those that are already in production) untested. This may happen because sufficiently large and representative volumes of artificial data are usually hard to create.

Remedy

• Try to use as much real-time data, as possible.

• If you are a client, talk to your vendor about the possibility of providing them with scrambled real-time data. If required, request their assistance in preparing this data.

Disclaimer: The present article reflects solely the subjective viewpoint and findings of the SYTOSS QA & Development Teams on the topics, covered herein and does not represent an advice to buy or not to buy, or use or not to use any software product or technology.