Michelle & Automated Testing 5: Internal API and External API Automation Testing, Lessons Learned
External vs. internal APIs, what are the differences?
“APIs are the foundation that the new digital economy is built on. External APIs allow secure connection and content sharing outside an enterprise, creating engaging customer experiences. Internal APIs create a secure platform for sharing data between teams and breaking down traditional data silos.” (apigee)
What are the most valuable lessons I have learned from my career:
- Internal APIs (whatever the name) can be used by in-house developers, but cannot be accessed by the external developers or users outside your company. So the focus of automation test is to test the backend logic. We call it API story tests.
- External APIs can be used by any developers or users. In other words, they are public APIs. When we test these APIs, the returned messages are friendly or not become important. This does not mean logic test is not important. It is still very important.
- Automation test strategy and test focus (the test case priority) should always be different based on project objectives, company requirements or a team’s particular needs. Our automation developers should work with developers, dev ops, QA and any other team members to understand their needs and requirements in each development stage. We need to be very thoughtful as a team.
- My previous work experience was focus more on testing external APIs. In that case, input validation test are very important. When I moved to internal APIs testing, my mindset did not change right away until we noticed some tests were flaky and were not very important to us. It took much time and effort for us to investigate and fix the problems. After we investigated our use case and also re-thought the tests based on the team’s needs and our resource limitations, we concluded that we need to have a main focus; for example, some edge cases can be ignored. We also found that in different projects, the edge case definition should be defined differently. People always think that tests should be automated as much as possible, but, don’t forget you have time constraint, budget limitation, team technical background variation, and also the cost for maintenance. To achieve the greatest value, you should always plan a most effective and productive way at the beginning of your automation project. Automation projects are on-going and will never end unless the application under testing is significantly changed or the development project is terminated.
Quality Assurance Analyst at PrintFleet
Michelle Xie is a Quality Assurance Analyst at PrintFleet in Kingston, Canada. Michelle is a passionate software engineer and a software QA expert. Most of her efforts focus on automation test best practices and common tech issues that can be avoided in automation tests, and she hopes to continue sharing her technical expertise through ECM TechNews.
Latest posts by Michelle Xie (see all)
- Michelle & Automated Testing 5:Internal API and External API Automation Testing, Lessons Learned - August 15, 2017
- Michelle & Automated Testing 4: How to Integrate Jenkins, Sonar and Github for your Pull Request? - July 27, 2017
- Michelle & Automated Testing 3: Using Maven AWS S3 Repository Instead of Nexus Server - June 28, 2017
You may also like
(Views: 676)