Introduction
This is part 2 of a 2-part piece on the culture shift to Developer Testing. Part 1 covered the difference between “culture” and “practices” and their implications for your teams; it also examined the origins of “Developer Testing,” and discussed how much testing is a Developer’s responsibility. Part 2 will begin by exploring various cultural aspects of popular development methodologies with recommendations on how to successfully implement said cultural practices in your own teams; it will conclude by emphasizing the importance of getting culture right within your teams with 5 first-steps you can take. So, without further ado, let’s dive into part 2.
The Cultural Aspects of Testing & How They Affect Developer Testing
As I’ve emphasized numerous times, culture is the key to success when adopting any new initiative—not practices. Let’s look at some popular development frameworks and their principles that can help guide leaders on the journey towards a successful Developer Testing culture.
XP (Extreme Programming)
Extreme Programming (XP) aims to produce high-quality software by adhering to a set of values like communication, simplicity, feedback, courage, and respect. XP is culture and practices aimed at Developers and development which includes testing, but the core values surrounding XP are culture that enables modern development practices. For example, courage and respect are 2 deep-rooted values of XP that can foster a good Developer culture that supports and respects testing efforts:
Respect. Respect guides teams to work together and respect the variety and diversity of the team. Leadership has a great influence on how their teams behave; so, as a leader, you need to display and inspire the actions you seek. To create a culture of respect:
- Leaders should identify unhealthy practices, behaviors, and actions in your workplace and take steps to cessate and prevent them from happening. Examples include:
- Addressing team members for any displays of a lack of respect for each other (i.e., shouting, insults, etc.); it’s important that you do this privately with the individual to respect their privacy, as well as to not create a standoffish culture.
- Leaders should not participate in nor encourage “gossiping,” and rather instill a culture of open communication and collaboration that allows team members to feel comfortable talking about issues directly rather than “behind one’s back.”
Courage. Courage encourages teams to accept change and feedback—even when it’s tough to accept. To make courage a pillar of your team’s culture:
- Creativity and innovation are all about taking risks, and taking risks demands courage; as a leader, you should display and inspire the actions you seek—individuals will often take risks only when they assess it is safe to do so.
- Leaders should create an environment where failing is not considered as a blunder, but is celebrated for the learning it brought.
- Leaders should listen to and encourage their team members to put forward their ideas without fear. One way to do this is by utilizing an anonymous survey, such as OfficeVibe (we actually use this tool at LogiGear!), that allows your employees to report their feelings on various workplace-related questions. Remember, teamwork makes the dream work!
- Leaders should create an environment where failing is not considered as a blunder, but is celebrated for the learning it brought.
Having a culture of respect and courage provides Developers with the basics they need to feel comfortable experimenting, innovating, or working fast, and potentially breaking things without fear of recrimination, blame, or finger-pointing. Experimenting, innovating, and working fast are good things, but they may also be new ideas for Developers being thrown into the world of testing. They may also require more testing, not less. The value of testing increases with respect and courage.
Scrum
Fail Fast. Many organizational cultures find it difficult to embrace ‘Fail Fast’ as they see failures as a bad thing—but, they fail to realize that the best learnings come from failures. ‘Fail Fast’ is a philosophy that fosters innovation through extensive experimentation. The objective of the ‘Fail Fast’ is to prevent the sunk cost effect, but it also has huge implications for culture.
‘Fail Fast’ requires leaders to create an environment where the team has the freedom to fail. Innovations happen when self-organizing Agile Teams experiment and learn rapidly. Failures help teams to succeed faster the next time.
- When implementing new initiatives like Developer Testing, leaders should take a PoC-based (Proof of Concept) approach to minimize risk and maximize learning.
- Automated tests should be crafted to fail faster because the sooner the tests fail, the sooner the fixes can be rolled out.
High Involvement/Collaboration. Scrum is all about collaboration. When Developers and Testers collaborate, they get better testing. Understanding customers, the business, and use cases will help Developers to better test their code and mitigate risks at earlier stages. Similarly, Testers get awareness and understanding of the underlying code, technologies, and architecture, which can help them contribute at a white-box and gray-box level.
Below are a few examples that can easily foster collaboration in cross-functional Agile Teams:
- Static testing (involving everyone in the team)
- Code reviews
- TDD/BDD (Behavior-Driven Development)
- Teststorming (brainstorming test cases)
- Test case reviews (involving everyone in the team)
- Pair programming or testing (by pairing a Developer and a Tester)
- Acceptance criteria demos by Developers
- Bug bashes (open for the entire organization)
- UAT (User Acceptance Testing involving stakeholders/Product Managers)
- Collaborative testing in production using feature toggles
Many of these practices are common and well known; but, they also take time and skill to perfect. Optimize your skilled, in-house staff by matching them with tasks that match their skills. You can also look for opportunities for alternative staffing, like outsourcing for test execution or Automation to keep teams focused on their highest value.
Lean
Amplified Learning. Lean promotes a continuous learning culture that motivates teams to continually increase their competence and knowledge to gain new skills and expertise. Developers learning to properly test is critical to the success of Developer Testing.
Amplified learning is also testing and bug finding. Finding bugs is learning about the system—finding boundaries and bottlenecks, finding gaps in user stories, learning new use cases… extensive testing is key to amplified learning.
Some easy ways for leaders to promote a culture of continuous learning include:
- Leveraging technology—empower teams with on-demand learning with Learning Management Systems or online coursework/master classes
- Attending conferences (virtual or in-person), webinars, and talks
- Reading books, articles, and magazines (like the LogiGear Magazine!)
- Enrolling in courses and certifications
- Conducting training programs and workshops
- Peer learning (Testers training Developers on their expertise and vice versa)
Agile
Open Communication (No Finger-Pointing or Blame). Any communication within the Agile Team must be discussed with the complete team; this induces a feeling of harmony and transparency within the team. Additionally, it’s important to avoid blame culture and rather exercise a solution-based mindset.
- Instead of blaming people, identify the steps required to prevent such issues in the future.
- A solution-based approach to solving issues will also allow team members to feel comfortable bringing questions and issues to the team’s attention before they become larger, more costly problems.
These are just some of the many cultural aspects of software development and testing, but these are some of the most applicable that I find in regards to increased Developer Testing. ScrumButts, AgileFalls, DevOops—these are the cultural mistakes organizations need to fix before they can say they are truly “being Agile” or “doing DevOps.” Remember: Testing methodologies are more than just practices.
Culture Over Process, Practices, and Rituals
The majority of the organizations that adopt trends like Agile, Scrum, and DevOps spend a lot of time teaching processes, practices, and rituals when it’s the culture that matters the most. When organizations are looking to adopt a new testing methodology, the first step should be establishing and nourishing the culture surrounding the methodology. Processes and practices are easier to change, but the same is not true with culture and people.
Culture happens at many levels: Corporate culture, office culture specific to one site, product culture specific to one product line, organizational culture specific to a VP or Director; it trickles all the way to team culture or working agreements specific to a team, Product Owner (PO), or individuals on a team. I want to side-step any conversation on that—I am most interested here in organization or team culture, where day-to-day decisions and communication happen at a low-level between individuals. It’s my opinion that these are the most profound interactions that can have outsized impact not only on team dynamics—but also retention—a manager’s ultimate success or failure, and all the way to product quality. We’ve previously explored how leaders can build a strong culture across teams, but many of the ideas are applicable here as well.
This is a simplified and very quick overview of culture change. Changing culture is complicated, sometimes difficult, and occasionally problematic. Culture change requires commitment and dedication from the Leadership Team. Here are a few recommendations for tackling a culture initiative:
- Set a Goal. Where do you want to go? How do you want the team to interact? Do your research: Get inspired by other teams or organizations; run some experiments; take some chances.
- Objectively Assess/Audit What You Have. This is fact finding. It may not be easy, and you may discover some difficult systematic things. Some examples from my work over the years include:
- Problematic relations with POs
- Long-held resentment over finger-pointing
- Perceived favoritism
- Negativity or resistance to change
- Too much sarcasm
- Layout Your Vision for Culture. Make an implementation plan, or a “roadmap.” It may not be easy; culture is often hard to change—especially where there are already problems. You can’t just wave a magic wand and say, “OK! Everyone get along now and collaborate all the time.” That will (unfortunately) not work.
- Enroll the Team. Give the why—explain, enroll, and make it personal—build a case for the culture change.
- Check-in, Talk About It. Never miss a “teachable moment”—jump on them and use them. Even when it’s difficult, confront difficult issues. It will be a big benefit in the long-term.
It’s also critical that organizations get buy-in from management, leaders, and teams before adopting Developer Testing—remember increased collaboration, communication, and teamwork!
Summary
Developer Testing is a huge, complex, and very current topic. At first glance, it appears relatively simple: Have your Developers test their own code (and not only unit testing)! But, it’s so much more than that; Developer Testing needs to be viewed as an initiative or a project of its own, rather than a means to an end. The success of any Developer Testing initiative will be reliant on one thing: a culture that supports it. Without a culture that allows for new ideas, risks, failures, open communication, collaboration—all of the things we’ve covered in this article—innovation will falter and it’ll be hard to see the proposed benefits of Developer Testing come to fruition for your organization.
Establishing a supportive culture for Developers and the redistribution of testing tasks is essential in software development today. Cleaning up some old or bad culture is the first place to start. Laying out a vision for the team and enrolling the team in this vision is part of modern development management and not always easy.
One thing is still left unanswered: Is testing really a Developer’s responsibility? It’s hard to give a black-and-white answer, so we’ll have to say it depends. It’s not a yes or no answer. It’s how much. Are the necessary cultural principles in place that will support your Developers as they increase their ownership of testing? Do your teams understand the need for increased ownership of testing from Developers? Most importantly: Do your Developers have the skills necessary to support the quick testing cycles that many of these development methodologies (Agile, CI/CD, DevOps, Scrum, Lean) require? Do Developers have the skill or the time to focus on testing like a user, particularly the ambiguous area of negative testing?
More likely, with a modern culture in place, there will be a redistribution of testing tasks to speed up delivery, while also keeping team members focused on their strong suit. Developers are doing Developer Testing and Test Teams are focused on integration, workflow, platform and user-focused testing, as well as Automation test creation and maintenance.
Don’t be scared away from Developer Testing! Yes, it’s going to be a huge initiative, but it’s a worthwhile initiative as long as you ensure you’re doing it right. This post is not meant to encourage you to stray away from implementing Developer Testing, but rather make sure that you’re aware of the caliber of this implementation. So, go forth and conquer! Redistributing testing tasks to take full advantage of modern Continuous Integration, delivery tools, and more Test Automation, while focusing staff on their best skill sets will reduce schedules, improve delivering customer value, and—just as importantly—have happier, more productive teams.
Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), available in English, Chinese and Japanese, and Global Software Test Automation (HappyAbout Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries."