A good analyst or tester knows what questions to ask to quickly bring clarity to a murky subject. When they first hear about Acceptance Test-Driven Development (ATDD), a core practice on agile projects, their initial questions often are "Can examples really capture functional requirements?", "Where do user stories come from?", and "Will the analyst and tester roles become extinct?"

When Jennitta Andrea worked on her first agile project in 2000, she asked all of these questions and more. As a hands-on practitioner and keen observer of teams and processes on more than a dozen agile projects since then, Jennitta has discovered that success comes from knowing how ATDD fits within an ecosystem of roles, practices, and tools. Learn what Acceptance Test-Driven Development is, the critical success factors for ATDD, and the details of several key success factors.

Checklists are great. They have clear and quantifiable benefits in industries such as medicine and flying, and they are considered so important that their usage is part of the training in those industries. Software testers have also adopted checklists as a reliable artifact for documenting test cases and test results. Another approach is to use the checklist as a thinking tool and ask what we can do to enhance its usefulness given that premise.

In this talk, Adam challenges the first part of the word, "check", and promotes replacing it with "test" to better emphasize the use of the humble checklist as a linchpin for planning, organizing, performing and continually improving testing. Adam will describe the steps to to evolve the checklist into a testlist and beyond, to construct a testmap complete with useful information to aid the explorer-tester in providing quality data to product/program management and solution providers. Through examples of use on projects and in operations, Adam will highlight the role of the testlist/testmap in building continual improvement momentum after the first release to production, and how to use it to satisfy the needs of enterprise processes such as ITIL-oriented change and release management.

Approaches to test automation traditionally begin with the idea of automating existing scripts to emulate what users do with the product. Also, when testers are coding or scripting, it is often assumed they are doing this kind of work. But development work to support testing doesn't have to be so direct. "Automation" does not just have to be about tests - it can be about building tools and systems that enhance your powers in different ways. From robots to emulators to oracles, I will share a few of the non-traditional but creative ideas we have employed at SMART to make our testing lives more fun and effective.

In December we will be trying a new concept for SQDG - "Lightning Talks"! Lightning talks provide an excellent format for covering diverse topics and generating interesting discussion. Be sure to check out this unique format!

What is a "Lightning Talk"?
A lightning talk is a 5 minute talk given by a presenter on a specific topic. Since the time allotted is only 5 minutes, presenters are asked to present on a small slice of their chosen topic. The talk is timed and when the 5 minute period runs out, the presenter is asked to finish their sentence and the talk ends. Another 5 minutes is allocated for Q&A about the presentation. After the Q&A session has completed, another presenter is called and the same process starts again. Lightning Talks are widely used at peer conferences and workshops. SQDG is excited to offer this new format as part of the 2010/2011 season.

How many presenters will be presenting?
We expect to have 5 or 6 presentations within the 1 hour session.

Can I volunteer to present?
Absolutely! Please email the Programme Director with your Name, Topic and Title and we will add you to the list. The deadline to sign up for the December Lightning Talk session is November 19, 2010.

In IT, regardless of what we do, we need to be learning all the time. Many times it is only the application. Sometimes it is new methods and processes. Sometimes it is new ways to analyze, develop or test an application. It may be new languages or new tools. Perhaps most importantly, we learn different ways of dealing with people. Contractors learn new industries and how different businesses work in familiar industries. Janet Gregory and Sherry Heinze share ideas about how to approach this learning curve and the different influences which help us succeed.

Test framing is the set of logical connections that structure and inform a test. To test is to compose, edit, narrate, and justify two stories. One is a story about the product--what it does, how it does it, how it works, and how it might not work--in ways that matter to your clients. The other is a story about your testing--how you came to know and understand the product story. The testing story comprises several crucial elements--how you designed your tests, how you configured, operated, observed and evaluated the product, what you haven’t tested yet or won't test at all, why what you did was good enough, and what what you haven't done isn't so important. Of course, the story must be a true account of the testing work. To build the tests and the story expertly requires a skill that we call test framing.

Over several years of training and consulting, I have observed that many testers need help in one or more aspects of test framing--designing tests, evaluating the results, telling the testing story, or making the connection between the testing mission and the test performed, in an unbroken chain of narration, logic, and justification of cost versus value.

In this session, written in collaboration with James Bach, I present a structure for test framing. I identify the elements of test framing: a client; a product; a test agency (a tester or a test group, or a tool that extends them); a motivating question related to some risk; a design; a test procedure and; most importantly, a logical line of reasoning that connects them. Throughout, I emphasize test framing's role in fulfilling the testing mission; its importance in explaining testing to our clients; its power as a coaching framework; and its potential to help in preventing waste and other testing pathologies.

Key points of this session are:

• For testers, learn to construct and describe the chain of logic that informs and focuses your test.
• Learn how the skills of test framing can allow you to relate your testing story coherently.
• For managers and test leads, learn how to use test framing to debrief your testers and build skill.

Everyone knows great software needs to be tested, but how do you know for certain your role lines up with the roles of the rest of the team. For that matter, are you really sure what your boss wants you to do?

In this talk, Patti will introduce you to The Strategic Sense Inc™ E.A.T. model. This is a model that can be used in any aspect of leading self, team or task and lining it up with an understood end-goal. That's right, E.A.T. Expectation, Alignment and Transparency. In this talk you will learn why those three words are key to creating team synergy and leading from the middle. No, not from your stomach (as the acronym might imply) but from a role not typically considered a leadership position in our company. Walk away with a few effective tools in your tool belt for:

• Clarity of expectations
• Team alignment
• Knowing how far you have come
• Reaching your results!

With some handy tools for asking the right questions and building a strong plan, you might just find yourself on the same path as the rest of the team and then track the progress!

Many of us have crafted numbers and proudly reported them as valuable insight on product quality. The drive to quantify and justify our projects through metrics is pervasive. Many stakeholders crave metrics in the hopes of simplifying their decision making process. Many testers are quick to respond with extensive graphs and charts. However, there is a serious problem in attempting to articulate the state of the testing solely through metrics. How do you identify the "right" metrics? How do you ensure those metrics are sufficient, accurate and conclusive? This session will review the importance of moving beyond the numbers game, placing less emphasis on providing the "right" metrics and more emphasis on the contextual conversation metrics should be generating.

Not all organizations have software testing teams comprised of software testing professionals. When software testing teams do not exist, companies may not be in a position to bring in a large team of skilled software test professionals to fill this void. Often a single software tester is brought in to lead teams of business testers in software testing. Leading a group of highly knowledge business people who often aren’t experienced in software testing is not the same as leading a group of software testers. There are many challenges that even the strongest lead isn’t ready to deal with. Based on real life experience in leading business test teams, this presentation will discuss successes had at other organizations and look at approaches that could be applied in when leading business test teams.

Agile teams deliver "potentially" shippable software at the end of every iteration (one to four weeks), or even possibly every day. This goal can't be achieved without automated tests and many teams struggle with test automation.

By combining a collaborative team approach with appropriate tools and design approaches, over time you can not only automate your regression tests, but also use automation to enhance exploratory testing. Janet Gregory describes how to use automation early and guide development, what tests should be automated, and some that should not. Using examples, she will show how to design automated tests for maximum effectiveness and ease of maintenance.

The landscape of software project management has changed dramatically in the recent years as more businesses around the globe are digitizing their systems . However, it is disappointing to see that IT/Software projects today are often characterized by poor quality, schedule overruns and high costs. The latest Standish Group's "CHAOS Summary 2009" report says only 32% of all projects are delivered on time, within budget, with the required features and functions. So decision makers need an objective measurement framework to take suitable corrective actions for project success.

Prashanth believes without metrics project management can be a nebulous if not an impossible exercise. In this backdrop, based on the Goal/Question/Metric (GQM) model for software project measurement, Prashanth has come up with 8 measures related to Scope, Schedule, Maintenance, Cost and Quality and applied them successfully for a SAP Portal Applications project for a bank in Canada. Apart from providing vital information on the project performance, the metrics he used in this project also served as the basis for clear and objective communication with project stakeholders, promoted teamwork and improved team morale by linking efforts of individual team members with the overall objectives of the project.

This is our annual planning session where organizers, volunteers and participants, active or otherwise, get a chance to make their mark on next year's sessions. Everything is up for discussion. Bring your ideas and suggestions to make the SQDG an even better discussion group next year.