Today’s testers have to be good at dealing with software that’s based on a different kind of source code, a codebase that includes many modular add-ons called Application Programming Interfaces or APIs. An API makes a software product “usable” by others. For example, if you have a piece of business software that uses some sort of file-sharing widget, it will incorporate that widget’s API, basically “plugging in” that smaller product’s source code and making it a part of the whole sophisticated architecture that customers pay for.
The emergence of APIs has led to, in part, a “mixing bowl” approach to application development (see this interesting take on the fragmented world of APIs and brands at Forbes), where one software application can use code from dozens of other projects with these simple connectors to bridge the gaps. In order for this to work, APIs have to be used in the right ways. Developers have to effectively blend them in and testers have to do their homework to ensure a great finished product.
Know Your API Types: Working with Social Media, Service, and Third Party
Why are there so many APIs in a given software project? Here are some of the categories of APIs that testers may have to incorporate into the workflow.
Social Media APIs — Developers could make the assumption that they will be “plugging in” Facebook, Twitter, or other social media APIs to a project. This kind of addition can seem simple based on the interface — often, the hookup will include an automatically populating icon and other convenient code features. These integrations, however, still have to be tested because even if the smallest detail is out of place, the application can have major problems. If you are trying to enable your salespeople to upload posts automatically to Facebook and Twitter and have customers interact with them, a systemic glitch could give bad information or alienate potential clients. Some problems can be as basic as a bad file path or another issue where the API isn’t even accessible because it’s not in the place where it was supposed to be, such as this problem described on StackOverflow. When this is the case, it is nearly impossible to notice without proper testing. It seems like a simple problem, but it can elude an easy fix.
Service APIs — Another big category of APIs is for established services that are now very popular across the web (think Dropbox). These products also have their own stock APIs that are supposed to be easy to “plug into” a project, but may require additional functional and performance testing down the road. Service APIs are more of a “wild card” and a little less predictable. Using them regularly and effectively requires getting more knowledgeable about the company that makes the service and looking at the “owner’s manual” that it provides for a given service. For example, if your file sharing service doesn’t launch or won’t sync, you might have a permissions problem that hasn’t been worked out. And somewhere along the way, that has to be fixed.
Third Party APIs — These APIs may be a little more difficult. Sometimes, a smaller independent project has its own API for use in a particular architecture. This category would include open source APIs, whether or not the third party application or product has its own army of developers at its disposal. For example, Docker, which offers cloud-based application development platform for building distributed apps, sharing repositories, and automating workflows, also offers a RESTful Remote API using JSON. This seems to be great for businesses, and it can be, but in order to use it correctly you have to understand exactly how it will integrate with your system. Using a third party API is more like changing your own oil vs. pumping gas. Anyone can do the latter; you have to know something about the car and the oil to do the former. Same with APIs. Any professional knows it’s not as easy as just “plugging in” to a virtualization system.
Without a working knowledge of these types of APIs and some command of testing techniques, there’s a chance that testers won’t be able to deliver a thorough service.
Evaluate Your APIs: How Good API Design Provides a Head Start
In general, APIs have been designed to work in standard ways, but that’s not enough when it comes to testing. That’s why QA testers have to also get good at understanding the API approach.
Sure, you can say that an API uses REST design or that it’s “kinda RESTful,” which can reassure a developer, a client, or anyone else. It’s true that conventions like REST make it less likely that a clunky API or integration will topple the Jenga tower (although, for a variety of REST issues, you don’t need to look further than this post from IETF chair Mark Nottingham). Still, even the best APIs need testing because their use is dynamic and rests on the overall accuracy of the larger codebase.
The bottom line is that no matter how they are designed, APIs have to “fit” into the code, which is why testing has to be directed at these elements of a product.
Don’t Just Look at the Big Picture — Take Small Steps, Too
Testers don’t want to get mired down in the details, so it is imperative for them to have a bird’s eye view of a project and work toward the end goals. At the same time, good testing and design has to proceed based on careful, deliberate, incremental progress. Otherwise, there’s a good chance that something important will fall through the cracks, or worse, the whole project can unravel. APIs are an excellent example of this. You can’t just say that “the API is in there” — layers of testing will show just how well one of these systems works and what it’s going to look like after release.
At LogiGear, we make the distinction between API testing and unit testing, using specific black-box processes to target the API rather than the interface in general. Our testers send calls to an API, skipping the peripheral (mouse or keyboard) input, to get a first-hand view of system responses. Using techniques like boundary analysis, forced error testing, and equivalence classes, along with our “smart API testing” tools like JUnit, we evaluate real performance thoroughly.
Whether it’s a mobile platform or a project designed for desktop or workstation environments, good testing means working on those interactions between many different modules within the software application. LogiGear can get your projects up and running while ensuring that they work well during and after release. Because we have the right people and processes in place for API testing, the results will take into account the complex interaction between all of the ‘moving parts’ of your software. Contact us today to learn more.
