CAST 2016

Whether you are Agile or Waterfall, you want testability. Whether you release periodically or continuously, you want testability. Testability means how easily a product can be tested. In other words, do bugs hide from you, lurking deep in the folds of your technology? Or do they run out and surrender when you come by, wearing bright reflective vests? Developers need to know this, not just to help the testing process, but to improve debugging, maintenance, and eliminate irreproducible bugs. And testers need to know this, in order to make the case to developers and management that testability creates speed and enables agility.

We will first consider the big picture: a revised version of the Agile Testing Quadrants that shows how testability is a core element. Then we will delve into the five major dimensions of testability: project-related, value-related, subjective, intrinsic, and epistemic. Finally, we will deal with how to assess the testability of a product.

Although we’d like to be able to say “yes”, there are times when saying “no” serves our projects, our teammates and our stakeholders best.

Testers can be subject to many conflicting or unreasonable demands. A manager may insist we work on several projects simultaneously, making it impossible for us to do good work on any of them. There may be enormous pressure to work long hours, which will jeopardize our health and the quality of our testing. Sometimes we’re expected to commit to something that we don’t know how to do. We can even find ourselves pressured to misrepresent our findings about the quality of the software.

Paradoxically, learning to say a good “no” enhances our ability to say a meaningful “yes”. If we can say “no” appropriately to demands we know to be wrong for us or for the project, then we can also say “yes” with whole-hearted commitment.

Saying “no” is not easy for anyone, but it is a skill that we can learn.

This half-day tutorial will consist primarily of experiential exercises and debriefs—as many as we have time for. Some volunteer participants will get to practice saying “no” to unreasonable demands. Everyone will have opportunities to observe the interactions, ask questions, discuss, and draw their own conclusions.

This session is intended for testing practitioners and managers at all levels of experience.

Learning Objectives
Why “no” can be a more positive answer than “yes” in certain contexts
How to recognize and resist the many tactics people can use to get us to say “yes”
How to say “no” when that is the right answer for us—simply, and with conviction, equilibrium and respect

During this talk, I will describe the three stages of development of Sonos' iPad application and the lessons we learned at each stage. These learnings helped us forge an environment that supports the creation and delivery of high quality products. Over the course of five years, Sonos has continually evolved our software organization to foster a culture where we all own quality. I will walk the audience through the initial development of our iPad application as well as two overhauls of the UI, explain the lessons we learned, and share the methods that work well for us in building high quality applications.

· Moving from an org where testers, developers, designers, product managers and others worked in isolated silos to working as a fully integrated team from the start
· Investing in key technical debt early on to enable future accelerated growth
· Finding the right balance between prototyping and user testing in order to code great experiences with the least number of iterations
· Clearly defining a project's desired outcome (and how to measure it)

Requirement engineering is an important part of the software development lifecycle. Gathering the right information so we can build the right system is critical for a project’s success. Regardless of how this information takes form, whether it comes in formal requirement specifications, user stories, or even just general ideas in a spreadsheet, ­this first step is the key to reducing bugs in our software and building better quality products. It has been estimated that almost 50% of bugs are the result of poorly written requirements.

How can we avoid bad requirements and reduce the number of bugs in our products? We can have testers involved early in the requirements process and ensure that requirements are written to be complete, consistent, and testable. Although there are lots of methods that will help remove bugs from requirements, I believe a human factor (and ideally a tester) is needed to really understand what the stakeholders are trying to communicate. Testers bring a different perspective and dynamic skill set that can be very valuable in requirement gathering. Testers can become active participants in the requirement process, and should advocate for well written and testable requirements. This session will explore why testers should be involved in the requirement process, how they can contribute, and the impact on quality this can have on a project.

What happens when you are brought into an organisation to build and teach testing only to find out you are the one needing the lesson?

This is a true story about how a tester with thirty years experience got taught the lesson of listening to your stakeholders by a group of developers.

The exercise was not only a lesson in learning to listen properly but it's helped me understand the importance of trust. In testing we talk a lot about reputation and credibility giving you a seat at the stakeholders table but without building trust we can lose that position very quickly.

What exactly is trust for testers? How can we go about building it?

Alpha Testing is typically defined as preliminary software field testing performed in order to find bugs that were not found previously through lab tests.

This definition understates the value of alpha testing, as my experience is that alpha testing can be successfully used very early in the software development cycle to quickly find the bugs that really matter: those with high impact to the customer.

My experience also shows that alpha testing can be used to find not just software functional issues, but hardware issues and issues in customer documentation and training as well.

Finally, my experience is that alpha testing can be used as a catalyst to build product knowledge throughout an organization, leading to the biggest benefit of all: a more successful product launch.

Professional development is important – everyone attending this conference knows that. What about those that aren’t attending conferences, reading books or following testing thought leaders online? Erik and Rob have had a variety of experiences working with those that are absolutely energized about their career and those that sometimes seem to only just want a job and nothing more. Over the past few months they have been exploring this topic in their own communities as well as through sessions at conferences.
 
There were a couple of questions they were curious about:

• How do we reach more testers
• How do we “sell” professional development
• Should we “sell” professional development

In this session they will reflect on some of their own experiences and successes. As well, report on some of the findings they have come across over the past few months. And hopefully, gather more insights from the attendees at this session. 

Attendee takeaways include:

• Reflection on promoting professional development
• Learn how others approach promoting professional development
• Discover ways to reach the testers who do their job but are not engaged in the community or do not show an interest in professional development
• Hopefully we will have provided attendees enough information as to draw their own conclusions as to whether professional development needs to be promoted

Fear of uncertainty is natural and human. Few of us would be happy not knowing when we or our loved ones could eat again, or whether bombs might drop on us tonight.

Yet some people joyously embrace particular uncertain situations, seeing opportunities to exercise and hone their skills. Others detest all uncertainty and seek to deny it or will it away.

Many managers discourage behaviour that exposes uncertainty. They don’t want to hear about risks, and they don’t like people asking too many questions. In their minds, exploration promotes uncertainty because it’s unpredictable and uncontrollable. They prefer absolutes:

• Immovable delivery dates and fixed costs

• Mandated “best practices” and controlled processes that (they believe) produce predictable results

• Hard numbers that purport to tell them exactly what’s going on

Good testers know that uncertainty is inescapable in software development (as in life), and it is better to embrace it on our projects than to run away from it. There are no best practices, and the only responsible answer is usually, “It depends.” It’s our job to expose uncertainty, and to help reduce it when possible.

But testers are not immune to human feelings. We also can fall into denial and too-easy answers.

In this interactive workshop, we’ll do group exercises and debriefs to tackle the questions:

• How can we grow our own tolerance for uncertainty and learn to embrace it?

• How can we promote a healthy attitude to uncertainty on our software projects?