I work in the IT department for a big company. There are many development teams all working on their own applications and projects. Sometimes those applications need to integrate with each other.
However we have nothing set up to organize integration testing between different teams. First hurdle to cross is off course making a point of contact known for each time, so you can start the discussion. But what to do after that? who takes the lead, who tests, ā¦
How do you do/organize integration tests? Are there any best practices?
Communication.
Personally, cover your own ground fully first, then look at the risks for integration failures, because as we all know, interfaces are where by far, the largest congregations of defects are just waiting to be found. But when they are found, who cares? and that is probably the crux of it. Whoever triages any you do find is probably the person to talk to about a strategy that can kick off that coverage project. But finding someone who will help maintain integrations as a standalone system level piece of work is in my opinion, they way to go, even if it is just a 50% resource, but a dedicated go-to person who tests or drives the system quality across products, is a resource hurdle that really needs some level of independently budgeted resource.
Hi Demi,
Thatās a great question, and not an easy one to solve. As Conrad mentioned knowing your own products and current integrations is a good place to start.
As you work in the IT department you are in a great position to do something I have always found helps too and that is identify the core systems that everything will integrate with.
This could be an email system for communications, Active Directory for access and user information (on site or in the cloud), some kind of finance system if things like portfolio codes, or department budget codes are required to pull in and anything else that is a central system used to manage the organisationās data.
You should also speak to your local architects if you have some? They can often tell you what the common integration points are.
From there you could start to reach out to other testing teams and understand what they integrate with.
As you build up a picture, you are also building a community, who can support each other.
Iāve had lots of occasions in previous roles where, through a previous project I have become familiar with the challenges of integrating with a specific system (e.g. email) and have been able to provide that knowledge to new projects to avoid the same pitfalls.
Becoming someone other testers go to as a āfont of all knowledgeā is a great way to build your knowledge, skills and profile.
Good luck and I hope the above has given you some ideas.
Jane
I agree that the main thing will be communication, so good that youāre already trying to find the right people to involve.
Some things which might also help include:
- Dependency map showing data flows
- Automated system integration tests that follow the data / user journey through the different systems
- Contract tests for any APIs
In terms of who takes the lead, I donāt see any reason why you couldnāt do it. That doesnāt mean you need to have the most experience or technical knowledge, just that you help drive things and keep people on track. As to who tests, I would say someone (or more than one) from every relevant team. Both to make sure things are good on their own end, and to work together to test out the integration. Itās something Iām currently co-ordinating, being the QE on a team providing data to multiple consumers.
This is something I was actually tasked with to help solve last year. Hereās a frame of reference. Also this is only strictly talking about integration testing and not the full suite.
The product I support has over 30 separate microservices that create it, and it connects out to 3rd parties and another product in-house. So a lot of integrations that have to be made.
Weāve broken it up into 3 distinct phases.
Development of Features (Local) - I need devs to build and test with confidence but not rely on availability of the external services. So we built a hermetic integration test suite so can easily create mocks based off of real data to ensure integrity and fidelity (or as close as we can get) But this has a gap of, āwhat if the contract changes between servicesā That moves onto the next.
Contract Testing (During deployment) - This validates that if one service makes a change to the integration point. It will either A) stop the deployment and alert that build of what is breaking. B) Alert teams to know that something has changed and conversations should be had as risk to breaking services has increased. Okay but we still havenāt actually tested the real thing yetā¦
Non-UI End-To-End Tests (post deployment) ā We have a series of tiny automated API tests that hit all the endpoints to ensure that everything is working for the end-user. This will either be specific endPoint tests or tests that follow Critical User Journeys. if you have performance tests, you can scale those down to 1 or 2 users and BAM you have your API E2E solved for.
As for who takes the lead. That will come in time, but I think the important part is starting that conversation, and bringing awareness and understand the problem it can solve.
Communication.
Could not agree more. How your team communicate is the foundation and everything else kinda follows from that.
I agree, in my organization, we have different projects that we call platforms, and many features are common among all the platforms, so common code is implemented there, from time to time, users of different platforms ask for a change in their platforms, which can impact other platform functionality. So, to ensure that new functionality does not impact other platforms on which those changes were not intended, we maintain communication at different levels. PM of all platforms have their group in our official application on which they keep discussing the ticket scope and impact area. Then, there is another group of Engineering managers who also discuss the tickets at their level.
Then there is a common group of PMs, EM & qa managers, along with the design team lead. So they discuss their ideas, and strategies and ensure that everyone is in sync. The qa manager finally share the outcome of such features/tickets with the testing team so that the team could set up their strategies accordingly.
Even though such conversations at different levels may consume time, it ensures implementation of one feature on one platform donot break the existing functionality on other platforms. With such process there is transparency in development, testing and requirement details.
Generally, i coped this situation with three aspects across the teams.
First, who is in charge of this role to organize all related teams. In my opinion, the Project Manager/Program Manager should takes this role to plan a proper schedule for all related teams with their timelines and efforts. The PM must identify the key dependencies cross components, get the est. finished date of development tasks, and even leave some buffer time for unexpected incidents.
Second, a dedicated environment for integration test should be set up and maintained by certain guys. All of the lasted applications/components should be published in this environment as due date then the scheduled test could be executed on it with prepared test cases and data.
Third, certain communication channel should be established in projects. Those key persons in different teams must be involved in the channel to understand the progress, status, issues, risks during the integration test. PM can arise some meetings to keep everyone on the same page.
Hi Demi
To add onto what has already been said.
Do you have some kind of chapter lead in your company? That person could facilitate what needs to happen.
Do you only need them or do they also need you?
Maybe they already have some automated tests on API that you could re-use.
Normally I just start the communication and I just talk to the team and Iāll take the lead myself in order to set something up. Else you might have to wait longer if you are dependent on someone else āwhat you do yourself, you do betterā
Good question! It depends on what we are talking about for ātestā
Do you just need their API to create data in your app?
Or do you create something that arrives in their app and you want to validate that?
If data is made for you and you have to test, well that says it, you test
If you want to create something and validate that it arrives in another teams part. You can ask for a GET API to validate it arrived.
Thatās how I would do it.
Of course communication is key, but if YOU need it, YOU should take the lead, else it might never come or be there. Especially in Belgium