As a career software tester, I’ve heard rumors DevOps culture will put me out of a job, so I took a job testing for a DevOps team. I’m new to DevOps, but aren’t we all? What matters most is our teams’ intentional decisions to grow our DevOps practices along with our development community.
Join me as I share my experiences blending disciplines, companies, levels of experience, and differing expectations as a member of efficient and effective delivery teams. I’ll describe common cultural and interpersonal problems I experienced while transforming a cross-functional agile team dogfooding a DevOps implementation.
Whether you’re into development, operations, testing, customer support, or product ownership, you’ll leave with concrete strategies for improving your DevOps working relationships to keep the technology running smoothly. People factors strongly affect your DevOps technical outcomes, so optimizing your flow includes improving your people practices.
Don’t feel afraid to ask about DevOps anymore!
The people factors that strongly affect your DevOps technical outcomes
Collective ownership for testing starts with understanding testing. Rework your team dynamics to evolve past duplication and improve performance through whole team testing. Take home practical patterns for improving your team’s collaboration on testing. Because teams who own testing have more confidence in the customer value of their results.
As the Pragmatic Programmers say, “refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully,” so how do we begin? In this session, we will experience the complex interactions of an agile team focused on demonstrating customer value by answering a series a questions:
Where do testers get their ideas?
How are you planning to accomplish this proposed testing, tester?
Why not automate all the things?
Who is going to do this manual testing and how does it work?
How do we know whether we’re testing the right things?
Build your own list of TODOs from these various practical collaboration approaches and begin deduping your team’s testing for a better first day back at the office.
Approaches to handle objections to executing the testing work
Ways to mentor test helpers, including pairing
Investing in testing the team believes in
Understand how other team members have been testing the work so far
Advising on opportunities to inject test thinking into all of the team activities, from story writing through to unit testing, to make the system more testable
Think manual testing is waste? Think again! If you’re not learning when you’re testing, you’re doing it wrong! People exploring systems can be your best defense against unknown problems and your greatest way of finding unexpected opportunities.
While automation is well adapted for repeating the same thing over and over again, human beings are great at doing things differently.
Doing is not enough! We need to think during our review and examination processes to improve outcomes. How do we design manual exploration to provide value in today’s fast-moving development culture?
Come to this workshop for hands-on experience with the full lifecycle of exploratory testing charters.
Structuring manual exploratory testing for transparency
Claire takes us on a nontraditional journey where designing and implementing testing approaches can be rapidly organized into a hierarchy of connected elements. Mind maps, used primarily for visual and conceptual thinking, may be just the answer for quality assurance professionals.
Recently, Testing Circus was asking about how testers are framing their new year. Many testers contributed their plans to form quite a list! Will sharing our plans with others help us to achieve what we set out to do? It seems worth a try. More to the point, will we actually execute all the plans we make? I think it will be much like exploratory testing in adjusting based on new information we learn, but at least I’m starting out with a plan.
Here are my charters:
Read. Blogs, books. Or even watching videos and listening to podcasts. (I know not everyone is a visual learner.)
Claire Moss shares with us a personal story on how using agile methods helped her family with managing meals and groceries. By using techniques like a Big Visible Chart, dinnertime for Moss’s family became less of a chore. Remember, nothing ever goes according to plan, but that’s true for any healthy team.
Here’s the big visible chart that turned our dinnertime struggles around:
As Agile2013 considers itself a best in class kind of conference “designed to provide all Agile Team Members, Developers, Managers and Executives with proven, practical knowledge”, the track committees select from a large pool of applicants and prefer vetted content that has worked its way up from local meetings to conferences. I have only one talk that fits this criteria since I presented Big Visible Testing as an emerging topic at CAST 2012. I developed several versions of this talk subsequent to that event and doing so had given me confidence that I would be able to provide valuable information in the time allotted and still leave enough time for attendees to ask questions and to give feedback on what information resonated with them.
I worked to carefully craft this proposal for the experience reports track, knowing that if I were selected that I would have a formal IEEE-style paper to write. Fortunately, my talk made the cut and I began the writing process with my intrepid “shepherd” Nanette Brown. I wasn’t sure where to begin with writing a formal paper, but Nanette encouraged me to simply begin to tell the story and worry about the formatting later. This proved to be wise advice since telling a compelling story is the most important task. Harkening back to my high school and early college papers, I found myself wading through different but largely similar drafts of my story. I experimented with choosing a different starting point for the paper that I ultimately discarded, but it had served its purpose in breaking through my writer’s block. Focusing on how the story would be valuable to my readers helped to hone in on sequencing and language selection. Once I had the prose sorted out, I began to shape the layout according to the publication standards and decided to include photographs from my presentation – the story is about big visible charts after all!
Investing sufficient time in the formal paper made preparing the presentation more about strong simple visuals. I have discovered my own interest in information visualization so prototyping different slide possibilities and testing them out with colleagues was (mostly) fun. I’m still not quitting my day job to go into slide deck production. Sorry to disappoint!
Despite all of this preparation, I couldn’t sit still at dinner the night before my presentation and barely slept that night. I woke before the sunrise and tried to school my mind to be calm, cool, and collected while the butterflies in my stomach were trying to escape. This was definitely the most challenging work of presenting!
As a first time speaker, I didn’t know what to expect, so I set my talk’s acceptance criteria as a rather low bar:
Someone shows up
No one hates it enough to leave a red card as feedback
When I walked into my room in the conference center, a lone Agile2013 attendee was waiting for me. Having him ready to go encouraged me to say hello to each of the people who came to my presentation, which in turn changed the people in the room from a terrifying Audience into many friends, both new and old. I think I managed not to speed through my slides despite my tendency to chatter when I’m nervous. I couldn’t stay trapped behind my podium and walked around to interact with my slides and to involve my audience more in the conversation. Sadly, I can’t share my energy with you since I forgot to record it. Oh well. Next time!
The vanity metrics
At 10 minutes into the presentation, 50 people had come to hear me speak and at 60 minutes I had somehow gained another 7 to end at 57 people. Thanks so much for your kind attention! I hope I made it worth your while…
43 people stopped to give me the simple good-indifferent-bad feedback of the color-coded cards (which I liked as a simple vote about a presentation) and I received 37 green cards and 6 yellow – with no red cards! Whoo hoo!
Words of Encouragement
Two people kindly wrote out specific feedback for me and I want to share that with you in detail, hoping to elicit some late feedback from attendees who might like to share at this point (Agree or disagree, I want to hear from you!)
Feedback Card #1:
– Best session so far!
– Great presenter – great information – great facilitator
– Would like to see future sessions by this speaker
Feedback Card #2:
Great Talk – speaker very endearing, Her passion for the subject matter is obvious.
A fresh perspective of how Developers and Testers should interact.
Should find ways to engage the audience
Someone else got a kick out of my saying, “I’m serious about my stickies.” and left their notes behind on the table after leaving. So thanks for sharing that. 🙂
One friend spoke to me afterward with some helpful feedback about word choice and non-native English speakers. When I was writing my talk, I was trying to focus on people who would be likely audience members, but I had not considered that aspect of the Agile2013 crowd. Since I was simply speaking off the cuff, I ended up using some words that would have fit in at our dinner table growing up but that would make for tougher translation. And yet, I got some wonderful feedback from Hiroyuki Ito about the “kaizen” he said I made. I can’t read it directly, but Google Translate assures me it’s good stuff. 🙂
Finally, I discovered that my relationship with a linear slide deck is not a comfortable one. I wanted to be flexible in referencing each of the slides and having to sequence them hampered my ability to respond easily with visuals when discussing questions or improvising during my talk. I haven’t experimented with other presentation options, but I hope there’s an easy solution out there.
During the year and a half of experimentation that included the big visible charts that are included in this slide deck, I read over the following resources, only some of which would easily fit into the IEEE format. This is the full bibliography of my research, as far as I have been able to track down my sources. (At the time, I wasn’t expecting to cite them for anyone else, so I probably didn’t bookmark everything I read.) I hope the following links will prove helpful to you in developing your own big visible charts. Let me know how it goes! And please share any sources that you find helpful. I’m always looking for new inspiration.
My first dev team was an XP dev team that dogfooded our own digital signage product to display success/failure for the thousands of unit tests in the suite (i.e. single flag for whole suite red/green).
Other eXtreme Programming big visible charts
Although the above resources were all I knew at the time I began my experiments, as I prepared my IEEE paper for the Agile2013 conference proceedings, I was tracking down my sources and came across these other relevant pages & posts that have given me some great ideas of things to try next!
After some discussion in my session about suggesting solutions for distributed teams, I was looking for some digital implementations of big visible charts, but I don’t know how these would work out for you.
Back during Test Coach Camp 2012, Michael Larsen made some great recordings of our open space sessions. Subsequently, he published Ken Pier‘s session topic E vs A – Huh? under the title Exploratory vs. Automation in the TWiST podcast feed.
I have always thought of myself as an agile tester. After all, my development teams have always delivered features in 2 week sprints. My testing activities included reviewing requirements or stories before the planning meetings to assemble a list of questions and test ideas that I would use to approach the work proposed. I participated in a review before code completion that allowed for some exploratory testing, brief and informal though it may have been at times. In the past couple of years, I also planned and coded test automation.
However, over the past year, I have been transforming from a pseudo-agile tester to a true agile tester. Rather than sitting apart from the software developers in my own quality engineering department, I am now seated in the same room as the other employees from a mix of disciplines who are on my product delivery team. Rather than testing in a silo, I have been gradually increasing the visibility of testing activities through exploratory test charter management, defect backlog organization, and paired exploratory testing with both testers and non-testers. The feedback loops have shortened and the abbreviated time between activities necessitated adjusting how I provide information.
Testers are in the information business. We take the interests and concerns of the business as communicated through the product owner – or in my case the product owner team – and combine those with the needs of the customer as expressed in the story and further augment those with our experience using and analyzing software for deficiencies, abberations, and oddities. We draw upon a variety of resources including the experience and perspectives of fellow testers, heuristics, and product history to approach the goal of delivering a product the customer values, focusing especially on the quality aspects of that value.
Now that the audience for my testing comprises a mix of disciplines and the work environment has shifted from a heavier process to transparent, quick information access, I have been experimenting with different ways to execute testing and to represent the outcomes of that testing activity so that the information consumers understand it in ways that best suit each of their perspectives.
In my brief presentation, we will examine 3 different agile team member personas and their implications for presenting and maintaining testing information as well as the inherent tensions between their distinct and various needs. I will trace my learning curve of adjusting to their needs through the various experiments I have completed in this context, though these lessons extend beyond a purely cross-functional agile product development team.
Other testers will come away with a fresh perspective on viewing their product team members and focus on the value testing artifacts provide to a software development team.