Date: Sunday 25th January 2015
Time: 3.30pm – 5.30pm GMT
Facilitator: Amy Phillips
Participants: John Beckett, Teri Charles, Dani Bonafe, Simina Rendler, Oana Casapu, skg kamar, Neil Studd, Carol Brands, Daniel Billing, Aleksandar Simic, Philip Hoeben, Christian Kram, Hannah Massey, Jignesh Nayi, Amit Verma, Mark Winteringham, Natts, Yule Lobo, Alan Richardson, Kadri-Annagret Petersen, Kalyan Yelisetty, Roman Baranov, Maja, Christopher Chant, Vladislava Surdolova, Raghu, Adina Moldovan, Srinivas Kadiyala, Kristaps Mežavilks, Maja Schreiner, Ash Winter
Sunday saw a record 28 testers gather for an ‘Introduction to API Testing’.
Neil quickly kicked off the session with a solid definition of what an API is:
“I would describe it as, a mechanism for requesting/receiving data in a structured format”
Experienced API tester, Ash added that he “sometimes think of it as a contract to communicate in a known way between two points”
APIs seems popular as a additional view for testing.
Christopher Chant finds them very useful. Our Test team don’t have access to DBs or logs. Having access to the API allows me to carry out simple checks on what information is available via the API and what our apps are actually displaying
kalyan yelisetty: My view is API testing helps in identifying whether expected end user data is delivered
Alan Richardson: I test an API when it is being used by something and we want information about how the interaction works.
After tackling some further definitions we dived into using an API. The Songkick API kindly gave us a place to practice constructing requests and reading the response.
Neil gave us some guidance on where to focus our testing:
Here, we’re looking at an API response, and seeing whether the webpage (which makes the same API query) displays the same data. I would think in most cases, these would match; though obviously there could be rendering issues.
I would be focusing more of my time (as I am on my current project) checking that the API response itself is correct – e.g. we are seeing 12 Prodigy events, comparing against the raw database to see whether this is the correct number
Ash had a go at defining a test approach for us:
So, you need eyes on the contract/definition/documentation
Tools to explore
Tools to automate
A testing mission no less!
Who is for to solve what problem or realise what benefit
[Access to web logs I would say
An enquiring mind, always
And provided this handy link to a whole load of testing mnemonics for apis – http://www.qualityperspectives.ca/resources_mnemonics.html
We had lots of tools suggestions throughout the session. Hopefully I’ve caught them all in this list. Feel free to add a comment if I’m missing anything:
Convert JSON to CSV
POSTMAN – http://www.getpostman.com/
Advanced REST Client extension for Chrome
Found this quite useful to check the XML output against the website http://codebeautify.org/Xpath-Tester. Then I can use xpath on the xml to check the results e.g. //event/@displayName
For automation purposes, “Requests” is a great python library
https://msdn.microsoft.com/en-us/library/azure/dd179357.aspx this page is specific to a REST API…but it should be a good start point
w3schools website for XML, XSLT etc
You can find plenty of APIs at http://www.programmableweb.com/
Many of the apps on bitnami.com VMs have APIs for local testing
Kin Lane. He writes a lot about APIs.
Troy Hunt video “Discovering Mobile App Traffic” (shows how to configure Fiddler to proxy app traffic)
More on REST- http://www.restapitutorial.com/lessons/whatisrest.html
You can read the full session transcript here.
There was a request made during the session for us to host ‘Security testing for APIs’, and a ‘Performance testing for APIs’ sessions. Watch this space!