- Find a small to medium size system or application managed by a maximum of 2-12 people. It will be easier to work with a smaller team and on a less complex system.
- Have developers working closely with testers to find an API to virtualize
- It should be stateless, transactional APIs are harder to virtualize
- It should be simple, for example, an HTTP SOAP request with not more than 20 tags to a third party, instead of an encoded custom TCP protocol call to a mainframe system
- Should cause significant problems that can be measured and showcased, for example:
- The backend system exposing the API is often not available preventing testing
- It is hard to set up test data in the backend system, the wait time is more than 4 weeks
- The API has not yet been released to the test environments and the wait time is more than 8 weeks
- Third party service test transactions are expensive, limiting the amount of testing done
- Choose a service virtualization tool that allows for a fast ROI
- A tool that can run on existing hardware, to save time requesting new hardware (for example TrafficParrot, Wiremock or Mountebank)
- A tool that can be used by both developers in an automated way for long-term maintainability and testers for exploratory testing (for example TrafficParrot)
- Create a squad team consisting of at least one person from development, testing and environment management and trust them to do the job properly. Ideally, they should sit next to each other to improve the communication channels.
- Relax and trust the team will deliver. Wait for a week.
Keep in mind, this is only one of many examples how you could implement the pilot project. The devil is in the details. You can request a free, no obligations 20-minute over the phone service virtualization consultation where we will go through your most pressing problems.
Do you disagree? Leave a comment!
