Continuous testing is gaining momentum!
AlWagner 120000DGH6 Visits (1969)
I recently had the opportunity to attend the Agile Alliance conference, for the third straight year, which was held in Nashville from August 5th to 9th. And while it is always a fabulous and worthwhile event, this year the conference just seemed to be a little different to me. Perhaps it was just my perception but last year after talking to many attendees about service virtualization and continuous testing, I left several conversations with the feeling that I missed sharing something in my message. While the person may have gained a new understanding of what service virtualization was all about, they didn't seem to be relating it to their challenges or didn't see an immediate need to employ this capability in their organization. I was wondering if I was getting through. After all, what test team is not plagued with some type of testing bottleneck or roadblock impeding their ability to reach their full testing potential and allow them do what they really want to be doing - test software? The bottlenecks or roadblocks I am referring to are that testers are spending too much of their time waiting for test environments to become available or simply don't have the funding and resources to procure and stand up new test environments quickly. But that was yesterday. Let's not dwell in the past.
Now, moving forward to this year. There seemed to be new energy and a higher number of stories being shared at the conference encouraging testers to begin testing continuously and specifically automate the execution of unit and integration tests continuously freeing up tester's time so they could do more value add activities like exploratory testing. Many of today's thought leaders speaking at the event shared their expertise embedded in stories on the importance and need to automate testing as part of continuous integration. What a relief! Others were talking about integration testing and I was now able to tie what they were saying to what I have been saying for the last couple of years. It was a great start but what I thought was missed and my reason for posting this blog entry is that they didn't seem to answer the "How?" to continuously execute integration tests - only the importance of making continuous testing a reality.
A piece of the puzzle was missing as the challenges that I am all too familiar with were still out there. Sure, many organizations may have figured out alternative methods to overcome these challenges such as manually writing mocks to simulate the missing yet dependent software components. But, I then ask why would companies want to pay developers to write mocks when commercial service virtualization solutions exist. Solutions which allow teams to test switching between the virtual component and the source code, when it becomes available, without having to reconfigure their application deployment. Solutions which will help teams stay in sync and aware of changes to the services and software they are dependent on. Solutions which will are easy to maintain and will offer value to the entire team and not just the individual who wrote the mock for their specific needs in the first place.
The name of the game in today's world of accelerating software delivery is not only to do things faster, become leaner, but to also find savings - time and money - while maintaining a high level of software quality. Service virtualization is the technology which can make continuous testing a reality for today's agile development teams and get team members - programmers and testers - working together in sync. I just wish one of the sessions I sat in on at the conference answered the "How is this possible?' question. I tried to do my part this year and gave away over 100 copies of the Service Virtualization for Dummies book. Perhaps at Agile 2014, I need to submit and abstract and hopefully get picked allowing me to share the whole story - the problem, the solution, the ROI.
To learn more about how IBM can help with service virtualization and continuous testing visit ibm.