|
|
|
|
|
 |
James Whittaker, Microsoft
As Microsoft’s only dual-role security and reliability
architect, James Whittaker is often asked to brief company executives on product
quality disasters and recommend remedies. With billion dollar warranty write-offs
at stake, such counsel is often sought, but the answers those executives receive
are rarely what they expect. James tells them that the ecosystem is sick. From academia
who train our new developers and testers, to tool vendors who manage only to delay
our suffering, to consultants who offer incremental process improvement (with largely
unnoticeable results), to our very own testing-oriented culture of last minute project
heroics—the system is broken. To fix it, James argues against three sacred
cows in software development—(1) A four year computer science degree is the
proper training for a software developer. (It’s not.), (2) Better processes
will produce better software, (Not by themselves.), and (3) The Herculean effort
testers expend at the end of a project makes them heroes. (It doesn’t.) Rather,
we need better ways to train our staff, we need to develop processes that actually
work, and we need to stop the late cycle heroics that are killing our schedules
and our people.
James A. Whittaker, now a Software Architect at
Microsoft, has spent his career in software testing. While a professor at Florida
Institute of Technology, he founded the world’s largest academic software
testing research center and helped make testing a degree track for undergraduates.
While at FIT he wrote How to Break Software, How to Break Software Security (with
Hugh Thompson), and How to Break Web Software (with Mike Andrews). Dr. Whittaker
currently works at Microsoft on the Trustworthy Computing Initiative in both security
and reliability, and directs the company’s methodology for security testing
as part of the Security Development Lifecycle (SDL). As owner of the reliability
pillar, James is responsible for understanding how software development practices
impact field reliability. |
|
|
|
|
|
|
|
Elisabeth Hendrickson, Quality Tree Software
One of the things testers often notice about Extreme Programming
(XP) is that there is no defined role for testers on the team. Yet XP teams describe
themselves as “test infected.” They practice Test-Driven Development
(TDD), writing executable unit tests before writing the code to be tested. Many
teams practice Acceptance Test-Driven Development (ATDD), writing executable acceptance
tests before implementing a feature. They use continuous integration to give them
rapid feedback about the effects of changes. They practice pair programming, a technique
that results in all code being peer reviewed before it’s checked in. In short,
XP teams test continuously from the very first moment of any given project. You
could even call them “test obsessed.” That obsession helps explain why
Elisabeth Hendrickson, author of www.testobsessed.com, likes XP teams so much. Elisabeth
has spent the last several years on a quest to discover how testers can contribute
effectively on Extreme Programming projects. Join Elisabeth as she shares her experiences
and the lessons she's learned about how testers can play well and succeed on XP
teams.
Elisabeth Hendrickson began working in the software
industry in 1984 and has held a variety of positions in companies ranging from a
twenty-person startup to a large multi-national software vendor. Elisabeth Hendrickson
founded Quality Tree Consulting in 1997 to provide training and consulting in software
quality and testing. Elisabeth is frequently invited to speak at conferences around
the world. In 2003, Elisabeth became involved with the agile community, became a
Certified Scrum Master, and in 2006, joined the board of directors of the Agile
Alliance. Today, Elisabeth splits her time between teaching, speaking, writing,
and working on Extreme Programming teams with test-infected programmers who value
her obsession with testing. |
|
|
|
|
|
|
|
Hugh Thompson, People Security
Hackers think differently, have strange goals, and will relentlessly
“test” your software for security bugs. Hugh Thompson exposes how attackers
view software to find security weaknesses and explains the economics of software
risk for organizations. He vividly illustrates the laws of hackernomics with real
vulnerabilities and helps you think like an attacker. Hugh takes you through crafting
input like an attacker would. He describes the features that attackers find most
attractive and why. Learn from Hugh how to prioritize a security bug and how to
explore the security implications of a functional bug. Gain a better understanding
of where the biggest risks in your software might be hiding and be better armed
to test for those weaknesses. Warning—there will be live exploits. Software
will be harmed during this presentation!
An expert on application security and testing, Herbert (Hugh)
Thompson is Chief Security Strategist at People Security (www.peoplesecurity.com).
He has co-authored several books on the topic and has written more than eighty academic
and industrial publications on security. In 2006 he was named one of the “Top
5 Most Influential Thinkers in IT Security” by SC Magazine and was featured
(along with Harri Hursti) in “Hacking Democracy,” the Emmy-nominated
HBO documentary on e-voting vulnerabilities. On AT&T’s tech channel (techchannel.att.com),
he currently hosts “The Hugh Thompson Show,” which features industry
luminaries in IT security. Hugh earned his Ph.D. in Applied Mathematics from Florida
Institute of Technology where he remains on the graduate faculty. |
|
|
|
|
|
|
|
Bharat Mediratta and Antoine Picard, Google
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
restroom, has sparked discussions, controversy, jokes, and parodies. More importantly,
it has taught everyone about techniques such as code coverage, dependency injection,
mock objects, and testing time-dependent code. Learn the story of its development—from
a deceptively simple idea to a company-wide cultural phenomenon that has received
national acclaim. Perhaps Testing on the Toilet can bring better testing to your
organization.
Bharat Mediratta is the Technical Lead of the Google
Web Server (GWS) team and co-founder of the Testing Grouplet. Bharat has been a
tireless advocate of developer testing both in GWS and Google as a whole. Thanks
to his efforts, GWS has increased its number of unit tests by an order of magnitude
and raised its code coverage by 50% while cutting the number of emergency pushes
in half. His team's success has become the benchmark by which other teams measure
their developer testing progress.
Antoine Picard is the Technical Lead of the unit testing team.
Antoine's team is responsible for providing Google's developers with the tools they
need to write unit tests and with fast and accurate test results at every change
list. Antoine authored the first-ever edition of Testing on the Toilet and is now
one of a handful of regular contributors.
|
|
|
|
|
|
|
|
John Fodeh, Hewlett-Packard
When developing software systems, the inevitable question is
“Are we ready to ship?” Facing this question, many testers and test
managers rely on their intuition and gut feeling to come up with a subjective verdict
of the system under test. John Fodeh describes how to establish and use a set of
Release Readiness Metrics in your organization. These metrics provide a snapshot
of the system state and quality that you can use throughout the development process—especially
when approaching the release date. John takes a closer look at these metrics and
examines the role of testing and testers as “information providers.”
John demonstrates different release-related metrics, including a model for predicting
how many defects remain in the system after release. Using a real-life example,
you’re invited to take part in role-play where you are presented with a set
of metrics and then must decide whether or not the system under test is ready to
ship. Learn from John how you can use metrics to enhance your gut feeling and to
improve the quality of the information you provide.
A consultant at Hewlett-Packard, John Fodeh has several
years of experience in the field of software testing, quality management, and process
improvement. He has been a key person in a Software Process Improvement (SPI) project
establishing a metrics program to support the release decision basis. John is an
active member of a Danish special interest group in software testing. He has given
presentations at a number of seminars and conferences including STAREAST, STARWEST,
EuroSPI, EuroSTAR, and at the BCS' SIGIST. John holds a MSc. from the Technical
University of Denmark and a Practitioner certificate in software testing. |
|
|
|
|
|
|
|
Tom Wissink, Lockheed Martin
Whether we develop software-based systems to create invoices,
solve difficult physics problems, diagnose heart disease, or launch rockets, we’ve
learned that nothing stays the same very long and software defects are inevitable.
However, one thing has remained constant—the role and value of testing has
been misunderstood by many in senior management. A Lockheed Martin Fellow since
2005, Tom Wissink describes steps undertaken at Lockheed Martin to change this culture
of misunderstanding into a culture of appreciation, satisfaction, and excitement.
Tom’s experience has convinced him that this change is not just theoretical
but both possible and rewarding. In a few organizations, both large and small, this
has resulted in dramatic changes including greater tester satisfaction, increased
company profits, and improved software quality often delivered on time and within
budget. Tom’s transformational steps—using robust test design techniques,
practicing exploratory testing, developing and conducting regular test training,
and developing a return on investment (ROI) model for test automation in your environment—are
defined such that test organizations and individuals can begin to implement them
now. Tom describes a complete set of steps together with specific examples of implementation
successes.
Tom Wissink has worked in software development,
software configuration management, integration and test (I&T), and at several
levels of management for more than thirty years. As an I&T Engineering Fellow
at Lockheed Martin (LM), he is responsible for identifying and incorporating I&T
best practices throughout the company. Tom has worked on the Space Shuttle, several
Satellite Command and Control Centers, the Global Positioning System, and the Hubble
Telescope, to name a few. In his role as LM Fellow, Tom provides I&T guidance,
direction, support, assessments, and training across all of LM. |
|
|
|
|
|
