sqe_bettersoftware_0310

8/8/2019 sqe_bettersoftware_0310

1/49


2/49


3/49


4/49


5/49


6/49


7/49


8/49


9/49


10/49


11/49


12/49


13/49


14/49


15/49


16/49


17/49


18/49


19/49

Be trained from your desktop with SQETrainings eLearning courses. Experienceclassroom value with the convenience of self-paced instruction on the Web.

What are the benefits ofeLearning? Superior lesson content: Developed and

delivered by experts 90 Days access to all course materials:

Learners have unlimited 90 day accessto online content

Access to expert test consultants: Emailquestions and comments to the experts

Powerful multi-media format: Studentsexperience professionally narrated audioand video clips

Interactiveexercises: To reinforcenew skills and

concepts

Experience theAdvantages ofSelf-PacedeLearning

eLearning

Try our New Demos Now Available onlineat http://www.sqetraining.com/eLearning

New Courses Now Available in eLearning FormateFoundation for Requirements Development and ManagementA Roadmap to Success

If you currently develop and manage requirements, manage people who do, or plan to do eitherin the future, this course is for you. This course teaches essential requirements development

and management skills in a flexible self-paced eLearning format. The curriculum is a seriesof eight self-paced courses that build the foundation you need to successfully develop andmanage requirements for business projects and software products.

eSoftware Tester CertificationFoundation LevelBecome a Certified Software Tester from Your Desktop

Are you looking for an internationally recognized certification in software testing? Deliveredby top experts in the testing industry, eSoftware Tester Certification is an accredited trainingcourse to prepare you for the ISTQB Certified Tester-Foundation Level exam. This program isthe only internationally accepted certification for software testing, accredited by the ISTQBthrough its network of national boards.

eMastering Test DesignThe Art and Science of Creating Test Cases

This course begins where many software testing courses end. Once the test plans are written,

test teams are formed, and test tools are selected, it is time to create test cases. Since testingeverything is impossible, the first step in test design is to choose a subset of all possible testsof program paths and data combinations to find important defects quickly.


20/49

www.StickyMinds.com MARCH/APRIL 2010 BETTER SOFTWARE 17

Management Chronicles

As a de ect manager or, more speci cally, as a test manager incharge o de ects, I was never so popular as when I started touse a whiteboard to keep up to date with the latest ound and

xed de ects. Suddenly, senior program management knewwho I was and what I did. Every day theyd ask how manynew de ects were raised, what the priorities were, which oneswere critical, and even who was raising themdata I couldreadily provide rom my whiteboard. As the de ect numbers

went up, there would be more concern; as they came down,less. But as time passed, I realized thata lot o the use ul in ormation thatwas ound on the de ect managementsystem couldnt be reported using met-rics. These were the hidden messagesthat were important to decipher.

Defect Description andDeveloper Comments

Much o what turned out to be use ulin ormation was ound in the de ect

description and consequent developercomments. What mattered was how thedescription was written, not what the in ormation was. Whilesome testers reported de ects in step-by-step detailincludingpreconditions and all relevant dataothers simply stated thatthe system had crashed or that a calculation was wrong.

The large variety in reporting styles told me a number o things. It told me who were the experienced and con dent tes-ters and who were not so con dent. It told me which tech-nical areas caused rustrationwhich became apparent in thelanguage (Surely the developers can see..., This is the thirdtime...). This in ormation added to the weight o evidence

that certain unctional areas were high risk.Also, the developers replies and consequent debate toldme something about the relationship between the developersand testers. Again, the language de ned much o this, pro-viding some clear evidence that relations werent as good asthey could have been. The number o replieso ten three,

our, or ve rom each sideindicated that either the de ectresolution process wasnt working and that improved contactbetween development and the test team was needed, or thatthere was some con usion about what the requirements were.

Defect HistoryA de ects history sometimes gave me interesting in orma-

tion. Once, when trying to track down why a given de ecthad been closed months be ore with no explanation, it was

ound that on the day o closing, the de ect had gone througha number o hands. Following through with the parties inquestion led to the discovery that a wrong assumption hadclosed this and other de ects. The de ects were reinstated. Onanother occasion, we tracked another group o de ects thathad been allocated to an incorrect party. Again, studying the

history enabled us to recti y incorrect details and eed lost de-ects back into the workfow.

Defect Fields and FormatsPrior to taking a holiday, I prepared

a handover note or the de ect man-agement process. During the prepara-tion, I realized how complex the de ectmanagement system was becoming.The number o di erent de ect statusesshould have given this away. Therewere seventeen. There were also twenty

elds or testers to ll in. A commonreason we cited or why testing took

much longer than expected was because having to raise anddetail so many de ects was an onerous task. However, it didntoccur to me until this point that this was partly o our ownmaking and not just a result o de ect numbers.

I resolved to try to reduce this complexity, eliminating someo the mandatory elds, reducing the number o eld values,and removing some o the statuses. This had a small but im-portant e ect on the speed o the de ect process. Though weaccepted that capturing the correct data up ront was timeconsuming, it did mean less time was spent in the number o

in ormal queries returning rom developers.I discovered a use ul piece o in ormation when I askedwhy the test re erence eld in particular was rarely beingused. It turned out that many o the de ects were ound usingan exploratory approach rather than ollowing scripts. This inturn indicated that there was a problem with the quality o thesupplier testing. The supplier was using our test cases to testits so tware (in a rigid and incorrect ashion) and at no pointwas experimenting or trying to break the system. This turnedout to be one o the key discoveries o the project. As a result,two urther intermediate stages o testing were inserted, rstinto the supplier test cycle and then into the user testing (acon dence test immediately a ter delivery).

Hidden MessagesAn experienced test manager can gather useful information by looking at

more than the defect management systems data.by Dan Minkin | [email protected]

I realized that a lot of the

useful information that

was found on the defect

management system couldnt

be reported using metrics.


21/49

18 BETTER SOFTWARE MARCH/APRIL 2010 www.StickyMinds.com

Management Chronicles

The Defect Tool and Its UseAs the program moved later into the testing cycles, the use

o the tool became more widespread and higher profle. Whowas using the tool, when, and why gave me insight into theprogram dynamics and events.

The program manager would ask me what the latest fgureswere and explain to me why he needed to know. By knowinghis reason, I was able to add extra in ormation or pinpointde ects as the situation required.

By asking mysel who was interested in the in ormation,it became possible to identi y and build up relations withkey players in the program. It became clear that one o thestrand coordinators, who reported to the program manager,was really one o the driving orces o the program. The re-lationship that was ostered was mutually benefcial, with thecoordinator having readily available in ormation on so twarequality and the test team having an active and voci erous ally.

Defect StatisticsThe statistics that I provided on a daily basis were simple.

My daily report explained how many new de ects had beenraised, the total number o de ects to date, and how manyde ects existed with our supplier. No one ever asked me orhistorical data or how many de ects had been fxed by oursupplier since the start o the program or the average time ittook to fx a high-priority bug.

It was just as well. I couldnt have answered any o thosequestions, anyway. I hadnt set up the de ect system to capturethat kind o in ormation. Once a de ect was fxed, I wasnt in-terested in it anymore. But, that raised questions in my mind.Should I have planned or the time when the questions wouldbe asked? Was this program simply not interested in carrying

orward statistics into uture programs? When I questionedthe program test manager, his view was frmly the latter. Asa matter o pragmatism, this issue dropped into the back-ground.

The de ect management tool and process should be aguide. Statistics and de ects are use ul, but they are only awindow onto the health o the program. As always, it is theawareness into the human element o any part o the programthat makes or the ull story. Elements to be aware o includethe developers writing style, the amount o debate withinthe de ect descriptions, and how success ully the tool is beingused. A success ul test manager should not take data and in-

ormation merely at ace value but should use this to in ormhis view and to ask himsel urther questions. So, when youare looking at statistics rom your de ect management tool,know that there is more you can understand. {end}

This article originally appeared on StickyMinds.com.

Get your FREEtrial now at

purecm.com/start10-1

Mapping your release planning to your project congura on allows you to increase exibility and reducethe risk of human error. Get more than just a link between issues and code changes: get true integra on.

Imagine automa cally populated developer workspaces based on the release they need to work on.Imagine real- me status updates throughout the development lifecycle. Or imagine automatedno ca ons about xes missing in a current or future release, drama cally reducing the risk of regression bugs.

Learn how PureCM Professional can help you to manage your so ware development.Get the free evalua on resources at purecm.com/start10-1

Are you struggling to manage

Get integrated release planning, task tracking and source control tohelp solve your development challenges.

in parallel?maintenance and development

N E W

Visit StickyMinds.com to comment on this article


22/49

Can you nd 7 mistakes in this photo?

Did you nd them all? Answers at www.testcomplete.com/hawkeye

Fun challenge, right? Great software testing feels like that.Now do that 5 times a day, every day, for the next yearWith the Exact. Same. Photo. Does your testing feel like that?

Time for TestComplete.

Free yourself to do the quality work that you love: explore, investigate and discover.

Test faster. Test better. Test more.

Did you nd all 7 mistakes?

TEST WITH THE BEST

TestComplete is the most exciting software testautomation tool available.

TEST ANYTHING

Web, Ajax, Flash, FlexWindows, .NET, WPF, SilverlightJava, Qt, Delphi, MS O ceFunctional, Load, Regression, Manual

TEST IT YOUR WAY

Automate without programming via Keyword TestingFree extension downloadsProfessional IDE for test engineersFriendly and responsive support

Visit www.testcomplete.com/hawkeyeto see how you did and try TestCompleteAutomated QACall Us: +1 (978) 236-7900


23/49


What book do you consider a must read for someonejust starting out in the software industry?

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

Peopleware by Tom DeMarco and Timothy Lister because its a useful book on

the importance of teamwork in delivering software products.

Mike Cohn

James W. Moores The

Road Map to Software

Engineering: A Standards-Based Guide covers all of

the basic issues and points

the reader to where there

is detailed guidance on

just about every software

engineering topic. Testers can

obtain consensus-reviewed best

practices for both testing itself

and for any form of test basis.

Claire Lohr

For someone starting out as a business analyst in the software space, the

only place to start is Karl Wiegers Software Requirements . Karls coverageis pretty comprehensive and provides both a big-picture perspective and

immediately useful, detailed help for anyone writing requirements.

Scott Sehlhorst

The first testing book I owned and the one I still carry around is Tim

Koomen and Martin Pol's Test Process Improvement . It is portable, easy

to read, wide ranging, and full of suggestions. Other books are more in

depth but few are as practical.

Dan Minkin


24/49


Code Complete by Steve McConnell. I

recommend this because it gives a nice

overview of the nuts and bolts of creating

software. Its essentially a handbook, and

helps set the bar for someone starting out in

their career as a coder.

Jonathan Kohl

Chad Fowlers The Passionate Programmer . It doesnt

matter if you are a developer, tester, writer, or whatever. If

you are starting out (or if youve been working for a while),

Chad has great ideas about how to take advantage of all

opportunities in your career.

Johanna Rothman

Gerald Weinbergs Psychology of Computer Programming .

It was the first book to describe programming as not just amatter of hardware and software, but a human activity with all

the richness that such activities possess.

Lee Copeland

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

Want to get our authors' take on a particular resource? Email us at

[email protected] Subject: Virtual Resource Shelf .


25/49


FREEFUZZING TOOL!Unique opportunity to test top-of-the-range

commercial testing software for free.

Request your free copy now!http://www.codenomicon.com/free-ftp-suite/

FUZZING and the SDL

The Microsoft SDL

The Microso t SDL is the industry-leadingso tware security development process. Itis ounded on the idea that security shouldbe built into so tware during the so twaredevelopment process. It basically lists all thesecurity measures that need to be carried out

during the development process groupedaccording to di erent phases o the SDLC.For testers the most important phase in theSDL is the verifcation phase, where uzzingis used to test the robustness o the systembe ore the release.

Fuzzing in the SDL

Fuzzing is a natural part o the SDL, becausethe entire uzzing methodology promotesbuilding security into systems, instead o protecting vulnerable systems. In the Micro-so t SDL, uzzing is used in the Verifca-tion phase. However, uzzing can be used

throughout the development process romthe moment the frst so tware compo-nents are ready and even a ter the release.

The earlier the vulnerabilities are ound, theeasier and cheaper it is to fx them.

The idea behind uzzing is simple:unexpected data is ed to the inputs o a system and the behavior o the systemis then monitored. I the system crashes,then there is a bug in the so tware, whichcould have been exploited by attackers.However, the vulnerabilities can also betriggered by simple unexpected inputs inevents like heavier than normal use, systemmaintenance or when other devices orsystems send mal ormed inputs as a result o error conditions. A zero-day vulnerability is aticking time bomb, it does not really matterwhat eventually sets it o . The importantthing is to get rid o them.

Codenomicon was selected to participateas a tool vendor in the Microso t SDL Pro

Network, which assists companies in inte-grating the SDL into their developmentprocesses. Its o -the-shel De ensics solu-tions provide an easy way to ul ll the SDLs

uzzing requirement. No test tool creation ormaintenance e ort is needed, and as a so t-ware based solution De ensics is easy to inte-grate into existing tool libraries.

Answering testing challenges

The biggest challenges in Fuzzing arehandling the in nite number o possibletest cases and reaching the deeper protocollayers. Codenomicons intelligent uzzingmethods, which are based on protocol speci-

cations, cover the entire protocol imple-mentation, and thus they can target protocol

areas most susceptible to vulnerabilities toshorten test run times. Robustness tests canbe run, or example, automatically with everybuild. Intelligent Fuzzing tests can also unc-

tion as the peer o the tested system andgo through extensive message sequencesmaking it possible to identi y vulnerabilitiesin deeper protocol layers.

With new technologies the speci cationsare not always available. In such cases, tra ccaptures can be used to create mutation-based uzzers. Tra c capture uzzers arebased on real tra c samples, thus they onlycover a limited selection o the implemen-tation. Yet, per orming tra c capture basedtests already signi cantly improves the secu-rity and robustness o the system. Moreover,no additional knowledge is needed, thustra c capture based tests are quick to createand easy to execute. Codenomicons tra ccapture uzzer is an excellent tool or gettingstarted with zero-day bug discovery.

Benefts o Testing with De ensics

The biggest bene t o Codenomicons uzzingmethod is its ability to nd not only known,but also unknown or zero-day vulnerabili-ties. Fuzzing is essentially simulating attacksagainst a system under test to nd vulnera-bilities in it. Firewalls and virus scanners onlylook or known vulnerabilities and they addto the complexity o your system increasingits attack sur ace. Furthermore, applicationservice providers, like online-banks and webstores, cannot build ortresses around theirapplication, because their customers need tobe able to use their services.

Gain time and save money through preemp-tive testing. Instead o racing against theclock to get your system to work again andspending valuable resources in calmingdown angry customers, use uzzing todiscover faws and create patches or themproactively, be ore any problems occur. By

integrating uzz testing into your so twaredevelopment li ecycle, you can discoverfaws at the earliest possible moment andsave valuable resources.

To read more about Codenomicon and integrating fuzzing into your softwaredevelopment lifecycle, go to http://www.codenomicon.com/bettersoftware/

The increased complexity of new technologies and faster software releasecycles are making signature-based security solutions redundant. Insteadmore adaptable preemptive testing is needed. Moreover, due to outsourcing,the software development process itself is also becoming more complicatedcreating the need for more powerful project management tools such assoftware development lifecycle models (SDLC). The Security DevelopmentLifecycle (SDL) combines preemptive security testing with the SDLC model.

Advertisement


26/49


Digital Survey Questions

To participate in the survey, go to www.stickyminds.com/cloudsurvey . Results will

appear in Better Software magazine's May/June 2010 print and digital editions.

What do you consider the biggest beneftto cloud computing?

What is your main concern with cloudcomputing?

What percentage o your organization's ITresources have moved to the cloud?


27/49

June 611, 2010Las Vegas, NV

www.sqe.com/adpwest

RegisteR by apRil 9, 2010 and

save up to $400gRoups of 2 save even moRe!

KEYNOTES by international experts

Tim Lister Atlantic Systems Guild

Robert C. MartinObject Mentor

Johanna RothmanRothman ConsultingGroup, Inc.

Ryan MartensRally Software Development

indu try spon or :Conference

spon or:

NEW FOR 2010COLLOCATEDCONFERENCES!

C f c s :

+

Your registrationincludes full access to

the Better SoftwareConference!


28/49

Build Your Conference!Co fere ce chedu e i c ude mu i-d r i i g c e , u ori , ke o epre e io , co curre e io , ummi e io , d more!

sunday

Monday Tuesday

wednesday Thursday

s f w t C i c i F u d i l vt i i g (3 d y )

sc um M C i c i (3 d y )

p c ic t -d iv D v m (3 d y )

agi t i g p c ic (2 d y )th F u d i f agi D v m

Ch f m 37 h f- d fu -d y u i h w y u i -d h u ci c ic .

4 K y p i24 C cu s in w ki g expos ci ev d M !

friday

ag e le er h p suadd f h d o our co fere ce eve b e di g he agi e le der hip summi t ki g agi i

o he nex leve . Joi our peer d gi e i du r ve er o exp ore he u ique ch e gef ci g of w re deve opme e der gi e pr c ice move i o he m i re m. you he r wh worki g d o worki g d h ve he oppor u i o h re our experie ce d ucce e .

. q .c m/ p t RegisteR by apRil 9, 2010 and save up to $400!

Popular Tutorials Include:

aDapti g agi : a Guid t i i i g

e u p j c succ wi h sc umth righ W y

r i g l g -sc agi p j c

G i g agi wi h sc um

W i i g eff c iv agi U C

agi r p i g, M ic , d r c iv

sy m thi ki g f l d agi G w h

agi e im i g d p i g

p i ci d p c ic f l -agi D v m

agi p j c p i g: bui di g s g b ck g

tr n on ng o ag e

ag e i p e en on

scru

an much more!

ag e deve op en techn que

ag e te ng


29/49

I S T O

C K P H O T O



30/49


Early in my testing career , I discovered exploratory testing (simultaneous testdesign, execution, and learning [1]) and tried to practice what experts recommendedin their articles. I thought I was applying their ideas as best I could, and I knew whatI was doing would be called exploratory testing, but I was concerned. I wonderedi I was missing something. I had this gnawing ear that I had misinterpreted or mis-

understood a key concept. In short, I lacked confdence in my exploratory testingapproach.You can imagine my surprise when I met exploratory testing trainers who were more

interested in my ideas and experiences than in my ability to recite theirs. Now that I mentorand train exploratory testers, I fnd that I, too, am more interested in other testers uniquepractices, ideas, and experiences than my own. Thats whats wonder ul about thinkingabout testing rom an exploratory perspective: It is human centered. Instead o dehuman-izing the tester by reducing testing to a clerical task or by trying to automate away testers,we embrace their unique skills and experiences and the value they add to our projects. Weuse both so tware and thinking tools to give testers more power, not diminish it.

Recently, a test manager approached me a ter an exploratory testing training course.Finally, I have words to describe what my team and I have been doing or years! she saidand thanked me or not making them eel stupid or being unconventional in their testingwork. Youre the frst consultant Ive talked to who didnt tell me I was doing it wrong.She wasnt doing testing wrongin act, the development team was delighted with theresults o her teams testing e orts. Trouble was, the consultants who had worked with herteam were uncom ortable with her exploratory testing approach and the testing styles herteam typically used. This is an important lesson: Just because an approach is unconven-tional doesnt mean its wrong.

Exploratory Testing StylesBecause exploratory testing has less visible structure or example, it lacks explicit steps

and expected resultsthe test execution is di erent depending on who is doing the testing.There are di erent styles and variations that o ten yield similar results. What ollows aresome styles Ive observed.

IntuItIve This is the most common style. Testers who havent learned specifc exploratory testing

techniques tend to do this naturally. When you ask them what they are doing when theyare testing in the absence o pre-scripted test cases, they may say, I dont know why I didthat, or that they are using their intuition. Intuition is just a ancy way o saying, I amdoing this because o the insight I have based on my experience and knowledge. It canappear to be random or chaotic, but when the tester is pressed or an explanation o whathe did, a structure and purpose emerge.

LearnIng domInant This is also very common. Even shops that insist that all their test cases be designed and

recorded prior to ormal testing use this exploratory testing style during test design. Whilewriting test cases, the test designers will try out new so tware or a new eature that theyneed to learn about. As they learn, they invariably fnd bugs. This is also true o automatedtesting. As the automators learn about the system, they o ten will use an exploratory ap-proach as they try to get the automation tool to interact correctly with the application.

The concept o touring [2] heuristics to learn about applications is becoming popular.Touring is a good test idea-generation activity. Testers create models o the so tware theyare testing or use mnemonics to help them look at the application in di erent ways. Thislearning about the application leads to bug discoveries and test ideas. Some examples in-clude creating coverage maps and ollowing them or using di erent kinds o touring in aheuristic. For example, James Bach talks about touring the application to see i you canidenti y all the eatures. Or, try using the so tware the way you imagine di erent users

would. Touring is a power ul tool or test idea-generation and discovery.


31/49


SyStematIcMore advanced exploratory testing involves using a par-

ticular system, model, or strategy to guide your testing. This isdone to be more thorough in looking at and testing the system,and to be more consistent in our exploratory testing work.When I started working with James Bach, one thing he noticedwas inconsistency in my exploratory testing execution. I mightuse one set of test ideas and tools on one application but adifferent set on another. He taught me to use abstract models(see his Heuristic Test Strategy Model for more information)during test execution to guide my thinking and to help my ex-ploratory testing be more repeatable and consistent.

r egreSSIonYes, even exploratory testers have to do regression testing.

The difference between what scripted testers think of as re-gression testing and the exploratory testers version is in thelevel of guidance used. Exploratory testers often use light-weight coverage outlines as guidance rather than test cases.The guidance of the outlines helps ensure we can easily andfrequently repeat testing in desired areas. Using lightweightguidance with an exploratory approach to regression testing

can be quite effective. Stakeholders have a good idea of what

is being covered, such as features, functions, user scenarios,etc., while still allowing the test executors natural variationto discover problems quickly.

InteractIve automated /tooL Supported [3, 4]Exploratory testers often use automation tools to help

them. For example, if regression testing is becoming a burden,some aspects of testing may be automated. Task automationfocuses on speeding up activities like data loads or installingnew builds and can extend to test setup for exploratory testing

sessions. [5] These tests are run under the supervision and di-rect control of the tester who can step in and intervene manu-ally at any time.

Exploratory testers also use test automation that runs un-attended, particularly if the tasks are better served by a ma-chine than a human. The interactive part comes in when ex-ploratory testers use the tools to help them simulate differentkinds of conditions and then observe the results, change fac-tors, and rerun the tests.

Enough Words! How about a Picture?Most people who understand the unscripted, improvisa-

tional sense of exploratory testing but worry whether they are

Figure 1: Exploratory testing mind map


32/49


are de ned at a higher level than test cases, spelling out prod-ucts, areas to be tested, and lists o testing ideas. A tester mayrun one test in a checklist based on that idea, or he may runmore, depending on the task at hand, his schedule, and whathe discovers while testing.

Information Sources

We use all sorts o in ormation when testing. With experi-ence, we grow our own testing toolbox o ideas and tools,and we sometimes nd it di cult to explain where our com-piled knowledge comes rom. This knowledge comes romour testing experience, as well as books, Web sites, productin ormation, subject matter experts, other team members,and con erence, course, or workshop materials. It is pre er-able to use many rich sources o in ormation to help guideour testing. As in ormation providers regarding the quality o the product under test, any in ormation that helps us do ourwork is use ul. The richer our in ormation sources, the morein ormed our testing will be.

GuidanceWhen we test, we usually have some sort o guide. This can

be as simple as a bug report that we use or a bug x veri ca-tion, a test idea, or a test goal or charter or a testing session.Guidance can be more ormal in the orm o test checklists,coverage outlines, visual coverage, eature maps, or test cases.What we use or guidance is in ormed both by our coveragemodels and our in ormation sources. For example, we mayhave a coverage outline or unctional testing that is in ormedby our own knowledge and experience, as well as by sourceso in ormation rom our project and rom external sources.This coverage outline will guide our testing.

Guidance also comes in the orm o experienced teammembers and outsiders who can help you and your team. Inmy work with testing teams, I help them develop skills andstrategies so they can accelerate their learning and reducetheir trial and error. Using outside expertise such as a trainer,article, concept, or coach can help. Also, look or expertisewithin your team. More experienced teammates are a wealtho in ormation and are great to bounce testing ideas o o .

Structured vs. UnstructuredStructured exploratory testing has more guidance and

more visible tools and documentation. For example, session-based test management [11] is a method or adding rigor to re-cording exploratory testing so it may be reviewed or audited.Instead o writing test cases in advance, testers take detailednotes while testing. These notes are collected, reviewed, andstored or audit purposes. At the other extreme, we may en-gage in unstructured exploratory testing, which is sometimescharacterized as ad hoc or jumping around the applica-tion to nd problems. Exploratory testing can be very un-structured or very disciplinedand it usually alls somewherebetween the two.

TechniquesSince exploratory testing is an approach to testing, not a

doing it right arent necessarily doing anything wrong; theymerely lack con dence. One way to banish a lack o con -dence is to develop your testing skills. Describing exploratorytesting can be di cult, but Ive ound the mind map in gure1 to be help ul. As you look through the mind map, does ithelp your thinking about exploratory testing? Can you iden-ti y areas that resonate with you?

I use this mind map to show that, although there may belittle visible evidence, exploratory testing still can be a dis-ciplined, structured orm o testing. Its just that the testerkeeps track o more o the structure and guidance in his head.Exploratory testing isnt just playing with a product untilit breaks, and it doesnt need to be a set o simple quicktests. O ten improperly characterized as super cial bughunting or quicktests [6], exploratory testing can, in act,take us ar beyond that.

Coverage Models When testing, we have some idea o coverage, or how

much we are going to test a product. Cem Kaner de nes cov-erage as the amount o testing done o a certain type.[7] We can expand that to the amount we are testing softwareusing different approaches . We reveal di erent in ormation i we test an application in di erent areas, in di erent ways, orwith di erent techniques and tools.

There are many ways o de ning coverage [8], which arecalled coverage models . A coverage model describes how youare going to test the so tware. Because testing rom di erentperspectives reveals di erent kinds o in ormation, its betterto use di erent kinds o coverage models than one singlemodel. [9] For example, we could use a requirements-basedapproach and de ne a certain amount o testing to veri y theso tware meets requirements. We could also determine cov-erage using di erent testing techniques, such as de ning cov-erage according to security, per ormance, accessibility, etc.and de ning an appropriate amount o testing in each area.We will usually use one model at a time when testing, but it isnot uncommon to change models on the fy.

Choosing appropriate models can be determined by howwe want to mitigate risk on a project or through other moti-vations. It depends on what our stakeholders are looking or.For example, with so tware startups, stakeholders o ten aremore concerned with how testing in ormation a ects theirability to sell their product (capitalize on potential rewards)than in direct risk mitigation.

James Bachs SFDPOT San Francisco Depot mnemonic[10] (an abstract model or testing) spells out six possiblemodels o coverage or exploratory testers: the structure o the application, its function , the data it uses, the platforms itruns on, the operations its users typically engage in, and theimpact o time on the system.

One lightweight method o keeping track o what wastested and when is to use coverage outlines . Coverage out-lines are physical documents that o ten take the orm o checklists in a spreadsheet or visual diagrams that show userfows through the system. Their purpose is to direct and guide

testing and to communicate what was tested and why. They


33/49

technique [6], any testing technique can be utilized i it helps.Classic analysis techniques such as boundary value analysis,equivalence class partitioning, root-cause analysis, classifca-tion trees, and others can be applied to exploratory testing. I a technique helps you generate testing ideas that lead to bettertesting, use it. An exploratory testing approach can be usedwith any kind o testing technique, such as per ormance, load,

unctional, usability, accessibility, security the list goes onand on.

SkillsIt is di fcult to narrow down a short list o skills use ul

or so tware testing. Ive worked with a lot o di erent tes-ters with di erent skill sets, and the testers tend to draw ondi erent areas o experience. I see the ollowing skills mosto ten:

Strategic thinking: Pick an area o ocus and adjust testingto provide in ormation in areas that yield the most use ul in-

ormation. Idea generation: Exploratory testers need to be able to

think o di erent ways to test the so tware in the moment.I they see something strange, they adapt their testing. Thistakes practice, and to do it well, testers use mnemonics to helpremember di erent strategies and techniques.

Investigation: Analyze the product and the space in whichit operates, fnd areas o interest, and explore those areasusing tools, processes, and testing techniques to reveal use ulin ormation.

Communication: Its important to remember what youdid (i you didnt record a testing session) and explain yourstrategy and what problems you ound. I we discover im-portant in ormation but cant communicate it in a variety o ways, that in ormation doesnt help the team.

I tend to talk a lot about exploratory testing as investiga-tion (something I picked up rom Cem Kaner) and related in-vestigational skills. Technical skills that we develop on so t-ware teams rom programming to technical writingare anatural ft. Skills related to understanding the business, ourcustomers, and how they use our so tware are also very use ul.Ive seen wonder ul testing rom ormer orensic accountantsand stock traders. Both pro essions attract natural investiga-tors who are taught to assess systems rapidly and listen totheir gut eel or intuition.

OutputsWhen we test, we discover in ormation that stakeholders

on the team need to help make decisions about the so tware.We provide in ormation to other stakeholders in many ways:

Bug reports: Typically distributed to the technical team,bug reports need to be well written so programmers can easilyreproduce and fx the bugs.

Notes: Personal notes help us as we make our testing ob-servations visible and help us create reports that can be sharedwith our teammates.

Session sheets: Descriptions o testing activities capturedduring session-based exploratory testing can be used in regu-

lated environments and can be used to help review our work

with colleagues to see i we have overlooked anything. Withteams that use both exploratory and scripted testing ap-proaches, session sheets and personal notes can help in testcase creation.

Status reports: From low-tech testing dashboards [12] toverbal reports to stakeholders, communicating status helpsthe rest o the team understand what we have tested and the

state o the application under test.Test coverage reports: Stakeholders want to know howmuch testing o a certain type we have completed. Histori-cally, we have counted test cases, but using multiple models o coverage and explaining what we actually worked on duringtesting can provide richer in ormation than bug counts orpass/ ail metrics.

Quality criteria: Its important to have measures to deter-mine whether we are making our quality commitments withour so tware. For example, HP has used the FURPS+ modelo quality criteria. [13] When using these sorts o models, wecan report the unctional applicability o the system undertest and the usability, reliability, per ormance, and supportmeasures that we have agreed on as a team.

Blocking issues, problem areas: Its important to raiseawareness to decision makers when we are unable to com-plete aspects o our work. Its also very important to providethem with a sense o our qualitative impressions o the prod-ucts we are testing.

Effort and priorities: We cant test everything, and we areusually on a time budget, so we need to express what we havetested and what we think we need to test. We also need todemonstrate a sense o priority.

Our testing outputs are our only visible work productsthat other team members can see. We need to put e ort intodetermining what others need, be accountable or our work,and provide stakeholders such as programmers, managers,and decision makers with the in ormation they require. I thestakeholders are concerned with our approach, we need toadjust and provide them with what they need.

Ultimately, exploratory testing is determined by the mindo the tester who is doing the testing, and, as a result, it isinterpreted in many di erent ways. Dont let ear, uncertainty,and doubt get in the way o your testing. Instead, use explor-atory testing re erences to help guide your skill developmentand share your experiences with others. Sharing our ideasabout testing, inviting scrutiny, and making our testing ap-proach de ensible are important. I your team appreciatesthe testing in ormation you provide, dont worry that youredoing it wrong. I you are practicing your exploratory testingapproach and your testing is adding value to your teams e -

orts, you are doing it right . {end} [email protected]

For more on the following topic go towww.StickyMinds.com/bettersoftware.n References



34/49


35/49

I S T O C K P H O T O

Teams using a sequential development processhave become accustomed to hando s betweenspecialists. Analysts hand their work to designers,who hand it to programmers, who pass it on to

testers. Teams that are new to Scrum o ten do not go arenough in eliminating these hando s, wrongly assuming, orinstance, that the programmers should fnish programming aproduct backlog item be ore handing it o to the testers orthat analysts should work at least one sprint ahead o the resto the team.

High-per orming Scrum teams, however, have learned todo a little bit o everything all the time during a sprint, therebyeliminating large hando s. To do this e ectively, teams mustmake three changes: avor talking over writing, make hand-o s very small and very o ten, and mix the size o items thatare brought into each sprint.

Stop Writing and Start TalkingTheres a grand myth about requirements: I you write

them down, users will get exactly what they want. Thats nottrue. At best, users will get exactly what was written down,

which may or may not be anything like what they really want.As such, Scrum teams orego a lengthy, up- ront requirementsphase and the resulting product specifcation in avor o a dy-namic product backlog.

Because Scrum teams shi t ocus rom writing about re-quirements to talking about them, conversations with theproduct ownerrather than a product specbecome the pri-mary way o fnding out how a new eature should behave.Team members talk with the product owner about how a

eature should work, how quickly it should per orm, whatacceptance criteria must be passed, and so on. Scrum teammembers also talk with users, customers, and other stake-holders as appropriate and, perhaps most importantly, witheach other.

On traditional projects, analysts o ten act as intermediaries,communicating customer needs to programmers. On Scrumteams, however, analysts unction as acilitators, ensuring thatappropriate discussions between team and product ownertake place. For instance, an analyst might steer the productowner and team toward talking about a particular user storybecause it has more risk than another o going astray. At other



36/49


times, an analyst might convey a top-level understanding of anew feature to the team before bringing the team and productowner together to discuss the details. In all cases, analysts onScrum teams foster communication rather than distill infor-mation through a document.

All of this is not to say we should abandon written require-ments documents. Rather, we should use documents whereappropriate. Experienced Scrum teams lean heavily on cleanlywritten code and automated test cases. They then augmentthese forms of documentation with a written requirementsdocument only to the extent that such a document is helpfulor required for regulatory, contractual, or legal purposes. AsTom Poppendieck, coauthor of books on lean software devel-opment, once told me, When documents are mostly to en-able handoffs, they are evil. When they capture a record of aconversation that is best not forgotten, they are valuable.

Transfer Small Tasks FrequentlyOn Scrum teams, the unit of transfer between disciplines

should be smaller than an individual product backlog item.That is, although there will always be some handoffs, the

amount of work being transferred from one person to thenext should generally be as small as possible.

As an example, suppose a team is developing a new eCom-merce application. The team chooses to work on this userstory from its product backlog: As a shopper, I can selecthow I want items shipped based on the actual costs of ship-ping to my address so that I can make the best decision. Atthe beginning of the sprint, those who are interested in orwho will be involved in developing this feature begin to dis-cuss it. Lets suppose this group includes the product owner,a business analyst, a tester, and a programmer. They begin bytalking about some of the general requirements implicit in thisfeature: Which shipping companies (FedEx, DHL, etc.) do wesupport? Do we want to support overnight delivery? Two-daydelivery? Three-day delivery?

As these discussions occur, the individuals involved naturallywill begin thinking about how to get started. On a traditionalproject, each person would be able to start however he wanted(after the work was handed over). On a Scrum team, however,how to get started should be a collaborative discussion amongthose who will work on this feature. For this example, lets


37/49

assume that the programmer or some reason makes the casethat it will be easier to start with FedEx. The tester agrees. Theanalyst states an intention to investigate DHL and learn moreabout the parameters that a ect DHL shipping costs. The ana-

lysts goal is to have that in ormation available by the time theprogrammer and tester nish with FedEx.

When the programmer knows enough to get startedcoding, she does so. The product owner, analyst, and testerdiscuss high-level tests (Will our site ship any odd-sized itemslike skis?). A ter that discussion, the tester turns the high-levellist o tests into concrete tests (boxes o this size and weightgoing to that destination). The tester creates test data and au-tomates the tests. Some automation may be possible withoutany interim deliverables rom the programmer, while ull au-tomation may require getting an early version rom the pro-grammer. While the tester is thinking o the concrete tests, he

also should in orm the programmer o any test cases that shemay not be considering while shes programming.When the programmer and tester have nished, they add

support or calculating FedEx shipping costs into the build,complete with automated tests. Graphically, this can be de-picted as shown in gure 1, where our individuals work to-gether on one product backlog item rather than handing it o to each other.

Next, the programmer and tester check in with the businessanalyst, who hope ully has learned more about calculatingDHL shipping costs. The process is repeated, and support orDHL shipping calculations is added to the application whenthe programming and testing are complete. The key elementin gure 1 is that the team has learned to work by doing alittle o everything all the time. Rather than an analysis phase(done without the programmer and tester) ollowed by a pro-gramming phase ollowed by a testing phase, a little o eacho those activities is happening at all times.

A symptom o continuing to hand o work in overly largechunks is a tendency or no product backlog items to be n-ished until the last ew days o the sprint. Testers on teamsthat work this way o ten complain that they are given nothingto test until two days be ore the end o a sprint and then are

expected to test everything that quickly. The best way to ex-pose this problem is to create a chart o the number o productbacklog items nished as o each day in the sprint. An examplecan be seen in gure 2a. As the ScrumMaster on a team, I

o ten just hang this chart in the team area with no an areor explanation. Team members soon gure out the problemexposed by a chart like this and, hope ully, start to nd waysto nish product backlog items sooner. The result o ten willbe similar to gure 2b, which shows a much smoother fowthrough the sprint.

Create a Manageable MixWhen planning a sprint, teams should pay attention to the

sizes o the product backlog items to which they are commit-ting. Some product backlog items are more complex than theFedEx/DHL example given. Its possible that some productbacklog items might require a week or more o program-ming be ore a programmer can provide a tester with some-thing even initially testable. Thats OK. Not everything canbe split as small as we might like. The key is to avoid bringinga bunch o items like this into the same sprint. Doing so willshi t too much testing work to the end o the sprint.

Instead o planning a sprint with, or example, three verylarge items that cannot be partially implemented, bring oneor two such items into the sprint along with two or threesmaller items. Some o the programmers can work on thelarge items, handing them over to testers whenever possible.The remaining programmers can work on the smaller items,ensuring a somewhat smoother fow o work to testers earlyin the sprint.

Creating the right sense o teamwork can be challenging.ScrumMasters can help by ensuring that the team embracesthe concept o whole-team responsibility and whole-teamcommitment to deliver working so tware at the end o eachsprint. Though the team might struggle at rst to break long-held habits o specialization and hando s, increasing commu-nication, decreasing the size o hando s, and mixing the sizeo backlog items brought into a sprint will help individualsmake the shi t rom sequential development to working as ateam. {end}

[email protected]

Figure 1

Figure 2

A symptom o continuing to hand o work in overly large chunks is a tendency

or no product backlog items to be fnished until the last ew days o the sprint.



38/49

Software

teStingAnAlysis & Review

T h e G r e a T e s T s o f T w a r e T e s T i n G C o n f e r e n C e o n e a r T h

September 26October 1, 2010San Diego, CaliforniaHilton San Diego Bayfront

Choos f om a f w k of a n n , n wo k n , and mo Sunday Multi-day Training Classes begin

Monday tueSday In-depth half- and full-day TutorialsMulti-day Training Classes continue

wedneSday thurSday Keynotes, Concurrent Sessions, the EXPO, Networking Events,Receptions, Bonus Sessions, and more

friday Testing & Quality Leadership Summit

regiSter by july 30, 2010 and SaVe uP to $400.

grouPS of 2 SaVe eVen More!

www.sqe.com/starwest


39/49


Together

I S T O

C K P H O T O

Working

Not Just Working Together

by Johanna Rothman


40/49


S ophie strode down the hall to Randys o -fce. Randy, what is this? she asked as she waveda shea o papers.

Randy looked up and said, I have no idea. Whatare you waving around?

Your plans or your group!Oh, my predicted project port olio

or the next six months?Yes! When were you going to talk

to me? Im the development manager!I youre not testing the systems weredeveloping, what the heck are youdoing?

Well, this is what Ive been tryingto discuss with you or the past ewweeks, but you havent made time tosee me. So, I thought Id publish myport olio and get your attention. Itworked, eh?

Sophie and Randy are working to-gether, but they are not collaborating.

Collaborationthe ability to work jointly with othersissomething we talk about a lot. We demand it in job descrip-tions. We assume the people who run the business do it. Weexpect it o teams. But, how do people really collaborate?

Assuming you can get people to sit down together, a goodway to think about collaboration is to think frst about thesteps to collaboration.

Steps to CollaborationIn Building Trust in Business, Politics, Relationships, and

Life , Robert C. Solomon claims there are fve steps to buildinga trusting relationship, as shown in table 1.

Notice that the last step is extending trust. Sophie is surprisedby Randys plans. He is promising to deliver some workjustnot the work she wants done. But, Sophie hasnt been consis-tent in her actions and reactions, because she hasnt made timeto work with him. I she re uses to make time to work on the

port olio with Randy, she hasnt been trustworthy.

Barriers to CollaborationIn my experience, team size matters, too. I you have a

small team ewer than ten peopleyou have a good chanceo making collaboration work. But, i you are trying to getten or more people together to collaborate, its much harder.

Thats because its just about impos-sible to create a team o ten or morepeople. Groups o more than ninepeople splinter into smaller groups o three to seven people.

In addition to team size, there areseveral barriers to collaboration thatorganizations imposeperhaps unin-tentionallyon people:

Playing a zero-sum game: A zero-sum game is a game where one personwins everything while another personloses everything. When you rank proj-ects, there is only one No. 1 project. Ina real sense, one project wins and theothers lose. Thats the only zero-sumgame you want to play in an organi-

zation. Otherwise, you are not optimizing the work at thehighest level. I people cant decide which projects are rankedfrst, second, and third, they are preventing the organization

rom making progress. In that case, your competitors win. Hiding information: Sometimes, people think that i they

keep in ormation hidden rom others, they can enhance theirposition in the organization. And, or a short time, they maybe able to do so.

But, in the long term, hiding in ormation prevents peoplerom collaborating. Remember, although you might be nego-

tiating with a peer about a problem, its in the organizationsbest interests to have all the in ormation out and available.

Incentives prevent teamwork: Ive worked with managerswhose salespeople were paid when an order was booked, notwhen it was shipped. There was no incentive or salespeopleto sell what the development team had already created. In

act, there was tremendous incentive to sell new things that

hadnt been invented yet.

I people cant decidewhich projects are ranked

frst, second, and third,

they are preventing

the organization rom

making progress.

Table 1


41/49


Rewind Randy and SophieOnce Sophie realized shed ignored Randy, she decided to

make the e ort to collaborate on the project port olio.They picked a mutually convenient time to meet. They

each considered the principles behind their decision making.Luckily, they did have a common goal. They discussed howto make the entire organization success ul with their plannedport olio, and they agreed on when to review the port olioagain.

As Sophie and Randy worked through their plans or thenext quarter, they kept reminding each other about pendingdeliverables and showing each other their progress. When oneo Sophies projects encountered trouble, she explained theproblem to Randy. They were able to make other plans andmanage the problem.

Once they realized the power o collaboration, Sophie andRandy brought in others across the organization, not onlyto manage the project port olio but also to collaborate onproduct roadmaps and do a little strategic planning.

It doesnt matter where you are in the organization; col-

laboration is necessary. I youre a tester, you need to workwith developers and vice versa. I youre a product owner, youneed to work with your users. I youre a manager, you needto work with your teams. The higher the stakes, the more col-laboration will help you. {end}

[email protected]

Youve probably met project managers who had manage-ment by objectives (MBO) that only dealt with the projectsrelease date. Those project managers worked with develop-ment managers whose MBO were about eatures and withtest managers whose MBO were about de ects. They have noincentive to collaborate in this situation. In act, it is not inanyones interest to collaborate. Except or the poor customerwho desperately wants them to collaborate.

Decisions dont stick: Its even worse when a group o people get together, make a decision (or several decisions),and then someone with more positional power changes thatdecision. Who wants to bother collaborating in that situa-tion? Any decision you make is as likely to get thrown outas stick.

The time-space continuum prevents true collaboration:Many o you work in geographically distributed teams. Youknow how hard it is to collaborate on product developmentwhen you are not in the same place. Its even more di fcult

or managers to collaborate on decisions when they are not inthe same place.

One CIO had fve remote teams run by directors: two inthe US, one in the UK, one in Poland, and one in Bangalore.Each director had his own MBO, which was not in concertwith the others, and they never met as a group. Some subseto directors would get together and make a decision; the nextday, when the others met, they made a di erent decision.

The CIO had fnally had enough. I want you olks towork together on this! he mandated. Once he called themeeting, the directors were fnally able to air their concernsand explain why theyd made their original decisions. Collabo-ration cannot occur without interaction among all the playersat one time.

Real Collaboration Can Produce Team Flow

When people collaborate, you can see the team members get into fow. I once worked on a large project where we all

had the same vision o the product; we all worked together, delivering small, working chunks o code into the code base;

we had demos or one another; and we treated one another with respect and had a great time.

We were in team fow. Because we had small, requent deliverables, we could see how each person delivered on a daily

or almost-daily basis. Because we had the same vision, we were able to be consistent in our actions and reactions. Any

time anyone outside the team asked us to cut corners (this is where integrity is key), we had our vision against which to

check our work. And, even though we had plenty o disagreements, we stuck to a principle, rather than to a position. We

delivered a new so tware-hardware combination product in nine monthsa record or the organization.

Watch out or the inadvertent organizational barriers to collaboration. And dont just work togethertry real

collaboration.

For more on the following topic go towww.StickyMinds.com/bettersoftware.n Re erences


42/49

Product Announcements

BambooRMRESTON, VABamboo Solutions has announced that it islaunching BambooRM, a SaaS-based requirements manage-ment program that requires no installation, is easy to use,connects workplaces all over the globe, and is available viamonthly subscription. BambooRM allows project managersand teams to collaborate on projects more easily with one re-pository o project requirements.

BambooRM simpli es requirements management by inte-grating use cases and business and unctional requirements allin one place. Managers, business analysts, consultants, andteam leaders can view, manage, and trace project require-ments online in their browsers, including:

Creating business requirements for any product or ser-vice

De ning and associating sub-level business require-ments

Associating use cases with multiple associated business

requirements Associating functional requirements with each business

requirement Prioritizing business and functional requirements Tracing the project requirements Creating and printing requirements with easy-to-read

summaries

For additional in ormation, visit bamboosolutions.com.

End-to-End Application LifecycleManagement Solution

CINCINNATI, OHSeapine So tware has released its ALMsolution, which streamlines development and QA processes toimprove so tware quality, increase productivity, and lower de-velopment and business costs.

Seapines ALM solution includes TestTrack RM or re-quirements management, TestTrack TCM or test case man-agement, TestTrack Pro or issue and de ect management,Surround SCM or so tware con guration management, andQA Wizard Pro or automated unctional and regressiontesting. TestTrack RM, the newest addition to the SeapineALM product amily, enables development teams to manageall aspects o requirements including planning, traceability,

impact, review processes, measurement, and reporting.Seapines ALM solution includes scalable, eature-rich,team-based tools that can be used separately to manage eachcritical phase o the development li ecycle or seamlessly inte-grated to ensure quality at every stage o development. Thesetools are cross-plat orm and built on fexible architecturesusing open standards to support todays popular developmentmethodologies and industry best practices. Seapines ALMsolution gives todays organizations the collaboration, work-fow automation, reporting, security, and extensibility capa-bilities to streamline communications, improve traceability,and make development and QA teams more productive.

For additional in ormation, visit seapine.com/products.html.

Concerity AnalyticsSALT LAKE CITY, UTConcerity has announced the reebeta launch o Concerity Analytics, a new type o integratedtoolkit designed speci cally to help so tware companies mea-sure real-world usage o their so tware applications.

Designed initially or Windows desktop and ASP.NETso tware products, Concerity Analytics allows independentso tware vendors to gather key data on how their so twareproducts are used in the eld by end userseither in a testenvironment or in production.

Concerity Analytics provides so tware companies and in-house so tware teams with the ability to:

Measure and optimize feature usage Understand beta tester behavior Track, understand, and improve product quality Prioritize product development efforts Track and validate marketing programs (including

conversion strategies or trialware)

Proactively determine where support needs are highestand thus lower support costs

Increase engineering return on investment Outmaneuver the competition through faster, smarter,

and more e ective use o resources

For more in ormation, visit concerity.com.

Coverity 5SAN FRANCISCO, CACoverity, Inc. has unveiled Coverity5, the industrys rst so tware integrity o er that automaticallyscans, prioritizes, and maps the impact o de ects introduced

by so tware changes. This new o er is speci cally designed tohelp development organizations mitigate the business risk o so tware changes across their entire product port olio.

The new Coverity 5 de ect impact mapping capability isthe rst to enable developers to automatically map and iden-ti y how a single de ect impacts multiple code bases, projects,and products across the port olio.

The new Coverity 5 uni ed de ect management inter aceis the rst to enable developers and management to review,prioritize, and triage their C/C++, Java, and C# de ects in asingle workfow, providing a single version o the truth or thestate o integrity across the entire product port olio.

Developer productivity enhancements: New, state-of-the-art code browser provides ad-vanced de ect drill-down capabilities, easy-to-use de-

ect markers, shared views, and in-line expansion intointer-procedural de ect details.

Advanced defect reporting provides an easy way totrack xed de ects, de ect trends, the overall state o in-tegrity across the entire product line, and evidence orde ect remediation or compliance reporting.

Robust scalability enhancements enable more concur-rent users and simultaneous analysis commits.

For more in ormation, visit coverity.com.



43/49



MINGLE 3.0SAN FRANCISCO, CAThe ThoughtWorks Studios teamhas announced that Mingle 3.0 is now available or down-load. The new eatures and enhancements in 3.0 continue toclose the collaboration and program management gap that ex-ists between business stakeholders, project managers, businessanalysts, QA, and development engineers.

Features include: New team collaboration features using Murmurs Powerful program management capabilities Usability and support enhancements in the Macro Edi-

tors that extend reporting eatures Clustering for larger deployments Support for Subversion 1.6.5 Other features to enable users to view and access devel-

opment data in new ways

For more in ormation, visit thoughtworks.com/studios.

ALM SOFTWARELAFAYETTE, CATechExcel, Inc. has announced it is o -

ering so tware developers a ree, ten-user license or DevSuite,its award-winning suite o ALM tools. The new 10-Users FreeProgram gives small development teams an excellent, no-riskopportunity to experience how the companys ully integratedset o enterprise-class tools can help them more e ciently ande ectively manage all phases o application development.

DevSuite is a ully-integrated ALM system consisting o TechExcels popular DevTrack or de ect and project tracking;DevSpec or requirements management; DevPlan or project

planning; and KnowledgeWise, a wiki-based knowledge man-agement system. Available as an integrated client/server andIntranet/Internet solution, DevSuite provides power ul work-fow and process automation, robust searching and reporting,and simple point-and-click customization. It also eatures anintuitive user inter ace, universal ODBC support, advancedemail noti cation, built-in time tracking, extensive customiza-tion options, and presentation-quality reports and graphics.DevSuite also enables so tware development organizations,regardless o size, to manage globally-distributed developmentteams e ciently and e ectively.

Managers interested in participating in the program can

register and download DevSuite to begin their thirty-day eval-uation and receive a ree permanent license or up to ten teammembers.

For additional in ormation, visit techexcel.com/products/devsuite/devsuite.html.

Agile Platform 5.0SAN RAMON, CAOutSystems has released the new AgilePlat orm 5.0. Agile Plat orm integrates the two li ecycles o application development and business process managementwithin a single, power ul environmentenabling the automa-tion o business processes and delivery o fexible Web appli-cations that are built or continuous change.

With this version, OutSystems extends the Agile Plat ormsexisting capabilities or building rich Internet applications byadding a new business process technology layer, enabling ITorganizations to model, integrate, deploy, execute, monitor,and optimize human-to-system processes that are 100 percentin sync with the applications that support them.

The new EPA technology allows simpli ed deployment o process de nitions with innovative support or automatinghuman-to-system interactions. A new TaskBox eature al-lows organizations to streamline the deployment o new andchanged business processes with automatic task noti cation,intelligent workfow support, and process documentation atusers ngertips.

Agile Plat orm 5.0 eatures include: Supporting in- ight validation Copy and paste across a wide range of model objects Improved support for Web service integration Simpli ed support for the delivery of multilingual ap-

plications

For additional in ormation, visit outsystems.com.

Parasoft C++testMONROVIA, CAParaso t Corporation has announced therelease o Paraso t C++test, an integrated solution or auto-mating a broad range o best practices proven to increase so t-ware development team productivity and so tware quality orC and C++. In this new release, Paraso t signi cantly expandsthe scope o C++test with the introduction o integrated run-time memory analysis that is suitable or both enterprise and

embedded development.New capabilities or reducing the risks o C and C++ so t-

ware development: Runtime memory analysis enables teams to automati-

cally identi y serious runtime de ectssuch as memoryleaks, null pointers, uninitialized memory, and bu eroverfowsduring execution.

Parasoft Concerto Task Assistant brings change-basedtesting and automated task management directly to thedevelopers amiliar work environment.

Extended environment and compiler support for ARM,Keil, IAR, Texas Instruments, QNX, AIX, and Eclipse

3.5 enables more developers to use Paraso t C++test asa seamless part o their development process.

To learn more, visit www.parasoft.com/c_cpp_testing.

TestRail 1.0Gurock So tware has announced the immediate availability o its new test management solution TestRail 1.0. TestRail is acomprehensive, Web-based test case management applicationto manage, track, and organize so tware testing e orts.

TestRail provides built-in solutions or managing projects,milestones, and releases, as well as test con gurations and ad-vanced testing scenarios.


44/49



Productivity- and team-related eatures such as personalized todo lists, emailnoti cations, and team conversations are a core concept o TestRail and integrateseamlessly with the daily workfow. The built-in reporting unctionality helps teamsget real-time insights into their testing process and progress.

For more in ormation, visit www.gurock.com/testrail/.

LISA 5.0DALLAS, TXiTKO has announced the general availability o its fagship LISAproduct suite version 5.0.

LISA 5.0 eatures include: Powerful and versatile virtual service environments. LISA captures and

models inaccessible or unavailable IT resources into virtual service environ-ments that produce the same dynamic behavior, per ormance, and data asthe real production systems.

Improved end-to-end transparency, automation, and validation. LISAsPath nder provides complete transparency to trace errors to their sourceacross complex architectures spanning multiple application tiers and het-erogeneous technologies.

New Path nder Pro streamlines defect collaboration with no new skills re-quired. LISAs new Path nder Pro builds upon Path nders transparencyand traceability capabilities by enabling ast, streamlined resolution o de-

ects without any new technical skills or processes required or develop-ment and quality assurance teams.

For more in ormation, visit www.itko.com/lisa.

ElectricCommander 3.5

SUNNYVALE, CAElectric Cloud has released ElectricCommander 3.5, a ullycustomizable and extensible version o its tool or automating and managing thebuild-test-deploy process in so tware development. Electric Cloud also announced

signi cant upgrades to ElectricAccelerator ( www.electric-cloud.com/news/2010-0216a.php).The customizability o ElectricCommander 3.5 simpli es so tware productionmanagement and removes the need or developers to learn and manage multipletools.

ElectricCommander automates and manages the error-prone, manual pieces o the build-test-deploy process, making so tware production aster and more e -cient. ElectricCommander 3.5, available immediately, integrates seamlessly into adevelopment teams current environment with ully customizable user inter aces,including dashboards and orms. Version 3.5 also provides the tools to create andshare custom plug-ins or smoother integration with application li ecycle manage-ment tools, homegrown tools, custom workfows, etc.

For more in ormation, visit www.electric-cloud.com.

Have news youd like to share?

Send your new product announcement to

[email protected]


45/49


by Claire Lohr

How can I ensure myrequirements are fully testable?

There is not just one answer to this question. Testability, like beauty, is in the eye o the beholder.It all comes down to success ul communication between the requirements initiator and the tester.

There is not one universal answer, because every pair o requirements initiator and tester is di er-

ent. The challenges acing testers can range rom very high integrity systems such as NASA on one

end, down to minimal-documentation agile projects at the other end, and everything in between. All

address the testability issue with di erent solutions.

NASA has answered this question by developing the Automated Requirements Measurement Tool

(satc.gsfc.nasa.gov/tools/download/). Traditional requirements documentation can be developed ollowing

the Std 830 IEEE Recommended Practice or So tware Requirements Specifcations . Use cases can bedeveloped using internal or UML standards. The agile community starts with user stories (described

by the Agile Mani esto). While these are the most popular requirements documentation techniques,

there are many more. Each type o requirements standard enhances the testability o the system by

providing the tester with more complete and correct in ormationthe standards are developed by

consensus and contain a compendium o use ul in ormation rom many experienced practitioners.

The ollowing techniques can acilitate the testing process within any documentation or tool ormat:

Include quanti cation in each requirementuse actual numbers or the words an

none. Avoid vague terms such as user riendly.

Include visual representationsmany humans are visual learners; they understand pic

better than words. Techniques such as the decision table, state transition diagrams, and the

model in use cases all provide visual representations.

Expect to develop requirements iteratively. Do the iteration then have the peer review-

throughs or inspections) and expect updates throughout development.

Collect metrics to show the rewards of early requirements correction and the cost of-

ing the requirements defnition phase o the li ecycle.

Build a team with a variety of skills (e.g., testing methodology, business analysis, to

and keep team member morale as high as possible.

Have online examples with blank templates and good examples from real projectsteam members to use as models.

Use more than one technique.

Get both your testers and business analysts certi ed, as the pre-exam preparation wi

the most important requirements and testing techniques and issues.

Cra ting testable requirements is part art and part science. There are a lot o help ul tools and tech-

niques available to guide your requirement creation, helping to ensure a high level o clarity and

testability.

[email protected]


46/49


Career Development

is one place that its actually necessary or you to expound onthe great work youve done. I you managed a project thatcame in $2 million under budget as a result o your leader-ship, say so. In Michaels experience, identi ying tangible re-sults, such as reduced de ects by 10 percent, or otherwisedefning accomplishments that provided an organization timeor cost savings is a good way to make a positive impact on thehiring manager.

Michael also has an eye or detail.Rather than just saying implementeddriver code in C, he says, I am moreinterested in a candidate that tells a bitmore o the story, such as implementedIEEE-1394 driver in C, and partici-pated in unit test and integration o thedriver with the product lineup.

Proofread before you send: Typos andmistakes arent necessarily a deal breaker,

but they can a ect your chances o landing the job you want.Too many grammatical errors or sloppy mistakes will likely

cause the rsum to head toward the discard pile, Michael says.While I wont discard a rsum automatically because o oneor two errors, i it appears that the rsum was not read throughprior to submitting, then it likely would be discarded.

While a ew mistakes may not disquali y you or somepositions, a typo-riddled rsum can a ect the perception o your ability to per orm well in certain jobs. For example, atester who hasnt taken the time to run spell check is not likelyto be the top contender or a QA position, as the hiring groupmay eel that quality is not her highest priority.

Keep it short and sweet: There are a lot o people lookingor jobs these days and not a lot o companies that are hiring.

So, when a position does open the manager is going to beswamped with rsums. The volume o applicants normallyprecludes a manager rom spending more than a ew secondsscanning your rsum or applicable skills. I those skills arenot highly visible, your rsum likely is headed to the trash.

In the age o word processors, it is airly easy or a can-didate to present a tailored rsum or a job description thatshould emphasize their most relevant skills and experiences

or that position, Michael says. To me, it eels like a lack o e ort to receive a nine-plus-page rsum with lots o genericexperience or a specifc job position.

The reality o a job search is that candidates should maketheir relevant experience jump out at the reviewers, and notexpect the reviewer to scrutinize a long rsum to extract de-

Even i you werent one o the millions o people aced withlayo s this past year, its always a good idea to keep yourrsum up to date. You never know when opportunity maycome knocking or youll fnd yoursel unexpectedly ex-ploring a di erent avenue.

Your rsum can make or break you as a candidate or ajob. So, its wise to make the time to put together thorough,organized documentation o your skills, accomplishments,

and experiences.A rsum is a marketing tool, but its

important to remember that its not allabout you. Its an opportunity to showa potential employer that you are theone person who has the skills needed tofll the open position and add value toher organization.

Two important things you can doto increase your odds o landing aninterview are: make sure your rsum explicitly defnes yourexperience, be it as a tester, developer, manager, or business

analyst; and tailor your rsum specifcally to the job youseek. Potential employers want to know at a glance that youhave the skills needed to do the job. I a hiring manager hasto wade through ten pages o unrelated work history to fndout whether you have Java experience, chances are good yourrsum will end up in the trash.

Five Tips for Attention-grabbing RsumsSo, what can you do to escape the dreaded shredder and

get some ace time with the hiring team? These fve things canhelp you set your rsum apart.

Tell them what they need to know: The most e ective r-

sums ocus on a specifc job title and address succinctly theemployers stated job requirements. Michael Kahn, a so twarepro essional with nearly twenty years o experience and au-thor o The Software Hiring Handbook: The Software Devel-opers Guide to Conducting a Job Interview , says he likes tosee evidence o an applicants experience level with a certainskillrather than a vague buzzwordexplicitly addressedin a rsum. I I need someone to maintain and develop anXML parser, then having a statement on a rsum such as in-ter aced with an XML parsing engine or worked with con-fgurations stored in XML ormat is more meaning ul thanmerely listing XML in a laundry list o keywords o skills.

Highlight your accomplishments: Many people are un-com ortable patting themselves on the back. But, your rsum

The Unshreddable RsumThese days, competition is sti or the ew job openings available. These fve

tips can help keep your rsum out o the trash and get your oot in the door.by Heather Shanholtzer | [email protected]

A rsum is a marketing

tool, but its important to

remember that its not all

about you.


47/49


Career Development

tails that are buried on page our or beyond.Show you play well with others: With more organizations

adopting agile methodologies and the increase in globally dis-tributed teams, it has never been more important or you todemonstrate your ability to work closely with others. Whenreviewing your rsum, a hiring manager will be looking orevidence that you are a team player. In todays workplace,Michael says, a majority o so tware positions require teamskills, so any statements that indicate team involvement (e.g.,leading a team or inter acing with multi-discipline teams suchas hardware, QA, etc.) are generally viewed as positive.

Tailor Your Rsum to Your Job FunctionIn addition to the ideas discussed above, what specifc

in ormation should a tester, developer, manager, or businessanalyst include on her rsum that will show a hiring man-ager that this applicant is the right choice or the position?

Johanna Rothman, an accomplished management consul-

tant and author o several books, including Hiring the Best Knowledge Workers, Techies & Nerds , suggests an applicantconsider the ollowing questions when preparing her rsum.Answering these questions will help the hiring team determineyour potential value to the organization.

Testers: What new or innovative approaches have you used

that helped the test e ort discover more in ormation?Developers: How have you made changes that ft the

product? How do you know a design is good?Software Managers: How did you beneft your previous

organization? How did you help people do their best?Business Analysts: What problems did your work solve?

Further Steps to SuccessWhether you are recently laid o or you hope to land a

great new job when the economy turns around, a well-writtenrsum is going to be a huge actor in whether you get aninterview, but its not the only tool you need. Michael has acouple o suggestions or increasing your chances or a suc-cess ul job search. First, he says, nurture and maintainyour pro essional network. In this industry, as with others,many people know each other, and your network can helpyou fnd job openings be ore they are posted.

Michael also recommends staying abreast o new technology

while you are looking or work. With the advent o the Internet,and an open source project or just about anything, he says, itshould be possible to devote a little time to most any area o so tware and learn more about it. Learning a new scripting lan-guage is usually a good place to begin. For an out-o -work jobseeker, this independent study is time well spent. {end}

Better Software (USPS: 019-578, ISSN:1553-1929) is published six times per yearJanuary/February, March/April, May/June,July/August, September/October, November/December. Subscription rate is US $40.00 peryear. A US $35 shipping charge is incurred or allnon-US addresses. Payments to So tware Qual-ity Engineering must be made in US unds drawn

rom a US bank. For more in ormation, contactin o@betterso tware.com or call 800.450.7854.Back issues may be purchased or $15 per is-sue (plus shipping). Volume discounts available.

Entire contents 2010 by So tware QualityEngineering (330 Corporate Way, Suite 300, Or-ange Park, FL 32073), unless otherwise noted onspecifc articles. The opinions expressed within the articles and contents herein do not neces-sarily express those o the publisher (So twareQuality Engineering). All rights reserved. Nomaterial in this publication may be reproducedin any orm without permission. Reprints oindividual articles available. Call or details.Periodicals Postage paid in Orange Park, FL,and other mailing o fces. POSTMASTER: Sendaddress changes to Better So tware, 330 Cor-porate Way, Suite 300, Orange Park, FL 32073,in o@betterso tware.com.

Display [email protected]

All Other [email protected]

ADP West 2010 www.sqe.com/adpwest 24

AutomatedQA www.automatedqa.com 19

Avnet www.avnet.com 31

Better Software Conference www.sqe.com/BSC 12

Better Software magazine www.bettersoftware.com 23

BugHost www.BugHost.com 41

Codenomicon www.codenomicon.com 22

Hewlett-Packard www.hp.com/go/agile Back Cover

McCabe www.mccabe.com 15

Microsoft www.microsoft.com Inside Front Cover

PureCM www.purecm.com 18

Rally Software www.rallydev.com/bsm Inside Back Cover

Ranorex www.ranorex.com 9

Seapine www.seapine.com 1

SQE TrainingeLearning www.sqetraining.com/eLearning 16

SQE TrainingLive Virtual www.sqetraining.com/VirtualTraining 6

STARWEST 2010 www.sqe.com/STARWEST 35

TechExcel www.techexcel.com 2

ThoughtWorks www.thoughtworks.com 5

Web Performance www.webperformanceinc.com 10

index to advertisers


48/49

Our business is dependent on tight turnaround times. Rally makes it easy

to juggle scope, hours and resources, so we can share up-to-the-minute

project information with all of our stakeholders . Everyone can see

priorities, status and roadblocks to save time and money.

www.rallydev.com | 1.866.348.1552 | [email protected]

SCALING SOFTWARE AGILITY 2010 Rally Software Development Corp

See how development organizations like Erik's are deliveringsoftware the Agile way: www.rallydev.com/videos/

We need to make sure thatour company's most important

Documents

sqe_bettersoftware_0310