CAST 2013

Can’t we all just get along?” is the famous rhetorical question from Rodney King, lightning rod for a series of 1993 riots in Los Angeles. Police officers who’d beaten him with clubs a year earlier during a traffic stop were pronounced Not Guilty, fueling race rage to no one in particular, and L.A. communities were set ablaze by its own citizens.

In software testing, the riots are invisible, but the rage is out there. Maybe you’ve heard “testing is dead”; “automation will find better bugs”; “don’t bother testing, our customers will”; “we’re moving to a Center of Excellence model”, or “our certified testers are ‘elite’”.  Maybe your outrage is smoldering, triggered by bad management, bad metrics, unethical practices, and an industry that seems bent on replacing testing skill with the latest open-source automation platform.

If there’s anything that’s ever been out there that made you want to argue, but held you back, come vent with Jon in this keynote. As the brother to James Bach -- software testing’s most prominent lightning rod -- Jon’s short answer to the rhetorical “can’t we get along?” is “well, no, we can’t”.  There are good reasons for this: debate forms identity; argument fuels scrutiny; and being “contrary” reveals new problems and opportunities. The basis of the CAST conference was to provide a higher degree of scrutiny and debate – to welcome and foster critical thinking and challenges to speaker content. 

In this keynote, Jon talks about the power of conflict at work and in the software testing community. If “a house divided against itself cannot stand”, then let Jon tell you his opinion on why “good fences make good neighbors.

The entire approach toward software testing was drastically transformed at a major health insurance company over the past year. In 2010, Brian Demers was hired to guide “transformational change” in the testing department at Premera Blue Cross based near Seattle, WA.

Brian explains the successes and failures that he had over the past three years. He talks about what worked, what didn’t work and the steps that eventually brought him to his decision to train his entire test department and their management in a different approach to software testing.

Paul Holland, an independent software consultant and teacher, was brought in to help Brian with the transformation. Paul taught the Rapid Software Testing class to the ~70 testers, four test managers, and the test director. He helps Brian explain this success story from the viewpoint of the facilitator and teacher.

Brian and Paul explain how the test teams were trained, how the teams were involved after the training to get their buy-in to the implementation, what improvements have been seen and how difficulties were overcome.

 

 

In an ideal world we would happily go along and collect experiences. These experiences would lead to learning and every mistake creates a lesson learned upon which we fine-tune our actions.

My experience, however, is that I sometimes utterly fail. There are times where I don’t even know what the lesson is I could learn from. The state I am in is one of confusion. Confusion can either be paralyzing or a starting point for a deeper learning experience, which is not a straightforward matter but a complex long-term path.

During this session I will explore some of my own failures and identify patterns that lead to them. I also want to include the experiences of the audience and engage in a discussion about failures and what came out of them.

Imagine that you have a group of students, between the ages of 16-­24. Imagine that these students have traditionally come from backgrounds and environments where technology and science has not been a prominent factor in their lives. Now imagine an initiative aimed at helping those same students being given an opportunity to participate in an internship program where they test software. What would you want to have them learn? How quickly? In what format? What can we do to have these interns be both excited about what they learn, and want to carry that knowledge forward as a career?


Actually, we don’t have to imagine. This program exists, and is happening now. The program is called SummerQAmp, and the participants are 16-­24 year old students, many from non  technical backgrounds, looking to develop skills towards software testing and quality assurance. AST and the Education Special Interest group took the lead in working with the SummerQAmp program to develop the training materials. We are, right now, actively creating the materials to be used for 2013. Through numerous revisions, a lot of collaboration, and comparing notes with many software testing professionals, we sought to answer one over-­arching question...“What did we wish we knew about software testing when we were younger?”


This talk looks to share the decisions we made, the materials we chose to use, the questions we asked and the answers we found, as well as both the positive and negative feedback we received in the process. Our hope is that these materials can be used as a model to help teach the next generation of software testers, and go beyond just the SummerQAmp participants.

We all want to test with “brain engaged”, right?  But what engages your brain? Software testing offers a range of problems and goals of all sizes. Sometimes you can feel like the job is too small and claustrophobic, or else vast and confusing. The right size problem engages your brain at maximum capacity.

The timeframe of the goals you share with your boss, your timespan of discretion, determines how you feel. You may need tighter feedback loops and more oversight, or larger goals and more discretion. Your team may need different size goals to suit each individual’s capacity.

This session will help you discover the timespan of your testing, see if it works for you, and tailor your shared goals to find the right size ones to strive toward. With these ideas you and your team can stay “brain engaged”.

“CAST Live” is a show broadcast live each evening following the close of the conference. CAST Live is hosted by Benjamin Yaroch and joining Ben this year will be Paul Holland. Each night Ben and Paul will recap that days events, interview influential testers, and discuss all things testing.

Join our live studio audience in Ballroom AB or via the webCAST.

Using retrospectives and extracting lessons learned are common tools teams use to evaluate a work effort and come up with ideas about what to do again, what to avoid, and what to do differently. This can be a fabulous opportunity to explore processes, team dynamics, organizational influences, external factors, personnel issues, management strategies, guidelines and procedures, tool support, skills, and anything else that contributed to the team’s success or failure in achieving their goals. But far too often, lessons learned exercises are forfeited due to lack of time, priority, or interest. Even more tragic is when the time is spent improperly – playing the blame game, venting sessions with no action, gathering data for performance appraisals, etc. – retrospectives can become demoralizing, cause people to participate poorly or even avoid the exercise altogether.

Overall, turning the critical eye toward our own work, analyzing our own failures and shortcomings, can be a difficult task. So I suggest we do it more! Especially if retrospectives and lessons learned sessions are not done or done poorly on your projects. Let’s perform personal retrospectives! We can file bugs and perform assessments on ourselves. What we discover can inspire change and personal evolution (and sometimes revolution!) leading to things like establishing favored protocols, reducing unproductive habits, seeing and avoiding traps, finding skill and knowledge gaps, identifying the need for mentorship or opportunities to mentor others, or whatever else you need to become the best master craftsman you can be.

In this session, Dawn will illustrate how she has used introspective retrospectives throughout her career to learn from her experiences – not only to improve personally, but to generate lessons learned to share in coaching and mentoring sessions, conferences presentations, consulting engagements, and training courses. What will you learn, or re-learn?  

By marshaling credible and persuasive evidence, influential testers answer three basic questions: How good is the product? What testing did you do? Why is the testing any good? Feeble evidence and the behaviors associated with it are common testing maladies and threats to your ability to tell a compelling story. What are the qualities of strong evidence, and the anti-patterns and risks of weak evidence?

Griffin Jones presents the different qualities and types of evidence. We review threats to the credibility and persuasiveness of your work, such as:  The danger of false-negative results reported as “pass - as expected”, “Lullaby Language” as an anti-pattern of Lean’s Genchi Genbutsu (go-and-see), the danger of obsessing on efficiency and how it biases the observer. Finally, we show how over-scripted procedures can superficially conceal fatal evidentiary flaws. Be intentional and critical about the type and quality of your evidence. Leave with the skills to recognize and evaluate the dangers and risks, strengths and weaknesses of the evidence you use for your testing story.

The relationship between business leadership (aka upper management) and testing teams is a challenging one. These teams often seem at odds in the struggle to deliver both quality and value.

Dee Ann is a Tester. Manuel is a Business Leader.

In this session we will share stories and discuss the dynamics of this often tumultuous relationship. We believe there are a number of common misconceptions and stereotypes that prevent people in these roles from communicating their needs effectively. But this relationship doesn’t have to be so strained.

We will tackle the problems that people in these roles face as they work together. The purpose of this session is to provide ideas for constructive communication, productive deliverables, and an improved understanding of the perspectives of the people in these vibrant and vital roles.

It has been 11 years since Lessons Learned in Software Testing has been published, and about the same time since the concept of the four schools in software testing came up. Since then a lot of things happened with the advent of more and more agile methodologies, online courses like the black-box software testing series, and the recent advances in web technology.

But what does that tell us about the future in software testing? With the different advances in both technology and business, testers nowadays face many challenges. Some of them hint towards a difficult future in testing, some of them make testing a bright spot in the future to come. After eleven years, it's time to take a look back, and see where we struggle, and where we shine, and how to advance from here.

You will learn about the concept of the four schools in software testing, where the model helped to advance our craft, and where it has not, and possible next steps for the future. You will walk away from this presentation with new things to think about.

Best of the lightning talks, the top three talks from Tuesday night will take the stage.

Rob and Scott will share with you their lessons learned at CAST 2013. This is sure to be an energetic tour de force of this year's conference and you won't want to miss it.

 

“CAST Live” is a show broadcast live each evening following the close of the conference. CAST Live is hosted by Benjamin Yaroch and joining Ben this year will be Paul Holland. Each night Ben and Paul will recap that days events, interview influential testers, and discuss all things testing.

Join our live studio audience in Ballroom AB or via the webCAST.