In this interview, Jonathan Cooper, a principal quality engineer for the ExactTarget Marketing Cloud, sits down to talk about various aspects of API testing, the difference between SMS and push notification, and why he is a proponent of the context-driven methodology of software testing.
Cameron Philipp-Edmonds: Tell us a little about yourself.
Jonathan Cooper: I’m Jon Cooper, principal quality engineer for the ExactTarget Marketing Cloud. I have worked in software testing for nearly ten years, starting out at a small software company in Indianapolis, testing telecom billing software. There, I manually tested the telecom billing software using session-based exploratory testing techniques. For the next six years, I worked with a consulting company that had clients in both Indianapolis and Cincinnati. From there, I joined the ExactTarget Marketing Cloud team and recently celebrated my two-year anniversary.
Cameron: Can you tell us about your role at ExactTarget Marketing Cloud?
Jon: As part of the platform team, my primary focus is testing our core platform APIs and our mobile products. Most of my testing revolves around REST APIs. Additionally, I train team members on why and how to test APIs. For our mobile products, I work with SMS and push message emulators that simulate messages moving back and forth from SMS and push aggregators.
Cameron: In your words, what is API testing?
Jon: API stands for application programming interface, and defines how software components interact with each other. In other words, an API is a way for a developer to expose functionality for use internally or externally. Just as traditional testers test how an operator would use the front end of their product, an API tester can test how internal and external users use the APIs. The concepts are very similar to non-API testing; the only difference is that in most cases you are manipulating the API outside of a user interface (UI) using different tools.
Cameron: Do you think API testing is more a white box testing task or a black box testing task?
Jon: The vast majority of the testing I do can be done without having any expressed knowledge of what the code behind the API is doing. The same things that a tester would do in the UI, you can do with the parameters of an API. Now, it can be very useful to have knowledge of the code and data structures behind the scenes because it opens up lots of different testing ideas and allows you to shift your focus to areas where you can see that there might be vulnerabilities that could be exposed with certain testing techniques. But at most, my testing could be considered “Gray Box”, almost never White Box.
Cameron: You specialize in API testing with an emphasis on both SOAP and REST. In layman's terms, can you tell us the difference between the two and why someone would choose one over the other?
Jon: Simple object access protocol (SOAP) and representational state transfer (REST) are two formats for implementing web services. Soap APIs have customer actions defined by developers, where REST APIs use only HTTP actions and define the state of an object using payload.
Typically users of REST routes are those who depend on their services being very quick to run and quick to build, including a significant amount of web apps. Newer companies seem to prefer REST due to its ease of implementation, and versatility.
Cameron: You also do mobile testing. Can you tell us what kind of testing for mobile you work on?
Jon: I assist with the testing of our two mobile products, MobileConnect, our SMS product, and MobilePush, our push product. MobileConnect allows our customers to interact with their mobile subscribers via customized SMS campaigns. For instance, at the movies when you see a sign in the lobby that says “Text POPCORN to 123456 to get concessions discounts,” MobileConnect is a tool that would allow brands to set up and monitor that marketing campaign.
The testing I do is around our mobile APIs and also around the mobile product itself, including the sending and receiving of SMS messages. We also test to ensure these interactions work across all of the aggregators we partner with both here in the US and internationally. Finally, we test to ensure message sizes and encoding work internationally.
Our push product enables brands to interact with their mobile subscribers via mobile apps on their phones and tablets. MobilePush enables a brand to “push” a message to a subscriber’s phone from an installed app. For example, if on your phone you get a notification saying that you have a bill ready to be paid from your banking app, it may have been triggered using one of our APIs. We also handle geo-targeted notifications. For example, if you are walking past a restaurant, and happen to have a dining coupons app, our APIs might trigger a message from that app giving you a coupon code for 10% off an appetizer.
Cameron: What is the difference between SMS and push notifications, and how does testing of those mobile traits differ?
Jon: Both SMS and mobile app messaging are critical communications for almost any organization— mobile stats and consumer behavior shows it. SMS is a text message and push notifications are messages delivered in-app or sent to the home scree of customer’s mobile devices. Each requires unique testing with variables on country, mobile app, size and encoding.
Cameron: You describe yourself as an adherent of the context-driven methodology of software testing. What about the method do you find so appealing?
Jon: As a consultant for several years, I’ve worked with interesting products in unique places. There was not a single instance where I would use the same testing procedure verbatim. The whole idea behind the context-driven methodology is that there is no single testing best practice that fits all situations, and that is up to the entire team to determine what the best way to test. This is what I have found to be true during my testing career.
It really is all about people taking a purposeful look at what they are trying to build and working together to define the “best practices” in their own unique context. However, that does not mean that for every testing project everything must be built from scratch. Tools, ideas, and processes can and should be reused where prudent.
Cameron: You've been a testing professional for roughly a decade, and testing seems to have changed a lot in the last ten years. How do you think the world of testing, especially relating to mobile, will change in the next ten years?
Jon: In the last ten years, I have seen a considerable shift to more and more automation, simply because the products we test and environments we operate in have become so complex that manual regression testing is impractical. In the next ten years we are likely going to continue to see more movement toward automation, especially in the mobile space. This does not however mean that there will be fewer testers.
In the last few years, I have seen more companies discover that automated tools are only a part (a SMALL part) of good software testing, and that on site testing teams actually save money and provide better ROI.
All in all, I believe we will see the number of testers grow to support the ever-increasing amounts of software that we interact with every day. Average testers ten years from now will be more knowledgeable about the technologies that drive the products they work with, and they will be working much more closely with development teams to build better and more stable products quickly.
Cameron: Knowing what you know now, what advice would you give to yourself when you were just starting out?
Jon: I would get more involved with the development and test communities locally and online. There are lots of great people and organizations out there to interact with professionally that can assist with professional growth and provide an environment for mentorship. Early on in my testing career I got to know some of the people in the AST, and the advice and techniques I learned from them are invaluable to my work even today. The software testing community is a friendly, professional, and resourceful community, so get involved!
Jon Cooper is a software tester working in Indianapolis. Jon is currently a principle quality engineer with the platform and platform applications team at ExactTarget. Jon has been working in the software testing arena for nearly a decade and has worked as both an employee and consultant for several companies in the Cincinnati and Indianapolis markets. Jon is a proponent of the context driven school of software testing, and believes strongly that there is no single “best practice” in software testing, but rather that the particular needs of a project its stakeholders should be used to define the testing procedures.
