|
|
|
|
 |
| |
|
|
BT1 |
|
| Linda Rising, Independent Consultant |
|
It’s surprising how little of the research around incentives has made it into regular management practice. Widespread belief is that the debate is first about carrots vs. sticks and then about the kinds of carrots or sticks. Cognitive scientists, however, suggest that carrots result only in temporary compliance. Rewards, like punishment, are ineffective in producing lasting change. Numerous studies show that offering incentives is not only less effective than other strategies but often proves worse than doing nothing at all. Organizations seem to focus on the effects of variations in incentives and not on whether performance-based pay has a real effect on performance levels. Managers often use incentives instead of giving workers what they need to do a good job: treating workers well, providing useful feedback, offering social support, and allowing room for self-determination. Linda Rising describes surprising studies to show what truly works to bring out the best in people.
Learn more about Linda Rising
|
 |
BT2 |
|
| Donald (Mark) Haynes, Ajilon Consulting |
|
Would you tell your publisher to stop editing in the middle of your manuscript and publish your novel now? Of course not! Then, why would you tell your QA/test team to stop identifying problems with requirements documentation? All deliverables—and especially requirements—should undergo a rigorous assessment based on their quality attributes and measurable evaluation criteria. Mark Haynes describes quality models and attributes he has used to evaluate requirements documents. He shows how you can detect imprecision—that will haunt you later—and remove it with a set of formal criteria and informal heuristics. Discover how you can use quality attributes, even subjective ones, to conduct a quality dialogue within the development team. Mark shares examples of poorly written requirements for you to evaluate and try your hand at improving. Leave with a better understanding of the process Mark has used to ensure quality requirements—a key for successful systems development.
Learn more about Donald (Mark) Haynes
|
 |
BT3 |
|
| Timothy Fong, Done Partners |
|
Want to start a riot among developers? Just talk about implementing a metrics program! The reality is that for organizations working to improve their software development, metrics are more important than ever to justify investments and show progress. The central issue is what to measure and how to measure it. Timothy Fong begins with a business and project leadership perspective and then drills-down into how to develop and identify the core metrics you need for your development organization. Learn why not all metrics are the same—some are noise, some can cause unintended side effects, and some actually are valuable. Examine the tell-tale signs your metrics may not be providing what you need and identify steps you can take to make them more helpful. Timothy outlines three key metrics attributes—relevance, freshness, and action-ability—and demonstrates each with real-world examples. Implement or improve your development metrics for greater innovation, better leadership, and more predictable deliveries.
Learn more about Timothy Fong
|
 |
BT4 |
|
| Selena Delesie, Delesie Solutions |
|
Many testers mourn the state of their state—undervalued, unrespected, and often excluded from important project conversations. Even though their advice may be dismissed, many testers somehow believe that they are accountable for software quality. Why does this happen? Testers often forget that they are service providers whose role is to provide critical information to the project’s stakeholders. Selena Delesie explains why testing and test reporting should focus on business needs to add the most value and gain respect within the organization. Selena will help testers learn how to ask the right questions, draw out pertinent information, and understand the stakeholders “world view.” Explore key values required to be successful in transforming how the organization perceives testing. Discover communication techniques that will help testers connect with stakeholders and get them clamoring for more testing. Leave with real-world approaches for handling difficult conversations and project situations that will gain the respect of stakeholders.
Learn more about Selena Delesie
|
 |
BT5 |
|
| Debra Hansen, QA InfoTech |
|
Most development projects have executive stakeholders, but problems can arise when executives, even those who are politically savvy, are involved. Project horror stories abound about senior executives who changed priorities time after time. Some projects appear to be tossed like a political football between wary stakeholders who don’t want to take responsibility. In these situations, what started out as a mission-critical development effort can easily become a cancelled project or, worse, continued but with little or no corporate purpose or value. Debra Hansen shares her experiences working on both sides of the discussion—as an executive and a project manager—to help you understand life in the executive suite and how it shapes decision-making. Learn how to work with executives who won’t listen, the danger signals that you are losing executive support, and ways to survive feuds between executives that jeopardize your project. Take away specific strategies for working with executive stakeholders to improve your project’s chance of success—and keep your sanity.
Learn more about Debra Hansen
|
 |
BT6 |
|
Non-functional requirements present unique challenges for authors, reviewers, and testers. They often begin as vague concepts such as “The software must be easy to install” or “The software must be intuitive and respond quickly.” As written, these requirements are not testable because they are subjective. Definitions of “easy”, “intuitive” and “quickly” are open to interpretation and dependent on the experiences of the reader. In order to be testable, non-functional requirements must be quantifiable and measurable. John Terzakis discusses the subjectivity problems with non-functional requirements—weak words, ambiguity, and unbounded lists. To facilitate the development of quantifiable and testable non-functional requirements, he introduces a solution—Planguage—and its associated keywords. By documenting requirements-specific parameters—scale (unit of measure), meter (method to determine the position on a scale), and range of success—you can remove subjectivity and ambiguity so that non-functional requirements are expressed in quantifiable and testable terms.
Learn more about John Terzakis
|
 |
BT7 |
|
A project manager decides a product is good enough to release—that it will be successful in the marketplace or the business. The manager is basing this judgment on confidence in the product. Confidence is a simple word, yet it is an extraordinarily intangible measure. Confidence drives a huge number of software releases each day. Can our confidence be quantified? Can it be measured? Terry Morrish thinks so and shares a formula for measuring release confidence by combining measures from the current development cycle with those of the past releases and from client feedback. The Release Confidence metric can help predict the number of clients who will be affected by post-release problems and how much time and money will be spent on maintenance and rework. By employing this approach, project managers can have a quantitative picture of release risk, providing for a more informed decision process—and a better night’s sleep.
Learn more about Terry Morrish
|
 |
BT8 |
|
Software delivery schedules are getting shorter and shorter as companies attempt to deliver products to their customers at a blinding pace. A critical role for testers and testing in this crazy world is identifying defects before they ever get to testing. Mike Ennis identifies key defect prevention techniques—walkthroughs, inspections, and reviews—that your test team needs to begin using—today. Yes, we know that these static analysis techniques are old, dull, and may seem boring; however, they actually work! Join Mike to see how static analysis techniques, performed by testers, help them test faster and more effectively while at the same time identifying and eliminating defects earlier in development. Learn how the testing process can facilitate process improvement initiatives that not only will increase testers’ productivity, quality, and efficiency but also provide opportunities for their development counterparts to get better, too.
Learn more about Mike Ennis
|
 |
BT9 |
|
| Thomas Bento, Certified Compliance Solutions |
|
When challenged with designing and developing standards-compliant software using a risk-based approach, it is essential to understand regulatory law, industry best practices, and the consensus standards recognized by regulatory bodies (FDA, ISO, and the EU). Thomas Bento helps you sort through the challenges of regulatory expectations to move confidently and defensibly forward with risk-based development using consensus standards, including IEC 62304 and ISO 14971. Learn valuable ways to augment your existing software lifecycle processes with these standards, how the standards impact industry, how to demonstrate your process for compliance audits, and ultimately how to submit to the FDA with confidence. Apply critical thinking to determine the appropriate amount of rigor for software design and development with a risk-based approach that maps your context to the Processes, Activities, and Tasks required by the standard.
Learn more about Thomas Bento
|
 |
BT10 |
|
| Filip Szymanski, Hewlett-Packard |
|
While there is much excitement surrounding agile, many complex or outsourced projects do not fare well under agile. In these situations, requirements and architectural design cannot emerge with the software; they need to be defined and documented before coding starts. Filip Szymanski explores important practices in waterfall projects to help ensure requirements quality while speeding up development. First, Filip explains how to speed up waterfall releases by fully engaging QA/test teams in the requirements process. QA/testers can ensure that requirements are testable and validated throughout the release and further accelerate testing by writing requirements-based test cases in parallel with development. In addition, testers can begin test efforts sooner by automating application interfaces below the GUI. Then, Filip explores metrics—including test coverage of requirements, defect injection rate, and defect density—to track the requirements quality and release risk. Finally, Filip describes how linking requirements to code enables more accurate change impact analysis for better decision-making and more efficient testing.
Learn more about Filip Szymanski
|
 |
BT11 |
|
Have you heard any of these from your development staff or said them yourself? “Our software and systems are too fragile.” “Technical debt is killing us.” “We need more time to refactor.” Having quality code is great, but we should understand why it matters and specifically what is important to your situation. Joel Tosi begins by defining and discussing some common code metrics—code complexity, coverage, object distance, afferent/efferent coupling, and cohesion. From there, Joel takes you through an application with poor code metrics and shows how this application would be difficult to enhance and extend in the future. Joel wraps up with a discussion about what metrics are applicable for specific situations such as legacy applications, prototypes, and startups. You’ll come away from this class with a better understanding of code metrics and how to apply them pragmatically.
Learn more about Joel Tosi
|
 |
BT12 |
|
| John McConda, Moser Consulting |
|
John McConda presents the story of a test team that challenged the notion of best practices and came out more focused, efficient, and effective. Creating a mission statement and using it as a measuring stick, this team threw out all practices, started with a clean slate, and scrutinized every proposed process and practice. They sought to understand and evaluate each practice-based contribution to the testing mission. Examples: Test cases—don’t need them; Automated regression test suite—just enough, thanks; Performance testing—only with accurate operational modeling; CMMI®—just the parts that work for us. The result was a transformed team that began exceeding its goals and earned accolades from a previously unhappy customer. Along the way they learned plenty of lessons about making sure everyone’s voice is heard and how to implement sustainable change within a test team.
Learn more about John McConda
|
 |
Top of Page
|
|
|
 |
|
|
|
|
