Flaky Tests at Google

Jeff Listfield has published an interesting read on where does tests’ flakiness at Google come from.

The main takeaway from that article is that the larger the binary size and more RAM the test consumed, the more likely it was to be flaky.

So, try to avoid creating large tests, and you should have less flaky tests!

It is worth noting that one way of addressing the flakiness of certain types of tests is using stubbing, mocking or service virtualization. When used properly, it can help stabilize the environment. It has to be assessed on a case-by-case basis if that is the right thing to do. For example, system tests will often be run in isolation, but end to end or smoke tests will require the whole stack to be deployed.

4 tips on "selling" service virtualization inside a large enteprise

What are the next steps if we have done a "POC" and people still don’t want to use service virtualization?

A service virtualization consultant recently asked me the following question.

"We have finished a proof of concept project and demonstrated that service virtualization would work in our company. We have presented our findings to several teams, but none were interested enough to start implementing it in their sprints. What do we do now?" Service Virtualization Specialist at a Fortune 300 company.

Selling service virtualization

There are a few ways this problem can be approached depending on the details and specifics of the organization.

There are four key points to make that should apply to your situation.

1. Selling

You are no longer only a service virtualization specialist once the proof of concept project has finished. Often, you need to become a salesman as well. You need to apply proper sales and marketing practices to win over individuals and teams inside your organization to help them solve their pressing problems.

2. Solving real problems

Good sales people solve people's problems; they do not push solutions. They make people understand what they offer is a good idea for a given situation if there is a big enough problem to solve, or walk away.

When you sell, remember you have to deliver value to the teams by solving their real problems of high priority. You have to build rapport and understand why do they think they do not need SV and what problems do they have that you could help them with. You need to “get a Ph.D.” in their internal and external issues. You also have to understand political issues inside the team that might prevent them from implementing service virtualization. Once you understand the whole environment inside out, you can suggest solutions.

3. Technology adoption lifecycle

Remember that in every large enough organization you will find people that will be very keen to try the new approach and individuals that will resist using it until everybody else is onboard. It’s called the Technology adoption lifecycle. Look for innovators and early majority.

4. Influencers

Some organizations have natural leaders, tech leads, architects or other individuals that developers and testers look up to. You could approach those influencers and work with them to spread service virtualization knowledge.

What are your experiences with “selling” service virtualization in your organization?