The basic problem in software testing is choosing a subset from the near infinite number of possible test cases. Testers must select test cases to design, create, and then execute. Often, test resources are limited-but you still want to select the best possible set of tests. Peter M. Kruse and Magdalena Luniak share their experiences designing test cases with the Classification-Tree Editor (CTE XL), the most popular tool for systematic black-box test case design of classification tree-based tests. Peter and Magdalena show how to integrate weighting factors into classification trees and automatically obtain prioritized test suites. In addition to “classical” approaches such as minimal combination and pair-wise, they share new generation rules and demonstrate the upcoming version of CTE XL that supports prioritization by occurrence probability, error probability, or risk.
Peter Kruse, Berner & Mattner Systemtechnik GmbH
This session is a deeper examination of how to apply dashboards in software testing.I spent several months on a project primarily building a software testing dashboard. I have learned some interesting things, including:
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.
Mistakes happen. It's how you respond to them that matters. Teams might react to a bug with panic and blame, leading to a quickly hacked fix and possibly more issues. Taking time to investigate and learn leverages problems into process and practice improvement and a higher quality product.
Many practitioners see becoming a consultant as their ultimate career goal. But what does it mean to be "a consultant"? In this email to an aspiring consultant, Fiona Charles (a consultant for more than fifteen years) discusses different consulting approaches and describes how working for a consulting firm can help you get there.
Rewards can be powerful management tools, but only if you implement them effectively. In this installment of the Management Chronicles, discover how the right timing and getting to know your employees better can improve the impact of your recognition method.
Development teams often are unaware of the commercial impacts of the software improvements they deliver. Often, the prioritization of work is done based on technical, rather than commercial, considerations. Based on a real-world example, this story explores the commercial benefits enabled by delivering in short release cycles and prioritizing according to bottom-line benefits.
Allowing an individual to hold a project hostage to his knowledge and expertise is bad for the project and for the team. Fiona Charles describes one captive project and shows how it could have been remedied.
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.