Is There A Problem Here?

Over the years, I have collected a number of examples of software failures in the wild -- some I've encountered myself, some were shared by others. I've had intentions to create a blog for sharing these software failures, and new ones as they are discovered, with hope that software designers, developers, and testers can discuss and learn from them. I have finally launched that blog. It is titled Is There A Problem Here?

I invite you to visit the blog and contribute at http://IsThereAProblemHere.com.

Have a great testing story to tell?

This coming July, my favorite software testing conference is coming to my hometown of Colorado Springs. What is my favorite testing conference? It is CAST, the Conference of the Association for Software Testing.

I'm not just saying this because I'm the President of AST or because I'm a member of the conference committee. I first heard of CAST and AST at another conference -- shortly after CAST 2006. People kept praising this event they were calling 'cast'. I heard stories of great presentations and debate. I heard stories of meeting great people and making new professional contacts. Others were excited about a new professional association for software testers. I heard stories of this organization adopting a code of ethics. I was intrigued.

Soon after, I joined AST and started making plans to attend CAST 2007. At CAST 2007 I found something I hadn't found at other testing conferences: I found a conference that made conferring part of the program. I was accustomed to conferring outside the scheduled activities, not it being an integral part of the program. Respected (and some despised) testing thought leaders, practitioners, and academics talked with one another, and listened to each other. Questions were facilitated after presentations. Some speaker's claims were challenged. Other claims were confirmed. Some speakers provoked enough interest that the discussion after the presentation flowed over into another room when the scheduled time expired.

I left CAST 2007 with new friends, new ideas, and new questions. That's what I want from a conference.

I am now intimately involved in planning for CAST 2009. We are working hard to assemble a great cast of top-notch invited speakers. We also want participation from others with something interesting to say about software testing.

The theme for CAST 2009 is Serving our Stakeholders. If testers aren't serving stakeholders, we're not likely to remain gainfully employed. The Call for Proposals for CAST 2009 has been issued. If you have a great story to tell or idea to propose related to testers serving stakeholders -- whether it be through applying soft or technical skills -- we want to know about it. Send us your proposal, and if accepted, you'll get free admission to the conference in exchange for a short paper and presentation.

Have a presentation idea? See the CFP below.

CAST 2009 CALL FOR PROPOSALS

The 4th Annual
Conference of the Association of Software Testing (CAST)
Colorado Springs, Colorado, United States
July 13-16, 2009

http://CAST2009.org

Serving Our Stakeholders

Keynote Presentation by Jonathan Koomey,
Project Scientist at Lawrence Berkeley National Laboratory, Consulting Professor at Stanford University,
and author of
Turning Numbers into Knowledge: Mastering the Art of Problem Solving

The Association for Software Testing is pleased to announce its fourth annual conference, CAST 2009, to be held July 13-16. The meeting will be held in sporty Colorado Springs, Colorado, at the Antlers Hilton Hotel. The Antlers Hilton offers stunning views of the Rocky Mountains and Pikes Peak, which serve as a dramatic backdrop for this year's theme: "Serving our Stakeholders".

Only rarely do we test software solely for the joy of finding a bug.
We test software because someone wants us to provide them with quality-related information about their software so they can make better decisions, fix important bugs, and/or assess regulatory compliance. Those someones are stakeholders. Generally, stakeholders fall into one of four groups: end users, regulators, business leaders, or development teams. Sometimes these groups have competing expectations.

• End Users: Many testers focus on the needs and expectations of end users. Do you? When you do, how do you go about donning an "end-user persona"? How can you be an advocate for end users? Are end-users the only stakeholders on your project?

• Regulators: When are regulatory agencies your most importantstakeholders? When are they just another source for requirements? Ordo they just generate busy work? How can we satisfy regulators without neglecting other stakeholders?

• Business Leaders: You may think of managers and executives as your primary stakeholders. Do you really give them the kind of business information they need? How do you provide business decision leaders with actionable information?

• Development Teams: Do your developers thank you for finding bugs, or do they hide when they see you coming? Do you treat them as your primary stakeholder? Do you think it would be useful if you did?

CALL FOR PROPOSALS

The CAST 2009 Program Committee is seeking proposals for papers and presentations that explain how testers can serve stakeholders. Both academic research papers and industrial experience reports are welcome.

In addition to presentations that demonstrate service to stakeholders, we're looking for personal experience reports that clearly demonstrate skills and practices of seasoned software testing professionals. We are looking for rich, diverse experiences and ideas that illuminate the theme.

If you have hands-on experience, and a fascinating story to tell, contact us and we will assist you in evolving your tale so it will be ready to present at CAST.

CONFERENCE FORMAT

CAST is designed to be a forum that stimulates discussion leading to innovation in software testing; and so is distinguished by significant interaction among presenters and attendees. Papers, experience reports, and presentations are challenged, debated, and discussed by conference attendees. We encourage and facilitate conversation by building flexibility into the schedule so that topics generating high energy can be explored more deeply without adversely disrupting the course of conference events. Trained facilitators will ensure that discussion sessions are appropriately structured and productive.

PROPOSAL SUBMISSIONS

Please submit an abstract for consideration by March 23rd. Abstracts should be 2-3 paragraphs in length explaining what you would like to write about and present. Submit your abstract via email to cfp@associationforsoftwaretesting.org.

March 23rd is the final deadline for submissions. Good proposals may be accepted prior to March 23rd, so submit your abstracts as early as possible before the schedule fills up.

If your proposal is accepted, you are expected to write a two to ten page paper on your proposed topic. Papers will be peer-reviewed to help you refine your ideas and presentation.

Although we are not associated with ACM, we encourage paper authors to follow the ACM SIG Proceedings style, freely available at http://www.acm.org/sigs/publications/proceedings-templates. However, please do not let this format restrict the quality of your paper. Use the format as a guide, not a restrictive template.

Authors of accepted abstracts will receive complimentary registration for CAST 2009. (This does not include tutorials or workshops.) Submitted papers will be published in the conference proceedings.

PEER REVIEWERS

In addition to presenters and papers, we are seeking software testing practitioners and academics to review papers. To best serve the stakeholders of CAST 2009, we need testers to work with authors to help refine papers. If you would like to volunteer to review papers, please send an email indicating your desire to be a reviewer to cfp@associationforsoftwaretesting.org.

IMPORTANT DATES

• Monday, March 23, 2009 : Final date for abstract submission -- submit as early as possible
• Monday, March 30, 2009 : Final notification of acceptance/rejection
• Monday, April 20, 2009 : Deadline for submission of paper for peer review
• Monday, May 18, 2009 : Deadline for submission of revised paper for peer review
• Monday June 1, 2009 : Final papers & slides (if applicable) due
• July 13-16, 2009: Conference

CONFERENCE CONTACTS

For further information about CAST 2009, please contact a member of
the conference committee as listed below:

• Sponsorship: Scott Barber, executive.director@associationforsoftwaretesting.org
• General Conference Information: Ben Simo, president@associationforsoftwaretesting.org
• Program: cfp@associationforsoftwaretesting.org

I'm helping you. I'm helping you.

A few months ago, I enlisted my 11 year old son to help me with some work around the house. After a short while, he was doing something other than what I had asked him to do.

I told him, "You're not helping me."

"But I am helping you.", he replied.

"No you're not."

"I'm helping you. I'm helping you.", he shot back. He was frustrated. He really thought he was helping me; and I was putting down his work. I was frustrated too. From my view, his helping was creating more work for me. I did not feel helped.

Then it hit me. I've heard this argument before -- from software testers.

I've seen testers, and test managers, attempt to justify their work by telling team members and stakeholders "I'm helping you. I'm helping you." We QA and tester people develop metrics and reports to help us demonstrate how helpful we are. We talk about our quality assurance and testing processes. We talk about all the test cases we develop and execute. We like to show off our test automation that spits out impressive color-coded results.

However, we still encounter unhappy team members and stakeholders. We develop adversarial relationships with developers. We have to explain ourselves to project leads that question the value of our testing. We hear people tell us we're not helping and we keep saying "I'm helping you. I'm helping you."

Maybe, just like my son, we're not giving our stakeholders what they need. Maybe we aren't really helping. So instead of shooting back the "I'm helping you." line, we can stop and listen. Find out what our stakeholders want from us. Listen and ask clarifying questions to better understand how we can help.

I'm not advocating that we just give in and do whatever we're asked without defending our positions. However, we can be willing to adjust our positions to better serve our stakeholders. (Joining an overly optimistic rush to release poor quality software usually doesn't serve them.) If there is disagreement, work to resolve it. Sometimes we may need to educate others on our areas of expertise. Yet we testers also need to respect others' roles and expertise. Listen and learn.

So, the next time you feel like screaming "I'm helping you. I'm helping you.", try to better understand how you can help before turning up your defenses.

Serve your stakeholders.