Wintertainment 2020 - Day 2: Building a Reliable Collaboration Approach for API Tests


Hi everyone! Today is Day 2 of glorious Wintertainment 2020 where we are sharing information about testing trends and pro tips on using SmartBear products with you! Today, we are going to be talking about building a reliable collaboration approach for API tests. Check out this great article written by an API testing pro from SmartBear - @TSanchez_1!


Answer the questions provided at the end of the article and share your thought on the topic to get a chance to win a special prize from our team! See event details and article schedule here. 


Building Reliable Collaboration Approach for API Tests 


Creating reliable tests you can reuse and share across teams is an ideal state for those companies trying to accelerate their development process. With a collaborative approach, companies can become more efficient within or across teams. In ReadyAPI we follow a VCS (Version Control System) approach to test collaboration.  


I believe treating tests as you would treat code is important, and there is no better way to do so than to follow the most common type of practice in the industry, using GIT. With ReadyAPI’s native Git provider integration we make collaborating with GIT providers a breeze. Let's walk through the process. 


The first thing you need to understand is that ReadyAPI default projects are XML flat files. Meaning that it is one file for all the work you do in ReadyAPI. To make these files flexible for collaboration we need to turn them into Composite Projects.  


Nneed to worryas ReadyAPI does this automatically for you. First, make sure your project is highlighted in the navigator and click on the Git Icon on the top, right-hand side of the screen. You can either click on Connect to GIT or create a local repo. For the sake of this blog, I will choose a remote repository and will use GitHub, but it is the same process for all Git providers. 




On the following screen you will be able to connect your Git provider account to ReadyAPI, or choose from an existing one. 


The next step is important, please make sure the repository is already created on your GIT provider so your project has a home. You can choose it or search the list. 


Once you have chosen a repository for your project, a Git panel will appear on the right-hand side of ReadyAPI. It has all the GIT action necessary to make sure your projects stay coordinated with the repository, and any work that needs to be pushed or pulled from it 



Now that we have set up a remote repository to share API tests within or across teams, let us go through a simple exercise. 

1. Create new test iReadyAPI Test. 

2. Save the project (saves locally first) by clicking on the Save button. 

3. As a best practice, confirm all the changes that were made under Uncommitted changes. 

4. Once you are ready to commit your changes, press the Commit button and make sure there is a meaningful Commit message for traceability. 

5. Finally push your changes to the repo by clicking the Push button. 





Lastly, as with any VCS process, there are changes that may happen by multiple teams at once. Iyour branch is behind, you will see by how many commits under the branch dropdown. If you decide to pull changes, and there are conflicts, you will get a message advising so. A Merge Conflict Dialog will help you make the right decisions. Please refer to the screenshots below for more. 

image (17).png




On the Merge Conflict Dialog,you can clearly see what the conflicts are, and you can decide to choose from “Yours” (local project) or “Theirs” (remote project). In this case, the changes happened on the payload, hence the yellow triangle symbol showing the difference. You can see the details in the Property details section at the bottom. 


As shown above, ReadyAPI makes it easy for teams to create meaningful and reusable tests across an organization or single team. By following similar practices to code, you can create object-oriented tests in ReadyAPI as your API test authoring tool, and make the collaboration process efficient at the same time. Now that you know about this functionality, go take it for a spin! 


Further Reading 


Release of Git provider integration: 


What do you think? Comment below! 


1. Do you constantly find yourself writing the same tests over and over? 

2. Are your teams working together when creating tests, and is the process as efficient as it could be? 

3. Are you looking to be more effective in test authoring across teams? 

Community Manager

Hi there,


Thanks for puting focus on using VCS for tests, it's not used enough in my opinion.


As most of my team mates don't use ReadyAPI but SoapUI, I try to use GIT versioning anyway.

It's a bit tricky to visualize your unique XML project file in a tool like Notepad++, but once you know the structure you can take advantage of the GIT plugin: 

(Hope anyone is using the GIT Gui, just looks awfull)


Could be harder to explain why doing such a thing than using it 😉.
But keep calm and carry on, you're on the right way.





Community Hero

I'm in the same spot as David.  Everyone is using SoapUI and if we do share tests, we just pass them around.  We have a lot of API development going on, but they are mostly internal ones that will be put in place and then maybe never looked at again.  That doesn't give me much leverage for asking to get ReadyAPI, although it would be a much cleaner solution that what we have now.

Regular Visitor

I definitely agree that we've to treat tests as we would treat the code, in my company we use bitbucket to collaboratively create and review API Tests. We also use BDD & TDD approach for writing and maintaining contract tests to map with User Stories. It is crucial to ensure business requirements are validated as per end user expectations hence quality code delivered into production.


Next, we're planning to add load testing to our test strategy and hence i'm interested in exploring ReadyAPI features. This article has been very helpful. Thanks!

Community Expert

I feel like I am in the minority here.


On our team I am the only "API tester", so it is just me up against the world. 🙂

Our dev team is not interested in learning another tool (they currently use Postman), especially a Java-based tools since we are a PHP house.

I still store all my tests in git, at the very least as a backup.


However, ReadyAPI has bugs with the composite project (got an email just today, that your dev team confirmed one), so I cannot rely on graphical tools to tell me what has changed and what has not. In my past I learned git from command line pretty well, and that still serves me just fine today. Also, with other bugs in ReadyAPI (also confirmed by your dev team) I just do not have confidence in any new features in the tool.

The features provided by (the free) SoapUI seem to be reliable. I try to stick to those when I can, even though I have a full license.



About three years ago, we had tests executing the same requests on different environments but were not evaluating the same response information on those differing environments. At that time we would save the project to a network share and people would grab the latest one (we versioned to the network share based on a "date"... not a sustainable process). With the implementation of GIT and Ready API, we decided enough was enough, we had to get smarter and take the best from those similar tests and roll those into new tests and get them checked into the repo.
The latest GIT enhancements have been well received and have helped us find potential merge conflicts sooner than later. Additionally, the changes we make are usually associated to JIRA tickets, so including the ticket number in the "commit" process helps us be able to see the associated code change and when or if the change has been made in the associated Ready API project.
Another example is when someone has been out for a few days (sick, vacation, etc.) and had test code they were working on but had not committed, being able to see what the differences are using the new feature is extremely useful.

This article shows how useful this new feature is and also why you should treat your test / validation code just like application code.

Frequent Contributor

Is there any existing or planned support for Perforce also?

Senior Member

1. Do you constantly find yourself writing the same tests over and over?
Ans: Yes many it was happening many times with me and my team that we were writing same tests for different scenarios.
To overcome this situation we are trying to re use of our tests. From this we came up with our own custom framework which is combination of page object model and data driven process.
With help of framework we are able to reuse the code in much better way for testing.


2. Are your teams working together when creating tests, and is the process as efficient as it could be?
Ans: We (My teams) are seating at different geos. So, rarely we are getting chance to work together. Due this we generally get chance to review tests written by each other.
But in couple of cases it is very hard to understand anyone's logic and to get explanation for it we need to wait for log hours or day also.
So looking at all the scenarios and situation I feel this process is not as efficient as it could be.


3. Are you looking to be more effective in test authoring across teams?
Ans: Yes, I am looking for more effective process to test authoring across the teams.

Community Hero

1. Do you constantly find yourself writing the same tests over and over?

Sometime it happens, as in order to cover all the scenarios for different functionalities with different set of data.


2. Are your teams working together when creating tests, and is the process as efficient as it could be?

Yes the team in which i am working is working together while automating test cases. but the process needs to be more efficient.


3. Are you looking to be more effective in test authoring across teams?

Definitely yes we are looking for ways by which we can make our automation more effective across the teams. 


Community Manager

Hi @rajs2020 ! ReadyAPI doesn't have specific support for Perforce, we only have documented support for Git repositories located in repository-hosting systems like GitHub, GitLab or Bitbucket, as well as Git repositories that reside on servers in your local network.
I would encourage you to create a Feature Request to make this use case more visible for the ReadyAPI Product Team! Thank you🙂

Occasional Contributor

I think because the cost to change API code is relatively low (compared to doing changes to all the layers involved in a full web application), it's important that everyone on the API team helps to maintain the two-way communication between the developers and the QA testers. It's so easy to make a minor change that breaks testing downstream.


1. Do you constantly find yourself writing the same tests over and over? 

A:At the beginning of our automation test , we are always writing the same tests.

Then we found it isn't efficient. So, we modified the codes as one and one module.


2. Are your teams working together when creating tests, and is the process as efficient as it could be? 

A: No, we haven't a fixed framework to create tests. Maybe change another project, we need to change a new way to write codes again. We are still trying which way to write codes is more efficient. By the way, I am a TC user. Do you have a recommend framework by TC.


3. Are you looking to be more effective in test authoring across teams? 

A: YES, I am looking for it.

Community Manager

Hey! Today's the last day of the event, you can check out all the articles we posted under this label - Wintertainment20

See if you missed something interesting🙂


Users online (589)
New Here?
Join us and watch the welcome video: