{{announcement.body}}
{{announcement.title}}

Make Like Megatron: Overcome Obstacles to Change on the Road to Testing Transformation

DZone 's Guide to

Make Like Megatron: Overcome Obstacles to Change on the Road to Testing Transformation

A question and answer article highlighting ways to overcome obstacles and transform for the better.

· DevOps Zone ·
Free Resource

Megatron: He’s arguably the best transformer with the best back-story. So what does he have to do with testing transformation? He’s a champion in gladiatorial combat; one who started as a lowly worker and has risen the ranks to affect positive change. We’re not asking you to go full-on gladiator, but like Megatron, you can rise through the ranks in your organization to champion change and spark an organization-wide agile, DevOps or digital transformation. Below, we’ve shared a handful of resources and a Q&A about igniting change with a successful quality champion.

Initiating Testing Transformation: How to Get the Ball Rolling

Once you have an idea for how to improve, how do you bring that change to your organization? Whether it’s getting your peers on board or securing approval from executives, two of the most important keys to success are building a groundswell and making the case in a way that highlights what your target audience cares about most.

Q: I want to initiate a change to the way we do QA, but executives say there’s no budget for testing and we don’t have time to slow down and learn new processes. What’s your advice?

A: Most importantly, you need to build a groundswell of support so leaders see there is a large need or want for a change. To build this groundswell, you might host lunch and learns focused on specific techniques or take a lean coffee approach in which a group gets together to talk about testing. These efforts will help gauge interest within the organization and build momentum for the change.

It also pays to start with a pilot. Tell your executive team that you understand you can’t make a sweeping change, but there’s a small group who’s interested and wants to enact the change for a sprint or two. Running that pilot will allow you to pull hard data (e.g. making this change reduced defects by X%) that you can take to support the case for rolling out the changes to the rest of the organization.

Q: Any ideas coming from QA have been ignored by executives. What is the best way to communicate with this group?

A: Executives typically speak in dollars and effort. They want to know the risk versus the benefit and the cost versus the impact versus the benefit. If you frame the argument in that way, it will make a big difference. For example, instead of simply saying “I have a good idea for how to improve testing,” try “I have a good idea for how to improve testing, and here’s how much it will cost, how much it will save us and how much happier it will make our customers by reducing defects.” Typically once you share those numbers with the executive team, it opens up the conversation since you are now “speaking their language.”

Q: Do you have any tips for implementing cultural change, like a culture of quality?

A: Implementing a culture of quality all comes down to communication and business partnership.

Most times when we see a culture of quality successfully implemented, the business and the product teams are completely on board. When this type of change is not successful, we typically see the business and product teams giving testers so much work that they can’t focus on quality, only on delivery. Usually, that’s because the business and product teams don’t yet understand that while devoting more time to quality might reduce product development, it will enhance the overall product and increase customer satisfaction — which is something everyone wants.

Getting developers on board is the next biggest challenge, and doing so requires focusing on their pain points and highlighting the “what’s in it for me” (WIIFM). With developers, the WIIFM is fewer weekends and late nights. One of the ways to express this WIIFM is to measure cycle time, which covers how long it takes to move an item from one point to another inside of a sprint. Essentially, it measures the handoff and time bounces back and forth between QA and development based on defects found. You can then share how much you can reduce that time by finding defects upfront, which in turn will make developers’ quality of life better.

Q: Is there any difference in approach to QA best practices in industries like healthcare that usually run behind when it comes to tech?

A: One of the big things to realize is that change happens slower at big companies, especially those dealing with sensitive data.

Understanding that change will take time in any organization, try building a master plan for all the various QA techniques you want to implement for the year. Then stagger the rollout times so that you don’t have to wait for one to be fully complete before you begin the next one. When you stagger rollouts, you can get new techniques out to everyone on a regular basis and avoid an overwhelming amount of change happening all at once.

Getting Past Roadblocks: How to Deal With Resistance to Change

Change is never easy. Whether it’s people who resist change or rollouts that don’t go as well as planned, there’s a lot that can derail even the best ideas. To get past these roadblocks, you need to keep the lines of communication open and learn from failures.

Q: How do you deal with resistors?

A: First and foremost, you need to understand why they’re resisting. Most often, people resist because they’ve always done something one way and don’t want to change. In these cases, data from a pilot that proves the positive impact of making a change becomes critical because it requires those resistors to weigh their emotions against real data — and data usually wins. Beyond that, having a conversation, particularly one that takes place outside of the office, can help break down concerns and make people feel more comfortable with the change.

Q: How do you recover if your change hasn’t been successful so far and people are starting to think negatively about it?

A: The important thing to note is that sometimes it’s okay to pause your efforts. In fact, taking a step back can often prevent the change from dying completely.

When you do put the change on pause, compile a list of reasons why it’s failing and talk to the people with negative impressions to find out what you could be doing differently. From there, you may have to go back to a pilot phase in which you work with smaller teams to iron out the kinks before rolling out the change on a larger scale.

Finally, remember that sometimes not all changes are meant for the entire organization.

Q: What are some good ways to measure the success of the changes we make?

A: Start with surveys at key points, such as after a training session or after onboarding. Ask questions like: On a scale of 1-5, how effective was this training? Or, on a scale of 1-5, do you feel this tool will allow you to do your job more efficiently or effectively? The answers to those questions will help you understand the positive impact you’ve made for individuals.

On the backend, measure how long the process took compared to how long you estimated it would take and discuss the roadblocks you encountered along the way. That combination of satisfaction and business metrics will help you understand what you can do better for future implementations so that you can be more effective with the rollout.

Identifying Areas for Improvement: How to Pinpoint Opportunities for Change

No one is perfect — there will always be opportunities to improve what your organization does. But how do you identify those opportunities for change to make your testing organization more effective? It all comes down to communication and awareness.

Q: I know our organization needs to modernize testing, but I don’t know where to start. What’s a good first step?

A: You first need to identify the challenges your team faces. Is it that the work is too technical for the people on staff and they don’t understand how to do it effectively and therefore need technical training? Or is it that you’re drowning in production defects and need to focus on more of a process change or shift left in quality? In general, ask what you could change that would make a positive impact and then identify the techniques you can introduce to alleviate those pain points.

Q: How can we help QA stay on top of best practices and build leadership skills to effectively engage with stakeholders?

A: One of the most effective ways to help testers build new skills is through regular forums (e.g. lunch and learns, staff meetings, internal academies) focused on teaching testers about new areas where they need to strengthen their skills. A lot of great resources exist to help drive these forums, including Lynda, Udemy, Test Automation University, and Coursera. The Techwell and Tricentis blogs, Angie Jones, Jason Arbon, and Joe Colantonio also offer valuable advice on how to overcome common testing challenges and expand testing skills.

Critically, the trick is not to just let your team go off on their own and hope they acquire the right skills. Once testers go through training, you need to give them applications through their work that allow them to implement the new skills so they can start using what they learned.

Q: In an organization where testing has always been done by the application teams or project teams individually, what’s your advice for building a testing team from scratch?

A: Start by building a groundswell with a lunch and learn or a lean coffee approach. From there, you can typically build enough momentum to launch a community of practice, which is a group of likeminded people that may not have change authority on an enterprise-level but can come together to enact positive change. But you have to build the groundswell first because if you start out by launching a community of practice that everyone is required to attend, you won’t have as much participation as you will if you ask people who are interested in testing to come together to talk about a specific topic. Once you start building that groundswell (which will take time), it will naturally transition into a community of practice and maybe down the road a centralized testing organization or oversight team.

Q: What are the biggest challenges with a centralized testing model and how can you overcome those challenges?

A: The biggest challenge with centralized oversight of testing is awareness. Often times in an organization with centralized oversight, a lot of good work and research gets done but the communication about that work to the rest of the organization isn’t effective, so teams only see a “governing body” and not something that can truly help. When this happens, one issue that crops up is shadow testing, where folks create their own automation frameworks that mimic what’s already been created because they don’t know that one already exists. Overcoming this challenge requires more effective communication about the work of this centralized team.

The second biggest challenge is running effective pilots that feel helpful, not disruptive. To overcome this challenge, you need to make sure you fully take in and understand requirements from various teams. Doing that gives you the ability to gracefully implement a technique or process change that can help people and that they actually want to adopt.

Did this help? Comment and let us know your experience!

Topics:
transformation ,devops ,qa ,culture change

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}