STAREAST Recap: The Road to DevOps: Data, Environment, and Test Automation

Last week, SmartBear Software had the privilege of joining hundreds of other software testing professionals at the STAREAST Software Testing Conference in Orlando, Florida.

At the event, we had the chance to connect with a number of speakers who presented on different challenges and opportunities for the software testing world. This week, we wanted to share some of our favorite interviews from STAREAST and give you the chance to learn from these software testing experts.

In our first video interview we caught up with Tanya Kravtsov, Director of QA at Audible. Tanya discussed some of the challenges teams face when implementing a continuous delivery process and shared insight into how you can get the internal buy-in you need to implement new testing processes.

Watch the full interview below.

What was your STAREAST session about?

I did a session which was called: Road to DevOps: Data, Environment, and Test Automation. The session was really about how to help an organization get from whatever process they are at right now to continuous delivery.

What are some of the things I should care about when shifting from a manual process to continuous delivery?

The way I structured the talk was really going step-by-step — assuming you’re starting from scratch or wherever you are. The first thing I recommend is to identify the bottlenecks. Because I think that’s one step that often gets bypassed and people go directly to tools to do automation. But the first step is to figure out what your real problems are. I introduced several techniques for identifying bottlenecks.

Could you give us a few examples of how teams can identify bottlenecks?

One technique I use is playing the speedboat game. This is where you assume your delivery process is a speedboat and you have to identify anchors that are holding you back. So you bring people on at the same time and they start defining those anchors and how deep those anchors go. The anchors that are the deepest and are the ones that the most people select, are the ones that you should focus on first.

Give us an example of the different anchors you have come across that are holding people back.

Some of the biggest anchors are actually in the presentation title. Test environments is one of the biggest bottlenecks. People may have full automation in place and everything is working but because environments are not there, they struggle with running their test.

Another example is test data. Very often, you have everything in place but your test data gathering is a manual process so that can become a huge bottleneck.

And then of course there is the test cycle itself. You might have it automated but the automation is flaky, or your results reporting might not be where it’s supposed to be. For example, you send a huge report to developers and they’re still not able to process the results.

That’s the first part of the talk. Once you identify these bottlenecks, where do you go next?

I went through some of the possible bottlenecks and gave advice of how to approach them. A few of them I just talked about — environment, test data, and automation. I also talked about such things like if your build is automated; make sure you have all your artifacts in a repository like Git. I also talked about results reporting. This is something that is very important that I think that often gets bypassed — automating the gathering and analysis of the results.

So, do all of the examples come from your own experiences? Were you also in a similar boat where you had to improve your continuous delivery process?

I have been multiple times. A few years ago I moved out of being part of abig QA organization in the financial industry into a smaller org. When I came there, there was no QA and had to build it from scratch. This is where this experience came from. I found out what has worked and what didn’t.

You spoke about having no QA. Many times when you go into fresh organization you have to setup from scratch. How did you get the management backing in order to setup a QA team?

I was lucky because the three organizations I came in there was no QA and the reason they brought me in was because they realized that not having QA was one of their biggest pain points. I didn’t have to prove myself and sell it. I had to sell some of the new processes and changes we were implementing. But all the developers felt the pain and knew it was important.

But what about those new processes — what is the approach you use when selling those new processes?

The approach I used is to get the developers on board with you. It’s not that you write up the process and send it out to everyone and say this is what we’re going to start following tomorrow.

What I usually do is assemble a task force of people — developers, managers, operations folks — who have some innovated way of thinking and can influence others. I’m sharing my ideas with them before I actually make them into a process. And get their ideas and implement their feedback and by the time I share it, everyone is already on board.

Learn more from Tanya by following her on Twitter: @DevOpsQA.

We’ll be sharing more interviews from the STAREAST Software Testing Conference all this week. You can stay up-to-date about updates from upcoming shows and all of our latest content by subscribing to the SmartBear Blog.

Close

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox

By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading