Test Management

Case Study:

I have a question regarding Test Management. I have this situation in my company: some part (hundreds) of applications that were developed by us will be transferred to another company. That means migrating to new environments, but with the same configuration and connections. Many of this application is connected together. And now the task is to prepare Test Strategy for End to End testing. In this case the hardest part is to find the ends, because of all the integration is more like a Gordian knot. The first idea is to find an application that is not dependant on any other and start there. Do you have any other ides (anything will be welcomed) on how to approach Test Strategy in such a situation?

We are in the process of migration, so application so in a sense still our responsibility and we have to make sure, that they will be working after migration - that is a part of the agreement. Good tip with the contracts, I will investigate that.

-- Anonymous

Recommendation 1:

So, a few questions for you? Why are you doing end to end testing that includes applications that you no longer own? If you find an issue, can you do anything about it? Whose responsibility is it? You might want to reconsider your scope. One thing that I find very helpful when having multiple components of applications tied together is to start with component and contract testing. Does each part of the application (or application) work properly by itself, and is it producing data as specified, and using input data as specified. With this approach, it makes it easy to isolate issues within areas, and understand what belongs where. It also means you never really have to find the ends, as you can just keep expanding your testing to include more and more components (or applications) and continuing to check those endpoints to ensure they align with the set contracts. For this to be effective, you must have contracts setup, and you must have some tests for them.

-- Max Saperstone

Case Study cont...

There are some issues with integration (not all data is being processed), I think the most knowledge I m missing is all the connections (hard to find, documentation not always up to date) and configurations.

Recommendation 2:

So, in my experience, "this lack of documentation" and things around it, will become a pain point. It means someone will most likely change an endpoint, and not realize the impacts. To me, this speaks for the need of drawing up contracts, and focusing on contract testing.

-- Max Saperstone