I’ll be presenting “Testing Twofer: how to Release Rock-solid RESTful APIs and Ice the Testing Backblob,” on Tuesday, September 9, courtesy of SQUAD – the Software Quality Association of Denver.
REST APIs are a key enabling technology for the cloud. Mobile applications, service-oriented architecture, and the Internet of Things depend on reliable and usable REST APIs. Unlike browser, native, and mobile apps, REST APIs can only be tested with software that drives the APIs. Unlike developer-centric hand-coded unit testing, adequate testing of REST APIs is truly well-suited to advanced automated testing.
As most web service applications are developed following an Agile process, effective testing must also avoid the testing backblob, in which work to maintain hand-coded BDD-style test suites exceeds available time after several sprints.
This talk will present a methodology for developing and testing REST APIs using a model-based automation and explain how this has the beneficial side-effect of shrinking the testing backblob.
The testing backblob is my riff on out-of-control Agile testing backlogs. I’m seeing this situation quite often as Agile development teams become swamped with a test maintenance problem that doesn’t have any attractive solutions.
I’ll explain some new strategies I’ve developed for Spec Explorer to test all aspects of any REST API, including functionality, security, and performance.
To register for the meetup, go to http://www.meetup.com/SQUADCO/
The basic structure of development contracts is all about risk management and creating incentives – for both sides. Fixed fee minimizes certain risks for the customer and maximizes them for the contractor. T&E minimizes certain risks for the contractor and maximizes the customer’s risk. There are many variations between these poles.
Although there are some exceptions, most projects are funded with a finite and limited budget of time and money, with considerable consequences for not meeting expectations. Telling a check signer they’ll know what they get when they get it usually leads to an interesting discussion.
We all know that the sponsors of bespoke software development often don’t know (exactly) what they want and that developers don’t anticipate all of the ways that complex software can get really screwed up. Some kind of iteration is necessary to resolve this. Techniques for managing software development risk are well-known and have been successfully applied (and ignored with predictable results) for over 40 years, including Agile practices.
The essential risks of software development don’t change as a result of using an Agile process (for a primer on Software Risk, I like Higuera and Haimes Software Risk Management.)
So, I think “Agile versus Waterfall” as criteria for terms is a misleading distinction that can’t really provide much help in identifying and managing risks. Choosing a process model and then a risk management/contracting approach is essentially putting the cart before the horse.