As testers, we must wear many hats to do our job effectively. Quite often, it is the pith helmet of an explorer, hacking through the vines and darkness of the unknown; or the baseball cap of the crime scene investigator, determining how the failure occurred. To make things even more interesting, the hats we need often differ from project to project and organization to organization. Adam Goucher begins with a general discussion of some hats testers typically wear and when they are appropriate or inappropriate. He then leads an “Art Show” exercise-a brainstorming process resulting in lots of “art” on the walls-illustrating the hats we all may wear in our daily testing activities. Through the Art Show process, you'll take away new insights into what hats you and other testers need, tips for wearing the beautiful ones with success, and how to avoid putting on the ugly ones.
Who drives your career as a tester or test leader? Hopefully, not the company for which you work. It's you-you must be the driver. Because the craft of testing is still relatively free and open, there is no authority structure that defines or controls our industry. There are no generally accepted and standardized credentials that will admit you to the upper tier of income and respect as a tester. There are no universities that offer degrees in testing-although certificates and certifications abound. What we do have is a pastiche of communities, proprietary methodologies, schools of thought-together with ambitious individuals who write articles, teach, argue with each other, and speak at conferences.
Test-Driven Development (TDD) is the practice of writing a test before writing code that implements the tested behavior, thus finding defects earlier. Rob Myers explains the two basic types of TDD: the original unit-level approach used mostly by developers, and the agile-inspired Acceptance-Test Driven Development (ATDD) which involves the entire team. Rob has experienced various difficulties in adopting TDD: developers who don't spend a few extra moments to look for and clean up a new bit of code duplication; inexperienced coaches who confuse the developer-style TDD with the team ATDD; and waffling over the use of TDD, which limits its effectiveness. The resistance (overt or subtle) to these practices that can help developers' succeed is deeply rooted in our brains and our cultures.
With all the hype about agile, lean, CMMI®, and every other method du jour, we sometimes forget that our real goal is high performance. High-performance software teams consistently deliver products that delight their customers, all while remaining on schedule, keeping with agreed-to functionality, and maintaining high quality. These teams are proud of what they produce and are continuously improving the way they work. Over the past decade, Noopur Davis has worked with many high-performance teams in both large and small organizations. She has discovered that high-performance teams share a number of key practices, regardless of the process they use. Noopur shares these effective practices, including self-direction, openness and transparency, simplicity of work practices, focused use of data, an uncompromising commitment to quality, and others.
Turbulent weather such as tornados is characterized by chaotic, random, and often surprising and powerful pattern changes. Similarly, turbulent software projects are characterized by chaotic, seemingly random project changes that happen unexpectedly and with force. Dealing with turbulence is about dealing with change. Testing teams must contend with continuously changing project requirements, design, team members, business goals, technologies, and organizational structures. Test managers and leaders should not just react to change; instead, they need to learn how to read the warning signs of coming change and seek to discover the source of impending changes. Rob Sabourin shares his experiences organizing projects for testing in highly turbulent situations. Learn how to identify context drivers and establish active context listeners in your organization.
You've managed projects, but they're never easy. They don't fit into the nice definitions found in project management books. Your schedules are generally off. There are always unkind surprises. Although you're not failing, you feel you could be more successful. There is a solution. Based on her many years of consulting with large and small software teams, Johanna Rothman coaches leaders to take a more pragmatic approach. Employ mini-projects and iterations to explore alternative technologies. Use incremental steps to finish features one at a time when you don't know how far along you are. Make sure stakeholders agree on what "done" really means. Learn how to escape the dreaded trap of "multi-tasking," a management style that drains energy from everyone whenever there is a task switch. One final secret every project manager must discover: There is no "one right way" to manage a project.
You work in an organization with incredibly smart and diligent software engineers. Deadlines are tight and everyone is busy. But when developers outnumber testers by ten to one and the code base is growing exponentially, how do you continue to produce a quality product on time? Google addressed these problems by creating the Testing Grouplet—a group of volunteer engineers who dedicate their spare time to testing evangelism. They tried various ideas for reaching their audience. Weekly beer bashes were fun but too inefficient. New-engineer orientation classes, Tech Talks by industry luminaries, and yearly “Fixit” days became successful and continue to this day. But no idea caught the attention of engineers like Testing on the Toilet. This weekly flyer, posted in every Google bathroom, has sparked discussions, controversy, jokes, and parodies.
People forget things. Simple things like keys and passwords and the names of friends long ago. People forget more important things like passports and anniversaries and backing up data. But Lee Copeland is concerned with things that the testing community is forgetting—forgetting our beginnings, the grandfathers of formal testing and the contributions they made; forgetting organizational context, the reason we exist and where we fit in our company; forgetting to grow, to learn and practice the latest testing techniques; and forgetting process context, the reason that a process was first created but which may no longer exist. Join Lee for an explanation of the nine forgettings, the negative effects of each, and how we can use them to improve our testing, our organization, and ourselves.
Sandra Bourgeois has 25 years experience as an IT professional project manager, test manager, developer and QA lead. She is a Director and Project Manager at MassMutual
Financial Services in Springfield, Mass. For the past three years she has functioned as the senior IT Test Manager at MassMutual, working with a variety of large projects to
identify and resolve testing roadblocks to project implementation. She also serves as a project manager and teaches classes on testing topics, focusing on Performance
Testing. Most recently she has been the Performance Test Manager for several critical projects including Internet, Intranet and technical upgrades. She has presented at the
QAI International Conference. Her background also includes working as a social studies teacher and museum tour guide since graduating from Vassar College and UCLA.
Beta testing is an industry standard practice to obtain user feedback prior to general availability of software. Have you ever considered that the Beta release can be used to validate the software's value to customers and application users? Extending the Beta concept will result in higher customer satisfaction (and higher revenue for commercial products). Also, you can employ Beta testing to evaluate not only the software product, but the distribution (and sales) process, training, customer support, and usage within your customers' environments. Far beyond just finding defects in the product, you can focus Beta testing on how well the software is meeting your customers' needs. What does that mean to the Development team and the organization as a whole? What are the risks and challenges that we face? What are the rewards?