Presented by 8-10 of your fellow QASIG participants
The format was the “lightning talk” where each of the speakers knew that they only had five minutes to present their idea (one at a time). Each speaker had a severely limited time-frame, but could speak about anything related to testing in that time – a new idea for status reporting or measurement, a lesson they learned on a project, an experience report about a new technique they tried, or a general test principle they want to share.
Lightning Talk Speakers, Topics, and Slides (where submitted):
|Jim Hancock, Director of Quality, IT and Customer Delivery at Geospiza
||Creating a Quality Index
||Most software development has become “agile,” but CMM, CobiT, PMBOK, Malcolm Baldridge and other quality process metric deployments are still large and complicated. Jim will discuss how to deploy software quality metrics that meet the following criteria: objective, non-obtrusive, flexible, repeatable, consistent, holistic, efficient and inexpensive. Most importantly, the Quality Index will provide an accurate assessment of risk and quality within any SDLC upon which logical deployment decisions can be made.
|Jeremy Lightsmith, Seasoned Agile Coach, Trainer and Facilitator
||What’s Your Conflict Management Style?
||There is a model of the way people respond to conflict that looks like the attached picture. I thought it would be cool to introduce it and talk about why it’s helpful and how to use it. There’s also a related questionnaire that I can leave for everyone to see how they score.
|Jeff Brewster, Grameen Foundation
||Untethering a Test Lab
||Do you have a performance test lab that can only be used onsite or has expensive software? Been forced to share lab resources due to cost or space concerns? We’ll share the steps the Mifos testing team used to move their performance test lab to the cloud.
|Tim Tapping, SDET, Expedia
||How to sprint as Agile/Lean QA on the feature team
||QA has challenges if we are used to building out test plans from extensive documentation which is not present in a agile/lean development environments. We need to engage early in the iteration and help the team understand that ‘quality deliverables’ are a team activity. Drawing on my recent experience at an acquired startup which was an agile shop, I can share techniques that worked for us and pitfalls to avoid.
|Jon Bach, Manager for Corporate Intellect, Quardev, Inc.
||I’m working on a talk for Ignite (Seattle) that has a likelihood of being chosen. How much of a likelihood depends on well I can define this talk about our industry to the technical masses. I could use some feedback.
|Lanette Creamer, Test Lead, Adobe Systems
||Agile Testing Ninjas
||If Adam Goucher learned everything he knows about testing from Pirates, why does Lanette insist that Ninjas hold the key? What is it about stealth, speed, discipline, and skill that translates well to Agile testing?
|Jim Benson, CEO, Modus Cooperandi
||Kaizen or Death
||If we don’t improve, we stagnate. If we stagnate, we perish. Life requires change, renewal, and innovation. Evolution is innovation. In life, in business, in everything, we must continuously improve. In 5 short minutes, Jim Benson will change your life through the Japanese concept of Kaizen (continuous improvement).
|Gary Knopp, SDET, Attachmate
||Chow, Expand Your Idea of Dogfood
||This talk will be a quick case study of how we were able to break out of what seemed like an obvious test strategy (using or extending our existing test system) and move to a lighter-weight, component-based test approach. This new approach includes testing the component in isolation, the usage of the component in isolation, and then the system as a whole. Ultimately we were successful in using this strategy and even completed the testing 2 weeks early.
|Michael Wolf,Perl Trainer, evangelist, programmer, community member, town crier…
||TAP – Test Anything Protocol
Presented by Jim Benson, CEO of Modus Cooperandi
What is QA?
When we seek Quality, we are looking for something more than “Does it break if I do this?” We are looking for improvement, for ascendancy, for something better.
Scripts, exploration, observation.
We look for patterns, we look for exceptions, we look for jarring transitions.
In Personal Kanban and Lean, we look for patterns, exceptions and transitions in the creation of value and the flow of work. Think of it as QA for your workload and your processes. QA for your QA.
On the 12th of May, we discussed how Lean techniques like Personal and Organizational Kanban can be applied to the highly variable workload of a tester. How understanding the variation in work and making judgments based on this understanding will help testers, managers and clients schedule for testing and the impacts on QA of unreasonable demands.
We will, at last, be able to define “unreasonable” and provide meaningful service level agreements.
About our speaker: Jim Benson is a collaborative management consultant. He is CEO of Modus Cooperandi, a consultancy which combines Lean, Agile Management and Social Media principles to develop sustainable teams. Clients include the United Nations, World Bank, Microsoft, and NBC Universal. Jim created the Personal Kanban technique that applies lean thinking to individual and small team work. He blogs at evolving web and is @ourfounder on twitter.
Reducing Test Case Bloat
Presented by Lanette Creamer
We may think we are ready to move onto new and innovative features. However, if we do not deal with the past, it can easily come back to haunt, slowing down new projects, and robbing our testing time unexpectedly, often to the point that testing becomes the bottleneck that slows innovation to a crawl.
For those of us who work on software that already exists, exciting new functionality and improvements are the main things that drive upgrades, as well as compatibility with new platforms. However, if end users cannot trust the quality of the legacy features they rely on, they will be reluctant to upgrade, or worse, your new versions will get a reputation of being unstable – harming overall adoption. In some cases users may downgrade their software to an earlier version because they are unhappy with the quality of the newer release or request an earlier version they feel is reliable.
This paper presentation is about the subjective and difficult part of testing which has no provable mathematical correct answer. It is about risk management, test planning, cost, value, and being thoughtful about which tests to run in the context of your specific project. The discussion covers identifying and reducing test case bloat, when it can be done, who does it, along with a few examples used in practice. Further, it will cover one untested but under test theory, experiences shared in significantly reducing test cases to cover more than three times the applications when the test team reduced from sixteen to four testers. When facing increasingly complex software and growing software, we must balance testing existing features that customers rely on every day with new features and interactions. When balanced in a sensible way, the best of the legacy test cases can be maintained, using existing knowledge to reduce risk as much as possible.
About our speaker: Lanette Creamer is a test lead with 10 years industry experience ranging from product feature testing on early versions of InDesign to leading collaborative end to end workflow testing across the Adobe Creative Suites. Most recently Lanette has been testing on an agile team that is automating the software production process between a product build and actual shipment, to be used on all Adobe shipping products in 2010. Lanette has two published technical paper “Testing for the User Experience”, voted best paper by presentation attendees at PNSQC 2008 and “Reducing Test Case Bloat”, PNSQC 2009. Her magazine article “9 Ways to Recruit Testers for Collaborative Test Events” was published in Software Test & Performance Magazine, in the January 2010 issue. Lanette started writing a testing blog at http://www.testyredhead.com in 2006 and has been writing and collaborating with the online testing community non-stop since.
Presented by Detective Brian Stampfl
Detective Stampfl from the Seattle CSI unit will be joining us to discuss the business of Crime Scene Investigation – a discipline not unlike bug investigation, with processes often used in software testing. We’ll talk about parallels and get some insight into what Crime Scene Investigation is really like, straight from the source.
Detective Stampfl will cover the following:
- The make-up of the Seattle Police Crime Scene Investigation’s Unit
- The type of crimes that they respond to investigate
- Steps necessary to properly document a crime scene
- The differences between the real world and how investigations are portrayed on television, and a current and look into the future of Forensic technology
Detective Brian Stampfl has been involved in law enforcement for over eighteen years. He began his career in 1991 in Southern California with the San Bernardino Police Department, and later joined the Seattle Police Department in 1995. Since joining SPD, Detective Stampfl has worked in patrol and was a field training officer, tasked with training new officers who had just graduated from the academy. Detective Stampfl went on to become an academy instructor and when the opportunity arose, he acquired the title of detective and worked for over three years in the Sexual Assault and Child Abuse Unit. Then in 2005, the opportunity of a lifetime presented itself as the Seattle Police Department sought to create its own Crime Scene Investigations Unit. Detective Stampfl was one of seven detectives chosen not only to staff this new unit, but to assist in the building of this unit from the ground up, which started simply as an idea. In addition to hours of training associated with Crime Scene Investigation, Detective Stampfl is a graduate of the National Forensic Academy in Knoxville, Tennessee and is an adjust faculty member of Seattle University where he teaches a course in Crime Scene Investigation.