Insider Tips for DevOps, Testing, and Automation

At the Postman Galaxy virtual API conference in February 2021, I had the opportunity to host the “DevOps, Test, and Automation” panel discussion. My fellow panelists were Alla Lazareva (head of QA at Ziwo), Angel Rivera (developer advocate at CircleCI), and Kevin Harris (API integrations SME and IQmetrix). Check out the on-demand video at the end of this post for the full conversation. But first, I’d like to recap some of the key discussion points. Spoiler alert: It’s about people, not tech.

Getting buy-in for automation projects

Sometimes we think of automation as a switch getting flipped that initiates a clean, functioning system leaping into action. But the reality is more of a process—it can be messy, it can be granular, and it often requires significant upfront investment. For this reason, I asked the panel: How do you go about getting buy-in for automation projects?

• Alla observed that people will invest in something when they see its value. Show automation working: release often and build demos, explain the risks that are covered by API test automation, and show the improvements automation brings. All of this helps people to see the value. Also, speaking their language helps.
• Angel explained that DevOps is really about developer and organizational culture. Implementing a DevOps program requires knocking down barriers between teams and roles—it’s about people. Advocating for improved communication and collaboration sets the scene for leveraging automation to get things done even faster. Companies will commonly invest in DevOps then revert back to old habits, perhaps because the DevOps cheerleader left the team—these are people problems more than tech problems.
• Kevin shared about his experiences onboarding people who are new to Postman, including developers creating systems for clients. People often carry out repetitive api testing processes that waste lots of time when accumulated, so helping them discover ways to reduce this repetition is hugely valuable. For example, pass data between requests instead of copying and pasting.

Navigating tricky conversations with other teams

In a DevOps, testing, or QA role, you’re inevitably going to expose issues with the work carried out by other teams, especially engineering. I asked the panel for tips on navigating these sometimes sticky interactions.

• Speaking from past experiences in more than one role, Alla reminded us that developers can be intimidated or put off dealing with an issue if it looks like it’s going to require difficult investigation. Making tickets and bug reports as accessible as possible to developers is ideal, making sure you’ve tried to identify a root cause and outlined reliable steps to reproduce the issue, referencing requirements if appropriate. Getting to know team dynamics can also give you a sense of conversations that are going to cause friction.
• From Kevin’s perspective in client-facing projects, feature requests have been the most likely source of tricky conversations. Streamlining the communication channels so that all client development projects are filtered through a single point of contact has helped create clarity and reduce wasted efforts on unnecessary projects.
• From a DevOps standpoint, Angel explained that shifting away from roles and responsibilities helps focus on improving processes. Establishing communication practices that everyone agrees with and that add value paves the way for automating and removing a lot of these conversations. Meeting developers where they are rather than defending roles helps—people get scared at the prospect of being automated out of a job. Prioritizing an “always be learning” mindset is an asset in tech, where the reality is always changing.

This last point by Angel about the fear of being automated out of a job is a hugely important one in my opinion—automation should free people up to work on more interesting problems. But in order for that to be the case, we need people to be informed and empowered around tech, all to ensure that automation benefits all of us.

Who cares about standards?

At Postman, we try not to force people to use particular formats and instead try to support whatever they’re using on their projects. But due to a lack of standardization in the API space for a really long time, we do see some consensus around OpenAPI. I was curious to know whether Alla—in her work leading QA—is also finding interest in standards.

• Alla said that large companies do care about standardization, because having an unpredictable, poorly documented API is just too costly. Smaller companies tend to be less focused on standards because the onus is on releasing fast rather than on onboarding. In general, the industry seems to be putting more emphasis on user experience (UX) and developer accessibility, which are made significantly easier by standardization. Documentation is also a huge help to any automation project, as it’s tough to automate something that isn’t documented.

How are people getting into what you do?

As someone working in developer relations, a field you tend to discover rather than work towards intentionally, it always interests me to hear what career pathways exist for tech roles, especially around emerging disciplines. One of the projects I work on at Postman is our student program, and we find that the more traditional education institutions are less likely to be teaching APIs than the more vocational organizations, like coding bootcamps. I asked the panel members how they’re seeing people navigate towards the types of careers they each have.

• Angel agreed that people aren’t often trained in modern software practices through traditional courses, so they’ll more likely just have a grasp of fundamentals (and see tech in a more monolithic way than the current reality). Encouraging learners to get hands-on practical experience can give them a chance to reduce the gap, for example, through events like hackathons. Helping people learn workplace skills such as navigating teams, using tooling, and more is essential.
• Kevin reiterated that once you have a foundation of essential skills from a course or self-taught experience, you can learn the rest as you go along. Using standards can also help with employability skills, enabling people to move between companies. Taking opportunities to learn and finding mentors can also be helpful. Docs are the lifeblood of working with APIs, so learning how to read and follow them is key.

In the work I do with students and learners of all kinds, I always stress that any course only equips you with a foundation—because in the ever-changing tech landscape, you are always learning. I strongly believe that we can also do a lot more in the industry to further train and prepare people.

Watch and learn

Watch the full “DevOps, Testing, and Automation” panel discussion here:

Join the conversation!

Do you have experiences or thoughts on anything we discussed in the panel? Please share them in the comments.

Related: Use the API Testing Templates