Software testing flight plan for learning and networking event

ig Ht PL an
so ft wa re te st ing fL
of lea rn ing ,
September 30– Ch oo se fro m a ful l we ek
ne tw ork ing , an d mo re
October 5, 2012 su nday
sse s an d
Mu lti -da y tr ain ing Cla
Anaheim, CA Bo nu s se ssi on s be gin
Disneyland Hotel Mo nday –t ue sday
ful l-d ay
31 in- de pth ha lf- an d
tu tor ial s
ay
we dn es day– tH ur sd
5 Ke yn ote s, 42 Co nc ur ren t
tw ork ing
RegisteR by August 3, 2012 se ssi on s, the eX Po , ne
ev en ts, re cep tio ns , Bo nu s
A N D s AV e u P t O $ 4 0 0 se ssi on s, an d mo re
gROuPs Of 3 sAVe eVeN mORe! fr iday
hip summit
testing & Quality Leaders
so ftw are
wo rk sh op on re gu lat ed
te sti ng (w re st )

www.sqe.com/starwest

May/June 2012 $9.95 www.TechWell.com

MAYDAY! MAYDAY!
Projects in peril

THE NEED FOR SPEED
Testing at the
speed of mobile

Visual Studio
isn’t just for
developers.
For a limited time, you can save 20%
on Visual Studio Test Professional 2010
with MSDN.

Testing Tools.
Visual Studio Test Professional 2010 with MSDN
is packed with integrated testing features like test
case management, manual test execution, manual
test record and playback, and lab management
conﬁguration to ensure the delivery of quality
code every time.

Integrated ALM tools.
Collaborate and communicate effectively at every
level, and gain visibility into real project status to
ensure the delivery of high-quality solutions while
reducing costs.

Everything you need with MSDN.
An MSDN subscription provides a comprehensive
set of resources including development and test
licenses, plus training, support, and access to
critical information for developing on the
Microsoft platform.

Find out how you can save
today on Visual Studio
with MSDN at:
www.microsoft.com/visualstudio/save/en-us

fall 2012 Schedule
San Jose, CA August 21–23 Austin, TX October 16–18
Boston, MA August 21–23 Tampa, FL October 22–24 Earn up to 37.5 PDUs
Charlotte, NC August 28–30 Chicago, IL October 23–25
Minneapolis, MN September 11–13 Bethesda, MD Oct. 29–Nov. 2 Become a certified software tester and...
(Advanced Testing Training Week)
Santa Fe, NM September 11–13
Philadelphia, PA Oct. 30–Nov. 1
• Increase your value in both your organization and
Washington, D.C. September 17–19 the industry
Raleigh, NC Oct. 30–Nov. 1
Atlanta, GA September 25–27
Bethesda, MD Oct. 30–Nov. 1
• Stand out from your peers with your professional
Toronto, ON September 25–27 certification
Orlando, FL November 4–6
Anaheim, CA September 30–Oct. 2
• Demonstrate you have the knowledge and skills
San Francisco, CA November 12–14
St. Louis, MO October 9–11 needed for your everyday software testing challenges
Vancouver, BC November 13–15
Pittsburgh, PA October 9–11
• Benefit from the most widely recognized and fastest
Phoenix, AZ December 4–6
Portland, OR October 9–11 growing software tester certification in the world
NY/NJ Area October 16–18

www.sqetraining.com/certification SQE TRAINING

Three time zones, one solution

Application Lifecycle Management with Industry Leading Performance and Scalability

• First Ever With Built-in Multi-site Support
• Native iPad and Android Tablet Applications
• Full Traceability Through:
- Portfolio
- Requirements
- Development
- QA Testing

Volume 14, Issue 3 • May/June 2012
22

C ON T ENTS
features
18 COVER STORY
Traditional Test Engineering, Your
Days Are Numbered Turning Software Quality
on Its Head, Part 2
In the first installment of this article, Dr. James Whittaker discussed revital-
izing and improving the value of late-stage testing. James also discussed
ideas behind empowering your dogfooders, testers, and the crowd to sig-
nificantly and efficiently improve software quality. In part two, Jason Arbon
discusses the research and engineering experimentation behind realizing
these ideas into new tools and processes.
by Jason Arbon
18
22 AGILE CODE FOR AGILE TEAMS
What makes a team agile? Is it in the way it plans projects, or how it engi-
neers its products? In this article, Steve Berczuk explains how agile code and
technical practices can help a team stay agile across the product lifecycle.
by Steve Berczuk

26 SELECTING THE RIGHT MOBILE TESTING SOLUTION
The mobile market dynamics are extreme, unpredictable, and fragmented.
There are numerous operating systems and a multitude of platform versions,
networks, hardware, and form factors making it a challenge to maintain mo-
bile application quality. Find out how to adjust to the shift from traditional to
mobile development—which additional elements are a must and which ones
26 can be maintained.
by Yoram Mizrachi
in every issue
Mark Your Calendar 4
columns
Contributors 7 11 TECHNICALLY SPEAKING
CONTROLLED FLIGHT INTO TERRAIN • by Lee Copeland
Editor's Note 9 Entering a holding pattern on a project can give you the opportunity to gather
Virtual Resource Shelf 16 additional information about a problem. But, sometimes, holding consumes
valuable resources with disastrous consequences.
From One Expert
to Another 17
14 MANAGEMENT CHRONICLES
Product THE MYTH OF 100% UTILIZATION • by Johanna Rothman
Announcements 32 Too many managers believe in the myth of 100% utilization—the belief that
FAQ 34 every single technical person must be fully utilized every single minute of
every single day. This leaves no time for innovation, no time for serendipi-
Ad Index 36 tous thinking, no time for exploration, and it often leads to a less successful
Better Software magazine—The print organization.
companion to TechWell.com brings you the
hands-on, knowledge-building information
you need to run smarter projects and deliver 35 CAREER DEVELOPMENT
better products that win in the marketplace
and positively affect the bottom line. LEVERAGE REVERSE MENTORING TO POSITIVELY IMPACT YOUR
Subscribe today to get six issues. ORGANIZATION • by Mukesh Sharma
Visit www.BetterSoftware.com
Introducing a reverse mentoring program provides both employees and
or call 800.450.7854. managers benefits beyond simply learning a new technology or skill. Find out
how to introduce a reverse mentoring program in your organization.

www.TechWell.com
MAY/JUNE 2012 BETTER SOFTWARE 3

MARK YOUR CALENDAR
SQE TRAINING software tester
certification
training weeks www.sqetraining.com/certification
Publisher
www.sqetraining.com/trainingweek June 4–6, 2012 Software Quality Engineering, Inc.
Chicago, IL
Testing Training Weeks President/CEO
June 4–8, 2012 June 10–12, 2012
Chicago, IL Wayne Middleton
Las Vegas, NV
Vice President of Communications
September 17–21, 2012 June 19–21, 2012
Washington, DC Tampa, FL Heather Buckman

October 22–26, 2012 Editor in Chief
August 21–23, 2012
Tampa, FL Boston, MA Heather Shanholtzer
San Jose, CA
November 12–16, 2012 Editorial
San Francisco, CA August 28–30, 2012
Charlotte, NC Managing Technical Editor
Agile Software Development Training Lee Copeland
June 10–12, 2012 September 11–13, 2012
Las Vegas, NV Minneapolis, MN Online Editors
Santa Fe, NM Joseph McAllister
Jonathan Vanian
September 17–19, 2012
Washington, DC Community Manager
David DeWald

Production Coordinator
Cheryl M. Burke

conferences
Design

Creative Director
Better Software Conference West Better Software Conference East Catherine J. Clinger
www.sqe.com/BetterSoftwareWest www.sqe.com/BetterSoftwareEast
June 10–15, 2012 November 4–9, 2012 Advertising
Caesars Palace Rosen Shingle Creek
Las Vegas, NV Orlando, FL Sales Consultants
Daryll Paiva
Agile Development Conference West Agile Development Conference East
www.sqe.com/AgileDevelopmentWest www.sqe.com/AgileDevelopmentEast Kim Trott
June 10–15, 2012 November 4–9, 2012
Production Coordinator
Caesars Palace Rosen Shingle Creek
Las Vegas, NV Orlando, FL Desiree Khouri

STARWEST 2012 STAREAST 2013
www.sqe.com/starwest www.sqe.com/stareast
September 30–October 5, 2012 April 28–May 3, 2013
Disneyland Hotel Rosen Shingle Creek CONTACT US
Anaheim, CA Orlando, FL Editors: editors@bettersoftware.com
Subscriber Services:
info@bettersoftware.com
Phone: 904.278.0524, 888.268.8770
Fax: 904.278.4380
Address:
Better Software magazine
Software Quality Engineering, Inc.
340 Corporate Way, Suite 300
Orange Park, FL 32073

4 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com

Level up your productivity
– Upgrade to Hansoft
Simplifying program management and day to
day lean, agile and Gantt scheduling development.
27, at
y our booth # ence
Come b tware Confer
of
Better S

Download a free 2-user trial at www.hansoft.se

Test Studio
Easily record automated tests for
your modern HTML5 apps

Test the reliability of your rich, interactive JavaScript apps with just a few
clicks. Benefit from built-in translators for the new HTML5 controls, cross-
browser support, JavaScript event handling, and codeless test automation
of multimedia elements.

www.telerik.com/html5-testing

Contributors

Jason Arbon is currently engineering director at uTest.com, focusing on mobile and analytics. Jason has held test leadership and
innovation roles at Google—on Google+, Chrome Browser, Chrome OS, Google Desktop, and Google Talk. He also worked on
teams at Microsoft, including Bing (Search relevance and QnA), WinFS, BizTalk Server, MSN, Windows CE, and Exchange Server.
Jason is the coauthor (with James Whittaker) of How Google Tests Software.

Steve Berczuk is an engineer and ScrumMaster at Humedica, where he's helping to build next-generation SaaS-based clinical
informatics applications. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration,
Steve is a recognized expert in software configuration management and agile software development. He is passionate about
helping teams work effectively to produce quality software. Contact Steve at steve@berczuk.com, visit berczuk.com, and follow
his blog at steveberczuk.blogspot.com.

With more than thirty years of experience, Lee Copeland has worked as a programmer, development director, process improvement
leader, and consultant. Based on his experience, Lee has developed and taught a number of training courses and is the managing
technical editor for Better Software magazine, a regular columnist for StickyMinds.com, and the author of A Practitioner's Guide
to Software Test Design. Contact Lee at lcopeland@sqe.com.

Janet Gregory specializes in helping teams build quality systems. As tester or coach, Janet has helped introduce agile develop-
ment practices into companies and has successfully transitioned several traditional test teams into the agile world. She is a
frequent speaker at agile and software testing conferences in North America, including the STAR testing conferences.

Jonathan Kohl is an internationally recognized consultant and technical leader. Based in Calgary, Alberta, Canada, he is the
founder and principal software consultant of Kohl Concepts, Inc. Jonathan helps companies define and implement their ideas
into products, coaches practitioners as they develop software on teams, and works with leaders helping them define and imple-
ment their strategic vision. He is also a popular author and speaker. Read more of Jonathan’s work at www.kohl.ca or contact
him at jonathan@kohl.ca.

Yoram Mizrachi is a mobility veteran with a wealth of experience in mobile quality, networking, security, and telecommunications.
Yoram founded Perfecto Mobile after serving as the CTO of Comverse Mobile Data Division. He was the CTO and founder of
Exalink, which was later acquired by Comverse. Prior to founding Exalink, Yoram held several technology-related positions in the
fields of communication and cryptography.

Management consultant Johanna Rothman is a regular StickyMinds.com and Better Software magazine columnist. She is the
author of Manage It! Your Guide to Modern Pragmatic Project Management—winner of the 2008 Jolt Productivity Award—as
well as coauthor of Behind Closed Doors and author of Hiring the Best Knowledge Workers, Techies & Nerds. Johanna is a host
of the Amplifying Your Effectiveness Conference and has presented at numerous conferences. You can reach her at
jr@jrothman.com or by visiting www.jrothman.com.

Founder and CEO of QA InfoTech, Mukesh Sharma leads the organization's worldwide operations, marketing, sales, and develop-
ment efforts, and is responsible for the company's vision. He founded QA InfoTech with a vision to provide unbiased QA testing
solutions and has grown the organization to five Centers of Excellence, hundreds of employees, and more than $10 million in
annual revenue. Mukesh can be reached at mukesh@qainfotech.net.

www.TechWell.com BETTER SOFTWARE
MAY/JUNE 2012 7

Editor’s Note

Holding Pattern
What do you do when you are stuck trying to decide the best course of
action on a project that just went terribly wrong? Do you forge on, because
you are the “some action is better than inaction” type, or do you step back,
take a deep breath, and wait for a message from the project gods to guide your
next move?

There is no right answer. And there is no guarantee that one approach will yield the same results the next
time. Lee Copeland’s Technically Speaking column, “Controlled Flight into Terrain,” has two examples of cases
where entering into a holding pattern had drastically different outcomes. Your project crisis might not be as
safety critical as the examples in Lee’s article, but the lesson is a valuable one that everyone can heed.

Also in this issue, Jason Arbon continues to turn quality upside down in his article “Traditional Test Engineer-
ing, Your Days Are Numbered.” Jason picks up where James Whittaker left off in the last issue and discusses
the research and engineering required to turn the ideas in part one into new tools and processes.

For the managers, Johanna Rothman sheds some light on “The Myth of 100% Utilization.” Think you have to
keep team members completely occupied all day, every day to get your money’s worth? You might actually be
hurting productivity.

Steve Berczuk’s “Agile Code for Agile Teams” explains how agile code and technical practices can be lever-
aged throughout the product lifecycle to keep your team agile.

As always, I hope you enjoy this issue of Better Software magazine. Send me an email to let me know how
you’ve put the ideas to work on your latest projects.

Happy reading,

hshanholtzer@sqe.com

www.TechWell.com

Technically Speaking

Controlled Flight into Terrain
Entering a holding pattern on a project sometimes buys you time to figure
things out. Other times, it buys you a crash landing.
by Lee Copeland | lcopeland@sqe.com
Just for fun, I often browse the shelves of the local university Denver, CO for Portland, OR with 189 persons on board. Ap-
library looking for something that catches my eye. Recently, proaching Portland, the first officer, who was flying the air-
an interesting book jumped off the shelf and into my hands craft, requested the wing flaps be extended to fifteen degrees
(perhaps its bright pink and orange cover helped). Controlling and the landing gear lowered. The captain complied with both
Pilot Error: Controlled Flight Into Terrain by Daryl Smith is requests. As the landing gear was lowered, both pilots heard
about poor decisions made by pilots under extreme pressure. a loud noise and felt a severe jolt. The aircraft yawed to the
After reading “A controlled flight into terrain (CFIT) is an right. However, the “nose gear down” light was green. The
accident in which an otherwise serviceable aircraft, under the crew put the plane into a holding pattern over the ocean, and
control of the crew, is flown unintentionally into terrain, ob- for the next twenty-three minutes, the flight crew discussed
stacles, or water, with no prior awareness on the part of the and performed emergency and precautionary procedures to as-
crew of the impending collision,” it occurred to me that if you sure that all landing gear were locked in the full down posi-
substitute “serviceable project” for “serviceable aircraft,” you tion. The aircraft continued to circle within twenty miles of the
have a description of many software airport. Thirty-four minutes after
project disasters. the “jolt,” the first officer asked the
Consider this example: “We were
“…if you substitute flight engineer, “How much fuel we
preparing for the approach at Belize got?” He responded, “Five thou-
City. Small thunderstorms were in ‘serviceable project’ for sand [pounds].” The first officer
the area. There was no moon, no acknowledged his response. Mean-
approach lighting system, and no ‘serviceable aircraft,’ you have while, the flight crew continued to
visual approach slope indicator due have discussions about the landing
to an outage on the ground. There a description of many software gear. Four minutes later, the captain
were no surrounding lights and it asked how much fuel they would
was very dark. At 5 miles inbound project disasters.” have left after fifteen more minutes
rain started falling heavily. We had of holding. The flight engineer re-
the runway in sight … We were at 350 ft. Suddenly we were sponded, “Not enough, fifteen minutes is gonna really run us
at 240 ft. We saw that we were low and both the captain and I low on fuel here.”
pushed the power up to max. As the aircraft accelerated we felt Sixteen minutes later, the first officer told the captain,
an impact and a loud thump. The lighting was so poor at Belize “We’re going to lose an engine.” The captain replied, “Why?”
that we decided not to make another approach so we diverted The first officer replied, “Fuel.” The captain repeated his ques-
to Merida. Immediately after our landing and parking at the tion, and the first officer repeated his answer. Finally, sixty-one
gate, we conducted a post-flight inspection. We saw a leading minutes after the indication of a potential problem, the first of-
edge wing slat dented from a tree strike and tree branches stuck ficer called Portland Tower, “United 173 heavy, Mayday. We’re
in the landing gear.” … the engines are flaming out. We’re going down. We’re not
These pilots felt strong pressures to land: the importance of going to be able to make the airport.” The plane ran out of fuel
doing their job, meeting their commitments, and not seeming and crashed, killing ten and injuring twenty-four people.
to be incompetent. However, when the situation deteriorated, While entering a holding pattern can allow us to gather
they had another option—they could have entered a holding additional project information, we must remember that we
pattern. Often just waiting a few minutes can allow uncertain- cannot hold forever. Holding consumes valuable resources.
ties to clear. Sometimes we need to do that with our projects— When dealing with a problem, don’t allow your attention to
wait for a while until additional information becomes avail- be so channeled that it pushes other concerns aside. In this ex-
able. Generally, executing “the plan” is not more important ample, at no time did any of the crew translate “pounds of fuel
than your organization’s success. You can always do a mental remaining” into “minutes of flying remaining.” Make someone
cost-benefit analysis. What’s the cost if you wait? What’s the responsible to call out the project’s vital signs. Remember, you
benefit of pressing on? What’s the cost if you fail? have the ethical responsibility to speak up. Vague hints about
Here’s another example, this one with tragic consequences. project status don’t always get the job done. Your job is to keep
On December 28, 1978, United Airlines flight 173 departed the main thing the main thing. {end}

www.TechWell.com

rEchargE your TEam and ElEcTrify your car
B
OM IN

C

E
Training WeeK The more training you take
N the greater the savings!

A
D SAV

E
Maximize the impact of your training by combining
courses in the same location. Combine a full week of
training for the largest discount!

2012 September 17–21, 2012
fall schEdulE Washington, DC
October 22–26, 2012
Tampa, FL
TESTING
TraINING November 12–16, 2012
wEEkS San Francisco, CA

WashingTon, D.c. Training WeeK Indicates courses
september 17–21, 2012 pre-approved for PMI PDUs

MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY

Software Tester Certification—Foundation Level Mastering Test Design

Test Estimation and Just-In-Time Software
Agile Testing Practices Testing Under Pressure
Measurement Testing Workshop

Risk-Driven Software Testing Testing with Use Cases Performance, Load, and Stress Testing Workshop

Essential Test Management and Planning Leadership for Test Managers Test Process Improvement

Mobile Application Testing

ways to save Take advantage of the different “Ways to Save” on training using our discount programs
listed below. Purchase valuable software quality training for your whole team and save.

B B
OM IN OM IN
Early
C
C

E
E

Training WeeK conference
Bird N N
A
A

D SAV D SAV
E
E

Register 6 weeks prior Combine specialized Have a group and want Bring any course Save $300 when you
for any training week training courses in to save more? Get to your location for combine any our our
course and receive the same location details on our discount team training. On-site pre-conference training
$50 off per registered and save. Discounts policy by contacting our training is both courses with your
course day. Take a full vary depending on the Client Support Group. cost-effective and conference registration.
week of training and amount of training days convenient for your
save $250! combined. team of six or more.
See page 6 for
more details.

For more details on our discount policy, contact the Client Support Group at sqeinfo@sqe.com or call 888.268.8770 or 904.278.0524.

rEEr WiTh TEsTing Training from sQE Training
TamPa Training WeeK Indicates courses
october 22–26, 2012 pre-approved for PMI PDUs




Systematic Software Testing Performance, Load, and Stress Testing Workshop

Essential Test Management and Planning Leadership for Test Managers Mobile Application Testing

Test Process Improvement

san francisco Training WeeK Indicates courses
november 12–16, 2012 pre-approved for PMI PDUs




Risk-Driven Software Testing Testing with Use Cases Performance, Load, and Stress Testing Workshop

Essential Test Management and Planning Leadership for Test Managers Mobile Application Testing

Finding Ambiguities in
Writing Testable Requirements Requirements-Based Testing
Requirements

LEarNING OpTIONS:

Public
eLearning

Instructor-led training in Live, instructor-led Self-paced Instructor-led training
a city near you classes via your computer learning, online at your location

for information on our 60+ Public
and 40+ Live Virtual course Dates
visit www.sqetraining.com
SQE TRAINING
www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 13

Management Chronicles

The Myth of 100% Utilization
The problem with the myth of 100% utilization is that it often leads to a
less successful organization.
by Johanna Rothman | jr@jrothman.com
A manager took me aside at a recent engagement. “You know, committed on another project. You can’t get together for a
Johanna, there’s something I just don’t understand about this meeting. You can’t have a phone call. You can’t even respond
agile thing. It sure doesn’t look like everyone is being used at to email in a reasonable time. Why? Because you’re late re-
100 percent.” sponding to the other interrupts.
“And what if they aren’t being used at 100 percent? Is that
a problem for you?” How Did We Get Here?
“Heck, yes. I’m paying their “Because we are human, we are Back in the early days of com-
salaries! I want to know I’m getting puting, machines were orders of
their full value for what I’m paying
them!”
unable to perfectly write out magnitude more expensive than1. In
grammers, as shown in figure
pro-

“What if I told you you were the 1970s, when I started working
probably getting more value than what’s in our memory, and we as a developer, companies could pay
what you were paying, maybe one highly experienced programmers
and a half to twice as much? Would imperfectly swap back in.” about $50,000 per year. You could
you be happy with that?” pay those of us just out of school
The manager calmed down, then turned to me and said, less than $15,000 per year, and we thought we were making
“How do you know?” huge sums of money. In contrast, companies either rented ma-
I smiled, and said, “That’s a different conversation.” chines for many multiples of tens of thousands of dollars per
Too many managers believe in the myth of 100 percent utili- year or bought them for millions. You can see that the scales of
zation. That’s the belief that every single technical person must salaries to machine cost are not even close to equivalent.
be fully utilized every single minute of every single day. The When computers were that expensive, we utilized every
problem with this myth is that there is no time for innovation, second of machine time. We signed up for computer time. We
no time for serendipitous thinking, no time for exploration. desk-checked our work. We held design reviews and code re-
And, worse, there’s gridlock. With 100 percent utilization, views. We received minutes of computer time—yes, our jobs were
the very people you need on one project are already partially often restricted to a minute of CPU time. If you wanted more
time, you signed up for after-hours time, such as 2 a.m. to 4 a.m.
Realize that computer time was not the only expensive
part of computing. Memory was expensive. Back in these old
days, we had 256 bytes of memory and programmed in as-
sembly language code. We had one page of code. If you had
a routine that was longer than one page, you branched at the
end of a page to another page that had room that you had to
swap in. (Yes, often by hand. And, no, I am not nostalgic for
the old days at all!)
In the late ‘70s and the ‘80s, minicomputers helped bring
the money scales of pay and computer price closer. But it
wasn’t until minicomputers really came down in price and
PCs started to dominate the market that the price of a de-
veloper became so much more expensive than the price of a
computer. By then, many people thought it was cheaper for a
developer to spend time one-on-one with the computer, not in
design reviews or in code reviews, or discussing the architec-
ture with others.
In the ‘90s, even as the prices of computers, disks, and
memory fell, and as programmers and testers became more
Figure 1
expensive, it was clear to some of us that software develop-


Management Chronicles

ment was more collaborative than just a developer one on Now, let me address the not-thinking part of 100 percent
one with his computer. That’s why Watts Humphrey and the utilization. What if you want people to consider working in
Software Engineering Institute gained such traction during a new way? If you have them working at 100 percent utili-
the ‘90s. Not because people liked heavyweight processes, zation, will they? Not a chance. They can’t consider it; they
but because, especially with a serial lifecycle, you had to do have no time.
something to make system development more successful. So you get people performing their jobs by rote, servicing
And, many managers were stuck in 100 percent utilization their interrupts in the best way they know how, doing as little
thinking. Remember, it hadn’t been that long since 100 per- as possible, doing enough to get by. They are not thinking of
cent utilization meant something significant. ways to improve. They are not thinking ways to help others.
Now, remember what it means when a computer is fully They are not thinking of ways to innovate. They are thinking,
utilized and it’s a single-process machine: It can do only one “How the heck can I get out from under this mountain of
thing at a time. It can’t service any interrupts. It can’t respond work?” It’s horrible for them, for the product, and for ev-
to any keystrokes. It can’t update its status. It can only keep eryone they encounter.
processing until it’s done. When you ask people to work at 100 percent utilization,
Now, if the program is well behaved, and is not I/O bound, you get much less work out of them than when you plan for
or memory bound, or CPU bound, and is a single-user, single- them to perform roughly six hours of technical work a day.
process machine, such as a personal calculator that only adds, People need time to read email, go to the occasional meeting,
subtracts, multiplies, and divides, that’s probably fine. But as take bio breaks, have spirited discussions about the architec-
soon as you add another user to the mix, or another process, ture or the coffee or something else. But if you plan for a good
you are in trouble. (Or, if the program is not well behaved and chunk of work in the morning and a couple of good chunks of
does not finish properly, you are in trouble.) work in the afternoon and keep the meetings to a minimum,
And that’s what we have with modern computers. Modern technical people have done their fair share of work.
computers are multi-process machines. If you work in a meeting-happy organization, you can’t
With multi-process machines, if a computer is fully utilized, plan on six hours of technical work; you have to plan on less.
you have thrashing, and potential gridlock. Think of a highway You’re wasting people’s time with meetings.
at rush hour with no one moving; that’s a highway at 100 per- But no matter what, if you plan on 100 percent utilization,
cent utilization. We don’t want highways at 100 percent utiliza- you get much less done in the organization, you create a terrible
tion. We don’t want current computers at 100 percent utiliza- environment for work, and, you create an environment of no
tion either. If your computer gets to about 50 to 75 percent innovation. That doesn’t sound like a recipe for success does it?
utilization, it feels slow. And, computers utilized at higher than
85 percent have unpredictable performance. Their throughput Agile and Lean Make the Myth
is unpredictable, and you can’t tell what’s going to happen. Transparent
Unfortunately, that’s precisely the same problem for people. Agile and lean don’t make 100 percent utilization go away;
they make the myth transparent. By making sure that all the
Why 100% Utilization Doesn’t Work for work goes into a backlog, they help management and the
People teams see what everyone is supposed to be working on and
Now, think of a human being. When we are at 100 percent how impossible that is. That’s the good news.
utilization, we have no slack time at all. We run from one task Once everyone can visualize the work, you can decide
or interrupt to another, not thinking. There are at least two what to do about it. Maybe some of the work is really part of
things wrong with this picture: the inevitable multitasking a roadmap, not part of this iteration’s work. Maybe some of
and the not thinking. the work is part of another project that should be postponed
We don’t actually multitask at all; we fast-switch. And we for another iteration. That’s great—that’s managing the
are not like computers that, when they switch, write a perfect project portfolio. Maybe some of the work should be done
copy of what’s in memory to disk and are able to read that by someone, but not by this team. That’s great—that’s an im-
back in again when it’s time to swap that back in. Because pediment that a manager of some stripe needs to manage.
we are human, we are unable to perfectly write out what’s No matter what you do, you can’t do anything until you
in our memory, and we imperfectly swap back in. So, there see the work. As long as you visualize the work in its entirety,
is a context switch cost in the swapping, because we have to you can manage it.
remember what we were thinking of when we swapped out. Remember, no one can do anything if you are 100 percent
And that takes time. utilized. If you want to provide full value for your organiza-
So, there is a context switch in the time it takes us to swap out tion, you need to be “utilized” at about 50 to 60 percent. Be-
and swap back in. All of that time and imperfection adds up. And, cause a mind, any mind, is a terrible thing to waste. {end}
because we are human, we do not perfectly allocate our time first
to one task and then to another. If we have three tasks, we don’t This article originally appeared on TechWell.com.
allocate 33 percent to each; we spend as much time as we please Visit http://well.tc/Myth14-3 to post comments and questions
on each—assuming we are spending 33 percent on each. for Johanna.

www.TechWell.com

Author recommended books, blogs, gadgets, websites, and other tools for building better software

What "tools" do you use to help you
overcome a slump during your workday?

When I need a quick reset during the workday, I often head for coffee with a
friend at work. Starbucks is good, but the dark chocolate mocha at Tully's in
the Bing.com building next door usually does the trick.
–Jason Arbon

I take a coffee break with my friends or play ping pong When I find myself in a slump, I usually play a
or foosball with office colleagues. It rejuvenates and game of some kind on my computer or phone.
helps me in bonding with employees, resulting in a I like the pattern-matching type of games—
happy work environment. Bejeweled or Mahjong. Sometimes, I play timed
–Mukesh Sharma versions, which wake up my brain. Even picking
up my Sudoku book will trigger my brain
functions in a different way.
–Janet Gregory

SCM
Getting out of the office and taking a walk is
one of the best ways for me to break out of
whatever thinking pattern was getting me stuck
www.accurev.com | info@accurev.com and come up with new ideas. Often, I get the
best ideas when I'm not thinking of the problem
at hand. And while I find listening to music or
podcasts sometimes helps me think when in the
office, my slump-clearing walks are best done
without any background, save for what's in the
neighborhood. And, if nothing else, I'm getting
some exercise!
–Steve Berczuk

S OFTWARE C ONFIGURATION
Slow preparation of strong
M ANAGEMENT FOR cappuccino is my preference
Agile, Waterfall, & Everything in Between for staying awake. Beside the
"coffee injection," this also allows
me to spend some time with my
Top 5 Software Development
colleagues and stay up to date
Process Challenges
with many daily issues.
Download White Paper:
www.accurev.com/top512 –Yoram Mizrachi


From One Expert to Another

Paul Poutanen Since the SMS market is
Years in Industry: 17 international and complex, I’m not
Email: paul@mob4hire.com aware of any formal governance
around this system. If you are a
Interviewed by: Jonathan Kohl company depending on SMS in
various companies, you may be
Email: jonathan@kohl.ca
It is incredibly difficult to try to getting different SMS products
replicate what is out there in the when you purchase the same
world without enormous cost. package from a broker next time.
An SMS service provider has to
purchase messages from different
SMS testing depends on testing
brokers in different countries.
a lot of platforms (a combination
of a handset, carrier, and
SMS is considered ubiquitous Every device that is used for country). Testing only within your
in the mobile space, and the only platform testing is controlled by a organization won’t tell you much,
standard digital app that can be human. If something goes wrong, unless you have offices in many
found on any device. It is also they can troubleshoot and bring locations where your services
extremely popular: According their own devices back online. need to be used.
to Wikipedia, approximately 2.4
billion handset users use SMS.

When we test messages, we confirm that
SMS messages make it to a particular country and Bringing hybrid
carrier by utilizing testers who use that carrier
in that country. The test is simple. It’s binary. It’s a
development and
pass or fail. Did the SMS make it or not?
deployment to
This process of getting an SMS the enterprise.
to the end handset is dynamic.
SMS aggregators may change hybrid cloud
their routes every day, meaning
a message that was successful public cloud
private cloud
when sent in the morning may not
work in the afternoon. CollabNet has built the first front end
platform to lead the industry shift to hybrid
cloud development and deployment. Learn
5 Steps your how an Enterprise Cloud Development
The way it works is not simple, especially when
Dev Team solution can enable:
looking at international SMS routing. There are
should know • 80% cost efficiencies
over 1,000 carriers and network operators in the
• 70% faster to market
world.
• Compliance and visibility
Manage Hybrid Cloud

Champion DevOps

Codify Dev Processes
Value

Download the free white paper:
Implement Community Architecture

Embrace Cloud

www.collab.net/ecd
Enterprise Cloud Development Maturity

For the full interview, visit W W W.COLLAB.NET | +1 650-228-2500 | 888-778-9793

http://well.tc/FOETA14-3


ISTOCKPHOTO


O
ur brave new world of agile, mobile, and continuous StickyNotes for keys to deciding whether a test should be au-
engineering is leaving traditional test engineering in tomated or manual in an agile world. In a continuous engi-
the dust. As test engineers, we need to rethink the neering environment, it is even more difficult to decide when
entire approach to software quality and engineer and where to automate your testing. Automation used to be
our way back into today’s world. Our users and customers done during “breathers” in between ship cycles or deliber-
are already suffering because we haven’t adapted. ately aligned with engineering work in a waterfall schedule.
Part one of this article (March/April 2012) discussed how In today’s world, developers and testers alike need to be very
many test teams have responded to the time pressure of agile frugal and decisive about when and where to add tests.
by shifting their focus to early cycle unit and “small” tests,
which are faster or more easily automated. In this shift to Test Plans
agile, late cycle or manual testing efforts are often dropped The days of the test plan are numbered. Agile and quick
or, worse, the program management and development teams engineering cycles often mean a lot less product planning—the
embrace agile and continuous practices, but the old world re- same should happen for testing. In fact, every minute spent
gression test cycle is left hanging around like an archaic ritual planning testing activities is time not spent testing a product
that adds a few days or weeks to an engineering process that that is continually going out the door. Testers should drop the
wants to be continuous. comfortable and slow process of documentation around test
Agile and continuous testing offer the ability to maintain plans. What should guide testing isn’t the completion of a list
quality standards in the face of continuous deployments. of tests written a month or more ago. The tests likely passed
Without continuous testing, defects slip into the released bi- the last time you ran them, and they likely will pass again.
naries and are often caught by end-users. The emerging mo- What matters is testing the most dangerous and risky part of
bile, web, and desktop application markets that host your the product at any given time. Test that until something else
apps amplify the visibility of these faults. The markets are worries the team more. New features are often more risky,
forums for comments on quality that can deter potential new but it is more likely there is still risk debt hidden in an older
users with reviews pointing to crashes, performance, usability, feature. Agile testing usually focuses only on the latest fea-
and functional issues and are very visible to other users and tures and only until the next iteration with its new features
your own engineering team. Every continuous build must be and changes. Continually updated heatmaps are a quick and
matched with continuous testing or the product risks poor easy way to track risk, help focus testing energy, and avoid
market comments and ratings, which affect user perception, the documentation process of traditional test plans.
downloads, and even the morale of your engineering team. Attributes-components-capabilities (ACC) is the process of
Agile and continuous testing are critical to maintain quality breaking down the project into a grid of the attributes that
in today’s world of agile, mobile, and continual engineering. the team and the customers would like the product to have
The test engineering recommendations that follow as- and the software components that are important, and then
sume that the development team is well on its way to best listing the product capabilities (features) that lie at the inter-
agile practices, such as strong Unit+ test coverage and con- action of goals and implementation. Now, assign a risk value
tinuous builds and deployment, and that the development to each square. Testing should always be focused on the most
team assumes accountability for quality. Unit+ tests are a dangerous, “red” areas.
strong set of unit tests with multi-component and interface The ACC process can be done in a spreadsheet, on a
validation automation in addition to standard unit testing napkin, or with a web tool that does coloration automagi-
scope. Without these, the team cannot be agile with respect to cally. The key is that it can be done in less than thirty min-
quality and backlogs of work. If the developers are not adding utes and can be updated in minutes with each new feature or
unit tests with every check in, it is an incredibly expensive and product change.
slow way to develop products. Most important is the notion
that developers are accountable for quality. Many avoid this Regression Testing
responsibility, but if they take on that role, they will add the The days of the regression test pass are numbered. Test
unit test coverage, avoid buggy code, and ensure testability continually. Drop the lists of hundreds or thousands of
is designed into the product. (For details, see the book How canned test cases that usually pass anyway. Instead, perform
Google Tests Software. [1]) Assuming the development team exploratory testing driven by the risk matrix. Produce dif-
is on its way toward this model, let’s look at how late cycle ferent builds for different levels of risk tolerance and “bake
testing must adapt. time.” Build the infrastructure to automatically and immedi-
Take a closer look at the bugs reported for your favorite ately deploy the latest builds to the developers. The Android
app in the iTunes store or in Google Play marketplace. How test team does this: If developers produce a bad build, it’s
many users complain about failed unit tests? Not many. They likely that the call they make on the way home will fail. This
either don’t care or the small tests are doing their job. Users means the developers are more likely to check in good code
complain about basic issues of installing on their particular with some testing. After a few days of baking with the en-
device, crashes or hangs while using the app, performance, gineering team, share these builds with ever-larger and less-
pricing, usability, or design. Small, automated tests don’t risk-tolerant customers. If you don’t have friends or a beta
catch these things; test engineers and early users do. See the community, you can leverage the growing communities of

www.TechWell.com

crowd testers for a dollar or two. When a build comes out at items are not truly agile, they often are just too nervous to
midnight or on a Friday evening, don’t let the build sit around defer judgment to the individual teams or they lack the mod-
untested. Deploy it to the team and send it out to the crowd— ular code, tests, and deployment features to move into the
they actually have more capacity on weekends and evenings agile world. More often than not, these hierarchal teams are
to find and report bugs. Given the importance of deployment missing out on the benefits of agile.
in an agile world, if the application or infrastructure doesn’t
have a quick way to deploy, roll back, and monitor these dif- Test Case Databases
ferent builds, test and quality engineers should build it before The days of test case databases are numbered. Much like
adding any tests. bugs and work item databases, they are a sign of non-agile
practices in an agile world. If testing is based on risk anal-
Textual Bug Filing and Triage ysis and is dependent on what new features are added to the
The days of bug filing and manually determining priority project this day or this week, the team will know what and
are numbered. The time it takes to manually enter into a text where to test. Having a small, vague list of exploratory tactics,
form the exact details of the system state, actual results, and such as a set of exploratory testing tours, can be handy, but
expected results hasn’t changed in a decade. How long does it these lists are small and don’t require a full-blown database.
take humans to read, understand, and judge the severity of an Even spreadsheets are good enough for the testing of many
issue from text? The better bugs have pictures attached, but of Google’s web apps, as they let many folks log pass/fail in
this is an extra step that still doesn’t tell us anything about the the cells next to simple “areas for testing.” As for queries on
actual state of the application. Bug filing and feedback from the test cases, test case counts mean nothing to the customer;
users are moving to a point-and-click exercise, where text is they are the least valuable of all project metrics. In my time at
optional and software automatically gathers most of the rel- Google, I witnessed the dismantling of two test case database
evant application state, images, and videos and even knows efforts. Smart test engineers always want to build them, but
what test case is executing. Some even generate replay scripts agile teams just don’t use them. If the team really needs to
so the reproduction steps can be played back on the developer’s plot the history of pass/fails for a product, the team by defini-
machine. These also render the known bugs in context—no tion isn’t in an agile environment, and the team is living in the
more crafting a query outside of the application under test and past. Keep the trees green, tests passing, and the bugs fixed.
hoping the testers use the same words the other bug filer used.
Show bug data in context within the application and make it Release Management
point-and-click easy to see existing bugs and file new ones. The days of release managers are numbered. The pro-
gram management and technical leads on the project should
Bug and Work Item Backlogs continually assess the quality of the product (with risk input
The days of large bug and work item databases are num- from the test engineers). They are accountable for quality. The
bered. A key to being agile is keeping the number of bugs and builds should always go out, but features should be easily
work items to a minimum. When it comes to tracking bugs disabled until they are ready for prime time. Facebook engi-
or requested feature work, a valid agile response is “Don’t.” neering follows this basic practice, as do many web and client
Really. Jason Fried of 37signals.com said it best in his book projects at Google. It is OK to have code in the product that
Rework: “There is no need for a spreadsheet, database, or isn’t yet ready; the only question is when it will be turned on
filing system. The requests that really matter are the ones you for users to see. If the product doesn’t have these mechanics,
will hear over and over again … your customers will be your engineer them into the product to support agile practices and
memory … If there is a request that you keep forgetting, that’s continual deployment.
a sign that it isn’t very important. The really important stuff
doesn’t go away.” [2] Team Structure
Fix bugs as soon as the team sees them. Any amount of The days of large, dedicated, onsite test teams are num-
bug debt is a drag on morale and speed, and it enables de- bered. Welcome users and the crowd into the engineering
velopers to do the wrong thing, which is add more code. If process. Today, most teams dedicate headcount to onsite test
there are bad bugs in the code, the team shouldn’t release engineers. These engineers are there regardless of whether and
the builds. If a bug is “difficult,” team members shouldn’t when they are needed. These engineers get bored and lose
defer it. They should investigate and debug, not add new fea- their objectivity seeing the same product day in and day out—
tures. Customer and feature requests shouldn’t be added to a they can only truly represent a first-time user once! They also
backlog, either. place a cap on testing bandwidth and throughput, as there
If the team needs a database to hold and support complex are only so many of them. Many smaller companies now reap
bug queries on lists or work items, the team is likely only the benefits of having a virtual, crowdsourced testing team.
feigning agile engineering processes. Agile teams are moving Much like VMWare and Amazon virtualized our test lab ma-
toward smaller, single-page punch lists of work items for the chines, the virtualization of our test teams is happening with
entire team, either on a whiteboard or in a simple shared doc- very similar benefits. While working on Google Chrome, we
ument with bullets. Large engineering teams that have created passed the same manual test cases we once passed to our five-
hierarchal scrum review meetings to review bugs and work person, dedicated manual test team to a virtualized testing


team at uTest.com. This virtual test team enabled us to ex- the incoming bugs. Onsite testers or PMs integrate the bug
ecute tests more quickly as we could spin up ten, twenty, or data from crowd testers with the rest of the engineering team
more testers when we needed a test pass to complete quickly. during standups. Virtual test teams are here.
And we could spin them back down when we didn’t need Some say test engineering’s days are numbered—but really,
testing. This virtualization of the testing team also proved it’s many of our rusty tools whose days are numbered. This
less expensive than dedicated resources for the same task. A leap takes a little bit of risk, an engineering mindset, and will-
side benefit was that they found bugs that our onsite testers in ingness to trust early adopters and the crowd with our bits.
the lab just couldn’t find, because their machine state was “in Not every option above is a perfect fit for every situation, but
the wild,” with user accounts on various sites across the web, the closer your team can get to these best practices, the more
different perspectives of quality, and fresh eyes. Just as with your team, product, and customer will reap the benefits of
Amazon web services, the management of these virtual test agile and continual engineering. If we don’t engineer late cycle
resources was simply done via web page. testing value into our agile tools and processes, our products
Crowdsourcing is becoming more sophisticated than onsite and customers will suffer from products that pass every unit
test management. Crowd testers are rated on every bug, every test but fail for the user. {end}
project, and every test case by the engineering team. They are
even rated based on fit for different types of testing. These jarbon@gmail.com
crowd testers can be “pinned” to the project so they are like
virtual team members or cycled out at will to get new perspec-
tives and machine contexts and experience. Most importantly, For more on the following topics go to
these testers are closer to the real users and can test on real- www.StickyMinds.com/bettersoftware.
world machines, account states, and from mobile locations. n References
The number of dedicated onsite testers should be kept small. n Automated or manual testing?
They shouldn’t be testing; they should be managing the crowd
for any regression and exploratory testing. Some startups
have no on-site testers, simply a program manager (PM) who
directs the crowd testers at companies such as uTest.com.
These PMs often spend only an hour a day communicating
the latest changes in the continuous builds and reviewing

3


ISTOCKPHOTO


T
here are two closely related aspects to a team’s being agile:
1) planning or project management, and 2) execution or engineering
practices. When people think about agile projects, the focus is often
either on the planning and project management process or the engi-
neering practices. It’s important to understand that both aspects work
together. This article discusses how the way you execute your engi-
neering practices can help your agile process be effective.

Agile Basics
Agile methods acknowledge uncertainty and manage it with techniques that rely
on transparency, inspection, and adaptation, with an emphasis on working software.
Agile projects allow teams to adjust goals in response to technical issues or changes in
current needs or future technical or market forces.
Some agile methods, such as XP, focus on technical practices. Others, such as
Scrum, focus on project management practices. Both planning and execution are nec-
essary for an agile approach to work. Good planning makes it easier to execute in an
agile way. Agile plans can only be effective if the team follows good engineering prac-
tices that give you the feedback that you need to inspect and evaluate and a codebase
that will allow you to adapt.
To understand how engineering practices can drive improvements in the agility of
your team, you need to understand the cultural challenges of being agile, and some
basics of agile planning.

Cultural Challenges
Agile is about incremental progress and continuous improvement. To become a
better agile team, you need to acknowledge uncertainty and the possibility of failure.
In many teams, this is hard to do. Getting good feedback requires changes in how you
define requirements, develop features, and interact with others in your organization.
Defining requirements with precise-enough definition to show whether you have
met the goal, while also maintaining enough simplicity that you can move from speci-
fication to development quickly, can be challenging. Developing, maintaining working
code, and coding and designing in a way that allows for incremental development
and continual feedback require new approaches and skills. Change, learning, and ac-
cepting and giving feedback are often difficult.

Agile Planning
“Agile planning” means enough planning to move forward and measure progress.
Agile requirements are focused on delivering functionality to users and start with
three things:
• A user, who has a business need
• A feature, which is what the system will do
• A goal, which is reason the user wants to do the task

While many teams can develop lists of features, the user and end-goal parts of the
story are often missing. The user and his goal are the most difficult parts to express
but also the most important.
Having a clear statement of a goal allows you to decide what implementation will
satisfy the core need and to evaluate whether the story is even necessary to implement.
Since implementing features that do not have a clear use is wasteful, removing items
from the backlog can be a major efficiency gain for a team.

Tracking and Defining Done
Tracking progress on a frequent basis is an important way to identify problems.
Agile teams measure progress by continually re-evaluating the amount of work re-
maining, rather than effort spent or “percent complete.”
Even when the product owner has a clear vision, teams often struggle with defining
what needs to be built in a way that can be evaluated. Tests pass or fail, and builds
are successful or not, but it’s more difficult to determine if the test is testing the right

www.TechWell.com

thing. Deciding whether a team has completed a story may al- isn’t useful and stakeholders cannot provide useful feedback
ways have a subjective element, but you can make it easier if on it until it can run on the target environment. Also, to be
you have a good sense of what “done” means. “done,” you need to address differences between a develop-
With an agile approach, some degree of consensus on how ment system and a production-like one. There are two steps
to evaluate completeness is critical. Without a good under- to building code in a way that supports an agile approach:
standing of what a complete story is, the team cannot estimate developing in vertical slices and deploying early and often to a
accurately and, thus, cannot set expectations. Not being able target environment.
to set expectations can cause a breakdown in trust between The vertical slices approach is to develop end-to-end fea-
the team and the product owner. Without trust, it’s harder for tures, from the user interface (UI) through whatever backend
management to accept the idea of self-organizing teams, thus systems are involved. Rather than focusing on the data model
negating the efficiency benefits this approach provides. or the UI or application tier, building end-to end (though less
Quite often, even the product owner is unclear about what rich) solutions has advantages. Users can see the application
to ask for. In these cases, it’s best to make decisions and ac- do something. A “data model,” while important, is not easy
knowledge that you may be wrong rather than work with to demonstrate. The team can validate the interactions be-
difficult-to-evaluate stories. tween layers and make changes to make work at other layers
The developers on an agile project can contribute to easier, thus minimizing unnecessary rework. UI implementa-
project success in the face of uncertainty by working towards tion can be influenced by decisions made at the data layer,
maintaining agile code. for example, and vice versa. The team and product owners
can understand what features are truly necessary and have a
Agile Code better sense of what to defer if something is late.
Understanding the needs of the agile planning process, Make your application available on a target system early
we can now talk about how engineering practices meet the and verify the deployment and installation process often. This
needs of agile methods and drive them when they are lacking. will give you an early opportunity to identify decisions that
Regardless of the agility of your product backlog, to be an will simplify the deployment and configuration process.
agile team you need agile code. Agile code is code that you
can change while still being able to deliver working software The Agile Team
on a regular basis. To be able to implement in vertical slices and be efficient,
Agile code can be maintained by a combination of good agile teams are often composed of generalizing specialists.
design and having practices in place that provide constant Generalizing specialists can work on multiple aspects of the
feedback on the state of your code so that you can detect system, though they have expertise in a particular area. This
problems as soon as they occur. These practices include: means that all work that touches the UI is not blocked if your
• Automated unit and integration tests in combination UI developer is overly busy. It also allows a first-pass, end-to-
with continuous integration, to provide immediate end implementation by a single developer. As a generalizing
feedback on the effects of a change to the code specialist, you are not abandoning the idea that there are no
• Refactoring and continually improving the structure of “experts,” but you are encouraging team members to learn
code while maintaining functionality about and work with other aspects of the code. Having such
• Frequent deployments to a production-like environ- a cross-functional team not only reduces bottlenecks in the
ment to identify issues before they can cause a last- development process but can also improve code quality by
minute emergency and to make the application visible increasing the number of people who work with—and thus
to stakeholders implicitly review—code.
By maintaining code in a working state and in a state
where it is easier to change, you make it possible for the team Agile Code at the Center
to implement changes to a product backlog that a product To be successful at agile, you need to consider the en-
owner might ask for. tire product lifecycle, from planning to execution. You also
While technical practices such as refactoring, design, need to be very aware of the challenges that the difference
and testing are essential to a successful agile project, avoid in approach will present to teams that have a different initial
having purely technical tasks on the product backlog. Rather, mindset. In many ways, implementing agile technical prac-
consider how doing these tasks furthers the progress of the tices may present less resistance than planning practices, and,
project. When working on backlog items, always consider ef- as long as your organization wants to be more agile, working
fort required to refactor, design, and so forth as part of the on the technical practices can help identify the other bottle-
estimate, since delivering code that can sustain change is es- necks to agile. {end}
sential to agile success.
steve@berczuk.com
Delivery and Deployment
Working software is the measure of progress in an agile This article originally appeared on TechWell.com.
project, but “working” means more than just “can demo” Visit http://well.tc/14-3AgileCode to post comments and
or even “compiles and passes automated tests.” Software questions for Steve.


ISTOCKPHOTO


H
ere today, gone tomorrow” is probably the best way to characterize the pace of change
in the mobile market. In fact, many of today’s popular handsets and tablets become
outdated and irrelevant in a few months. The mobile market is extremely dynamic, un-
predictable, and fragmented. The numerous operating systems and plethora of platform
versions, networks, hardware, and form factors make it challenging to maintain application quality.

The OS Challenge
New devices contain the latest or near-latest OS versions, and they usually automatically upgrade
to the newest available version. There are no guarantees that an application developed according
to an older OS version will function properly with a new version; enterprises have no choice but to
conform to this pace and continually develop and test version updates for their applications.
For example, in January 2011, Android 2.2 OS version was leading approximately half of the
Android mobile market. A few months later, Android 2.3.3 took its place. By March 2012, Android
2.3.3 had reached more than half of the Android mobile market and is projected to take over the
market.
This is one example of the many competing platforms available. For a better understanding of
the market dynamics, this example should be multiplied by the number of available platforms in-
cluding iOS, Android, BlackBerry, and Windows Phone.
Figure 1 shows the usage growth rate of the top five worldwide mobile operating systems. You
can see how the mobile market fluctuates with no defined leader or standards.

Adapting the Software Development Cycle to Mobile
Mobile application testing simply cannot be served by the traditional development and QA cycle.
As stressed previously, the market is extremely dynamic and unpredictable. A tremendous number
of customers will instantly adopt newly released mobile devices and OS versions and connect right
away to applications and websites. Although an organization may not be prepared to introduce an
updated application version, users expect nothing less than a flawless user experience.
In the mobile market, the risk accumulated between product releases is much greater than in
traditional software. This is because the market changes are much faster. For example, when devel-
oping a traditional web application, such as online banking, the chances that the IE browser version
will change within the six-month development cycle is unlikely. In mobile, the leading devices and
OS versions are likely to change within this six-month timeframe. This leaves companies no choice
but to accelerate the release cycle in order to limit risk exposure, as shown in figure 2.

Figure 1: Top five worldwide smartphone vendors, 1Q 2012 (Source: IDC)

www.TechWell.com

Software testing flight plan for learning and networking event

Software testing flight plan for learning and networking event

Recommended

Recommended

More Related Content

Similar to Software testing flight plan for learning and networking event

Similar to Software testing flight plan for learning and networking event (20)

Recently uploaded

Recently uploaded (20)

Software testing flight plan for learning and networking event