Tackling Software Testing Testing Challenges in the Agile Era

Chapters:About the Authors

Vu Lam is CEO of QASymphony, a leadingdeveloper of Quality Management solutionsfor software developers and QA testers. Hewas previously with First Consulting Groupand was an early pioneer in Vietnam’so�shore IT services industry since 1995.

An entrepreneur at heart, he started multiple technologyventures, including Paragon Solutions, a technologyconsulting company with international development centersin Bangalore, India, and Ho Chi Minh City, Vietnam. FollowingParagon’s acquisition by NASDAQ traded FCG, he led thegrowth of the organization from 400 to 1300 resources. In 2011,he co-founded QASymphony, a vendor of software testingtools, with Josh Lieberman. He holds a MS degrexe in electricalengineering from Purdue University. You may reach him atvulam@qasymphony.com.

Sellers Smith is Dir. Quality Assurance &Agile Evangelist for Silverpop of Atlanta,GA, a digital marketing technology providerthat uni�es marketing automation, email,mobile, and social for more than 5,000global brands. Prior to Silverpop, he led

technical implementation of new Internet business initiativesfor WebMD, ForestExpress.com, and the e-commercesite for NASCAR.com and GameTap.com. He has heldsoftware engineering positions at Turner Broadcasting, A.G.Edwards & Sons, and MITRE. Currently, Sellers is leadingthe implementation of Agile Testing practices includingAcceptance Test Driven Development, Speci�cation byExample, Test Automation using FitNesse and ExploratoryTesting. He has a MS degree in Software Systems Engineeringfrom George Mason University and a MBA in InformationSystems from Rensselaer Polytechnic Institute. You mayreach him at sellers.smith@gmail.com.

1. Reimagining the Tester for the Agile Age (Vu Lam)

2. Finding the Right Mix With Your Testing Methods (Sellers Smith)

3. Surprising Truth About Exploratory Testing (Vu Lam)

4. Building Good Tests: Why, What, How? (Sellers Smith)

Introduction

The testing industry is undergoing some rapid andfar-reaching changes driven by major shifts in thesoftware development landscape. Software is movingfrom concept to end user faster than ever before and thisthrows up a whole new set of challenges for testers. Thetraditional procedures and techniques that have servedQA departments in the past are no longer up to the job.The techniques and tools required for e�ectively testingmodern software has evolved way beyond the traditionalplan test – write test – run test model of yesteryear.

In this eBook we bring together the thoughts of a vendor-- intent on building something that truly speaks to theneeds of the modern tester -- with a practitioner fromthe testing trenches, to bring you a multidimensionalperspective on the issues testers are facing and how theymight be mastered.

We begin with a chapter on reimagining the tester forAgile. The Agile mindset has transformed how softwareis developed, but QA departments have been slow toadapt their own methodology. Testers are uniquelyplaced to serve as advocates for the end user. Testingpractices must be modernized; testers have to be in thedevelopment loop to gain the insight they need to teste�ectively, and realistic planning is paramount.

Our next chapter explores how testers need to identifythe right balance of testing methods if they are toestablish a comprehensive testing strategy. We discussautomated, exploratory, and user-acceptance testing,with advice on when to employ them and how to get thebest from each approach.

In the third chapter we drill down into exploratorytesting and analyze its origins to uncover its essence.The time pressures of modern development make itan indispensable technique. Continuous deploymentand the fast feedback loop which drives new features,necessitates a �exibility and focus that can be foundthrough exploratory testing.

The �nal chapter focuses on the practical side ofbuilding good tests by breaking the process down intoa deceptively simple trio of questions: why, what, andhow? By applying these queries testers can identify thevalue of individual tests to ensure that maximum valueis extracted from each new test cycle. This ability tocontinually reassess and refocus e�ort in the right placesis the key to delivering for the business.

QA departments are often left to their own devices.Excluded from exciting new developments and lastto the table for budgetary consideration, testers arebeing squeezed to deliver more with less. The testingcommunity has to get more active and vocal about thechallenges facing them. A love of the craft and realdedication is the �rst step towards challenging thatunderappreciated status.

We o�er this eBook in the spirit of opening a dialogue.The ultimate hope, which we’ll delve into in moredepth in our conclusion, is that the testing craft can beprofessionalized further. Good testers have key skillsand expert knowledge that’s in serious demand. Byadapting to seismic shifts in the wider software industry,developing new approaches, and �nding new tools,testers can stay relevant and e�ective.# # #

Dangerous AssumptionsIt should be obvious that Agiledevelopment completely disruptstraditional testing practices,yet many companies have donenothing to update processes orarm testers for the new challengesthey are facing.

Imagine a typical scenario on anAgile project with a team of �vedevelopers, and a pair of testers.From the development point ofview, �ve developers can workat a steady, measurable velocity,adding new features to each newbuild. But that simply isn’t truefor testers.

At �rst, testing each sprint is nota problem, because testers have alimited number of features to test,but as the software grows theyhave to test new features, verifybug �xes, and perform regressiontesting. Everything has to betested within the sprint timeline;the shorter it is, the more roundsof regression testing is calledfor. Soon, the test team is boggeddown and overloaded.

Automated Unit Tests developedalongside with the code helps torelieve some of the pressure, butthe workload for the testers stillremains high. How can the same

“The ideal tester is an advocate for the end user.”

Reimagining the Testerfor the Agile Age Vu Lam

CHAPTER 1

It’s been 12 years since the Agile Manifesto was created, and the majority ofdevelopers have jumped on the bandwagon since then. Agile methodologies arenow dominating the software development landscape. It has overtaken Waterfallas the dominant approach. But in the rush to implement the Agile mindset,something has been overlooked – the tester.

The focus on delivering a good product without endless documentation isundoubtedly a positive move for developers. By keeping the needs of the end userin sight at all times, and creating feedback loops, projects generally deliver bettersoftware, and faster than before. Given that the Agile method was conceived bydevelopers for developers, it left the testers in the dark. As a report from Forresterpoints out, Agile teams must invite testers to the table.

two testers cover all the newfeatures alongside �x veri�cationand regression testing? Theanswer is simple: they can’t.

A New ApproachIn order to ensure that the qualityremains high, managementcould scale up the test teamsigni�cantly as the developmentprogresses, but there is a muchmore cost-e�ective solution.Regression testing has to bedocumented and then automatedas you progress. There’s no wayto write up these test cases orscripts before the code hasbeen delivered.

New feature testing and bugvalidation is where youwant your testers to focus.You can avoid duplicatingwork by using the test �owthey are capturing as theytest to generate test casesthat can be used to automatethe regression testing forthe next build. It’s an all-at-onceapproach that requires testers tobe on their toes.

A New TesterFor Agile testing to work, testersneed to adopt the same Agilemindset as developers, butditching the traditional waterfallprocess for sprints does requiresome upfront planning.

Previously, the testers’routine involved reading andunderstanding requirements,writing test cases before thebuild arrived, and testing thesoftware when the build wasmade available. For the Agileproject, the tester cannot a�ordto write test cases before the buildarrives since there’s not enoughdetail available.

They need tools to support the waythey explore and test software in a�uid, unscripted manner. It shouldbe fast and easy to identify anddocument test cases for regressionand possible automation. Theyalso need a test management toolthat fully supports all the Agiletester’s tasks, not a tagged-onmodule to the development team’sproject management software.Something dedicated that canlink user stories and test cases,import and export bugs, and keepa complete record of the testingthat has been completed and whatthe results were. Something that’struly built for the Agile tester.

Time For Agile TestersSo much e�ort has been putinto creating Agile practices andtools for developers, isn’t it abouttime that testers were given dueattention? For all the good thatAgile development brings, it doesn’tdispense with the need for skilledtesting if you fully expect to deliveran excellent product for users.

Integrate testers into the Agileprocess from the start, equip themwith the right tools to help themdevelop exploratory skills anduse automation to cope with therepetition of regression testing,and you have yourself a tester forthe Agile age.# # #

There has to be a change inroutine: leverage Exploratorytesting to put new functionalitythrough its paces, write a limitedset of core test cases for futureregression testing, and automatethem as soon as the software inthat area is stable to reduce amanual testing burden.

In the absence of detailedrequirements and documentation,Agile testers must understandthe needs of the end user. It isvital they can put themselves

in the end user’s shoes and havea good understanding of exactlywhat they need from the softwareand how they are likely to use it.This means full participation inScrum meetings, absorbing userstories, and asking questionswhenever something isn’t clear.The ideal tester is an advocatefor the end user.

For Every Nail There’s A HammerLooking beyond the mindset, Agiletesters need the right tools forthe job. The vast majority of Agileproject management softwareignores the vital role of the tester.Test management solutions werecreated to support more traditionaltesting. In short, project andtesting software have not caughtup with the unique demands of themodern Agile tester.

QA Symphony | Reimagining the Tester for the Agile Age | Page 5

Automated TestingThe testing of every productwill start with some scripted,automated tests that are designedto exercise the system andvalidate that it works the way it issupposed to. Automated tests arerepeatable, fast, and they can berun as many times as needed.

To give an example, if you were totest an e-commerce shopping cart,you might have an automated testthat tries to add each individualitem in your store and check outsuccessfully. Does the cart addup the combined cost correctly?Is it possible to add each item?

Can you successfully completethe checkout process?

These are all useful thingsto know, but there are someobvious limitations. Automatedtests cannot go beyond theiroriginal scope. The lack ofhuman involvement means thatan automated test may run andsuccessfully add items and thencheck out, but it wouldn’t pick upon things like misspelled itemnames or stretched photos. If itwasn’t included as a parameterwhen the automated test waswritten, then it won’t be pickedup when it runs.

With the right balance of automated, exploratory, and user-acceptancetesting, QA teams can help build great products.

Finding the Right Mix withYour Testing MethodsSellers Smith

CHAPTER 2

Any comprehensive testing strategy is going to rely on the right mix of tests forthe product. There are various methodologies that can be employed, but ratherthan viewing them as separate, discrete approaches, it is worth remembering thatthey all lie on a common continuum. At one end we have mechanistic automatedtesting, and we pass through scripting, beyond exploratory testing, and on toprivate and public betas at the opposite end.

The testing journey starts from a tightly controlled base and winds its way towardsreal world conditions. We’re going to focus on three important stops along the wayin this article and explain a little about how they bring value to the process, whattheir weaknesses are, and how you decide when to use them.

Exploratory TestingWith any piece of software youcan use documentation, userstories, and conversations withkey stakeholders to determinehow a system should work. Thereare certain concrete rules to howthe software should behave andautomated or scripted testing cancater for those, but what happenswhen someone goes o� script?Exploratory testing is aboutcombining your knowledge andexperience as a tester with anunderstanding of what the productis supposed to do to uncoverpotential problems that automatedtests will not catch.

It goes beyond ad hoc testing,because there has to be a cleararea of focus and a predeterminedscope, but the tester is not boundby a check-list approach. Theycan delve into how the experiencefeels, unusual scenarios thatmay have been missed by thedevelopers, and leverage specialistknowledge related to the domainor industry that the software isaimed at. Using our shoppingcart analogy again they mightadd and then remove productsfrom the cart, test how it dealswith multiples, and see if theycan exploit the system to producenegative values and checkout witha refund.

User-Acceptance TestingThere is ultimately no substitutefor real world conditions. Youcan test a product professionallyfor months on end, but as soonas you release it into the wildyour end users will do a varietyof unexpected things with it.Whether you opt for a private beta,which involves inviting some ofyour prospective customers touse the software, or you open itup publicly and work fast to meetexpectations, you need to collect

adopters. Feedback from betausers is of limited value if primaryusage scenarios are not working.This approach can be usediteratively around release and orfeatures (for folks doing featurebaseddevelopment).

In short, start with a well-de�nedset of automated tests to validatecore business functionality, shiftto exploratory testing as the corefunctions are working, and thenbegin introducing real users asthe exploratory testing shows anacceptable level of usability.

# # #

this feedback before your productcan truly be �nished.

End users will always come upwith scenarios that developmentand QA didn’t consider. Withthe shopping cart, they might�ll it up and then come back aweek later with the expectationthat their shopping items willstill be waiting for checkout.Unencumbered by knowledge ofthe documentation, and not biasedby proximity to the project, endusers will try unusual things thatseem intuitive to them. That canbe great for discovering defects,but it also teaches you a lotabout expectations. This is howyour product will be used in thereal world.

Bringing It All TogetherThe exact mix of tests will varydepending on the type of systemand users. Generally, systems withheavy business logic are going tofavor more test automation (e.g.,veri�cation of business rules),while consumer-facing systemswill favor more beta testing.

As an example, Silverpopprovides marketing automationand email marketing in a SaaSmodel. The company focuses ona larger automation test suite,and does exploratory testing inorder to test complex usage of itsapplication. Silverpop has severalmechanisms, things like featureswitches and pilot environments-- to support beta users andearly adopters.

A good approach is to focus onautomated tests (or scripted tests),until you have a generally usableplatform. Exploratory testing is oflimited use if the basic featuresare not working. Once exploratorytesting is underway, you can focuson introducing beta user or early

QA Symphony | Finding the Right Mix with your Testing Methods | Page 7

What Is Exploratory Testing?Real exploratory testing is not thesame as ad hoc testing; it’s muchmore sophisticated and organizedthan that. The term was originallycoined by Kem Caner in his book,Testing Computer Software, todescribe an alternative approachto traditional formal planning. Heimplored testers to “Trust yourinstincts.” But he also warned thatyou should “always write downwhat you do and what happenswhen you run exploratory tests.”

Another author, James Bach,described exploratory testingas “scienti�c thinking in realtime.”In his 1999 paper, GeneralFunctionality and Stability TestProcedure, Bach expounded onthat, explaining that “unliketraditional informal testing, thisprocedure consists of speci�c

tasks, objectives, and deliverablesthat make it a systematicprocess…” and went on to say,“In operational terms, exploratorytesting is an interactive processof concurrent product exploration,test design, and test execution.The outcome of an exploratorytesting session is a set of notesabout the product, failures found,and a concise record of howthe product was tested. Whenpracticed by trained testers, ityields consistently valuable andauditable results.”

More than a decade has passedsince Bach wrote those lines,yet his wisdom is still lost onmany people.

The Surprising Truth About Exploratory Testing Vu Lam

CHAPTER 3

Exploratory testing is an important tool in any experienced tester’s kit.In the modern age of Agile development, with software being updatedand released faster than ever, exploratory testing is nothing short ofessential. The trouble is that there seems to be some confusion overwhat the term actually means.

When To Employ ItIt’s very common for testers to beunder time pressure, and the shiftto Agile methodology in softwaredevelopment has had a tangibleimpact on documentation. To put itsimply: testers have very little timeto test a new build and must oftendo so without access to detaileddocumentation.

Exploratory testing is ideal forthis scenario, but should notbe an exclusive approach. Itcomplements scripted testingactivities. Exploratory testingis simply part of an overall planthat must include new featureexploration, bug validation andregression testing.

If you’re not sure what to test next,or you want to dig deeper into acomplex piece of software, then it’stime for some exploratory testing.

How To Do It RightWhat you’re really looking to dois design and execute tests at thesame time. Although you won’tbe using requirements to preparedetailed test cases before you begin,that doesn’t mean you should testrandomly. There should be a focuson speci�c parts of the product, oran agreement to employ speci�cstrategies during the testing.Combine your intuition with theknowledge you have amassed onthe software from previous tests,and your perceptions about theneeds of the end user. You mustunderstand what the softwareis supposed to do. Then you canappreciate how developers triedto solve speci�c problems anddecide whether they accomplishedtheir objectives. By leveragingyour insight and targeting yourexploration, new issues will bediscovered. This is not a randombug hunt.

The Right ApproachThe surprising truth is thatexploratory testing encouragesthe right approach to testing anysoftware. You need to build a realinsight into the product and thinkimaginatively about how it will beused. Combine that creativity withmetrics and detailed reporting, andyou can see the big picture. Unlikead hoc testing, exploratory testingis an organized, well-structuredapproach that lets testers excelin the ever changing landscapeof agile development.

# # #

Good testers will naturallydevelop the skills required forexploratory testing; the abilityto think creatively and generateuseful tests in real-time. A dogged,rigid approach to testing software,especially software that is rapidlyevolving, does not make the bestuse of a tester’s intellect, andwon’t result in the best �nalproduct possible.

Extracting ValueYou’ve established yourboundaries and the scope of yourtesting session upfront. In orderto get the maximum bene�t fromyour discoveries you have togenerate reports of your �ndings.

You should be recording yourexpectations and the actual results.Were you able to achieve your goal?Did it take longer than expected?Did you encounter weaknessesin the software? Remember thatanother tester, or a member ofthe development team, should beable to follow your thoughts andreasoning. Clarity is vital.

Because you have a frame ofcontext the data you generatecan really bene�t the developmentteam. Instead of theisolated defects, suggestions, andconcerns that an ad hoc testingapproach might generate, you getin-depth information on how wellthe software meets intended goalsand how it will be perceived bythe end user.

In addition to verifying softwareand discovering issues,exploratory testing can helpidentify useful test cases for futureregression testing. An exploratorytesting session can be the bridgebetween unscripted and scriptedtesting for your project.

QA Symphony | The Surprising Truth about Exploratory Testing | Page 9

“Why” is a higher level overviewthat really ties into the businessside. It’s the big picture thinkingthat reveals why you’re buildingthe software in the �rst place.What audience need is yourproduct ful�lling? For example,we need to build an e-commercewebsite to sell our product to thegeneral public.

“What” is really focused onindividual features or functionsof a system. Using a shoppingcart analogy for an ecommercewebsite, you might say that users

How Do You Build Good Tests?You can’t design or execute theright tests without understandingthe intended purpose of the system.Testers need to have an insightinto the end user’s expectations.Communication between theproduct people at the business end,the engineers working on the code,and the test department enablesyou to score tests in terms of theirimportance and work out whereeach test cycle should be focusing.

We can break it down into threesimple queries: why, what, and how.

must be able to add and removeitems from their shopping cart, orthat they shouldn’t be able to addsomething that’s out of stock.

“How” relates to the practicalapplication of your testing. Howexactly is the software going tobe tested? How is the success andfailure measured?

Good tests are always going tocover our trio, but it can be a usefulexercise to break things down.

Good testers and good tests always retain and use an awarenessof what the intended audience wants and expects.

Building Good Tests:Why, What, How?Sellers Smith

CHAPTER 4

Tests are an investment in the quality of any given system. There’s always a costto build, run, and maintain each test in terms of time and resources. There’s alsoa great deal of value to be extracted from running the right test at the right time.It’s important to remember that for everything you do test, there’s somethingelse you’re not testing as a result.

Understanding that some tests are more important than others is vital tocreating a useful and �uid test plan capable of catering for modern softwaredevelopment techniques. Traditional waterfall development -- where everythingis delivered for a speci�c release date in a �nished package -- has beensucceeded by continuous feature roll outs into live systems. This necessitatesa di�erent approach from QA departments.

QA Symphony | Building Good Tests: Why, What, How? | Page 11

The WhyIf you get too caught up in the “what” and the“how” it’s possible to miss the “why” completelyand it’s the most important element because itdictates that some tests are more important thanothers. The business case for developing yoursoftware in the �rst place has to remain frontand center throughout the project. If you begin tolose sight of what the end user needs, then youcould be focusing your e�orts in the wrong places.Delivering value to your customers is critical. Goodtesters and good tests always retain and use anawareness of what the intended audience wantsand expects.

One technique we can employ is risk-basedanalysis of tasks. With risk-based analysis, wecan arrive at a numerical value for each testwhich gives you a sense of its importance.We can assign a score of between 1 and9 to each test. At the top end, a score of9 would be a critical test, and at theother end of the spectrum, a scoreof 1 might indicate a test that onlyneeds to be used sparingly.

The WhatTesters come up with speci�c scenarios of how anend user might interact with the software and whattheir expected outcome would be. A typical test mayconsist of many steps detailed in a script, but thisapproach can cause problems. What if a new testercomes in to run the test? Is the intent of the test clearto them? What if the implementation of the featurechanges? Perhaps the steps no longer result in theexpected outcome and the test fails, but that doesn’tnecessarily mean that the software is not workingas intended.

The steps and scripts are delving into the “how,” but ifthe “what” is distinct from the “how” then there’s lesschance of erroneous failure. Allow the tester someroom for an exploratory approach and you’re likely toget better results. If something can be tightly scripted,and you expect it to be a part of your regressiontesting, then there’s an argument for looking atautomating it.

Adopting a technique like Speci�cation by Exampleor Behavior Driven Design, you’re going to lay eachtest out in this format:• Given certain preconditions• When one or more actions happen• Then you should get this outcome

Regardless of the speci�cs of the user interface, orthe stops along the way between A and Z, the “Given,When, Then” format covers the essential core of thescenario and ensures that the feature does whatit’s intended to do, without necessarily spelling outexactly how it should do it. It can be used to generatetables of scenarios which describe the actions,variables, and outcomes to test.

(Continued on next page)

The value is determined by multiplying two factors:• Impact to the user – what are they trying to accomplish and what would the impact be if they couldn’t? How critical is this action?• Probability of failure – how likely is it that this code will fail? This is heavily in�uenced by how new it is and how much testing it has already undergone.

If we return to our ecommerce website analogy thenwe could take the action of being able to buy goods,clearly that’s essential, so it would be assigned a 3.However, the functionality for adding goods to thebasket and checking out has been there since dayone, so it has already been tested quite extensively,but some new features have been added which couldimpact on that code, so that might result in a score

of 2. Multiply the two together and you’ve got a6. This �gure will change over time, because

probability of failure will go up if this part ofthe system is signi�cantly altered, and it

will go down over time if it isn’t. There’salso a discretionary factor that might

lead you to bump that 6 up to a 7 if youfeel it’s merited.

Building Good Tests: Why, What, How?

The HowGetting down to the nuts and bolts of how testers will create, document,and run tests, we come to the “how.” Since projects are more �uid now andrequirements or priorities can change on a daily basis, there needs to besome �exibility in the “how” and a willingness to continually reassess theworth of individual tests. Finding the right balance between automatedtests, manually scripted tests, and exploratory testing is an ongoingchallenge that’s driven by the “what” and the “why.”

Traditionally, manual tests have been fully documented as a sequenceof steps with an expected result for each step, but this is time consumingand di�cult to maintain. It’s possible to borrow from automation byplugging in higher level actions, or keywords, which refer to a detailedscript or a common business action that’s understood by the tester.There’s also been a move towards exploratory testing, where the intentof the test is de�ned, but the steps are dynamic. Finally, there’s a placefor disposable testing, where you might use a recording tool to quicklydocument each step in a manual test as you work through it. These testswill need to be redone if anything changes, but as it’s a relatively quickprocess, and you’re actually testing while you create the test, that’s notnecessarily a problem.

Continuous assessmentEach individual test should be viewed as an investment. You have todecide whether to run it, whether it needs to be maintained, or if it’s timeto drop it. You need to continually assess the value and the cost of eachtest, so that you get maximum value from each test cycle. Never losesight of the business requirements. When a test fails, ask yourself if it’s aproblem with the system or a problem with the test, and make sure thatyou always listen to the business people, the software engineers, and mostimportantly the customer.

# # #

(Continued from pg. 11)

Conclusion

Every decade or so, we see a radical new idea ortechnology emerging that completely changes thesoftware development scene, and moves the goalposts fortesters. A trio of trends, in the shape of cloud computing,Agile development methodology, and the explosion inmobile devices, have converged to give us software thatis put together quickly and made available cheaply.Drastically cutting the time from concept to market hasa big impact on the way software is tested and a bigimpact on testers.

The waterfall method necessitated meticulous planningfrom detailed requirements, and a linear developmentschedule that dictated testing should follow the designand implementation phases. It’s hopelessly outdated.

We are in the midst of this transformative periodand if you �nd that you’re struggling, then it’s time torealize why. You need to catch up on what is changing,understand how you can be a better tester, and adopt newtechniques and tools that will help you to be as valuableas possible to your company.

It’s not a level playing �eld. There are lots of conferencesfor developers, plenty of networking opportunities,magazines and online articles sharing new ideas. There’sa whole community that targets developers with newtools and products, a community that’s geared towardsgetting developers up to speed on new languages ormethodologies. Unfortunately, the support o�ered todevelopers does not match or exist on the same scalefor testers.

Too many testers have their heads down, working awayon their own projects. There’s a lack of appetite forforum discussions, conferences, or new techniques. Thislack of a community evangelizing new procedures andspreading new ideas, makes it that much harder for bestpractices and exciting techniques to spread. The �eld isrelatively slow to modernize. New trends are in motion,and there are QA professionals pressing for change, butmany testers unfortunately are not aware it.

In order to spark the same level of activity andeven controversy in testing that we see in softwaredevelopment, we need to work together to drive the craftto become more professionalized. Generally speaking,testing roles may not be valued in the same way thatdeveloper roles are, but we can push to change that.Seasoned testing professionals can act as advocates forthat change, open lines of communication, and agitatefor the whole community to pull together.

The testing profession should move to an expertisevalue base, focus on improving skills and knowledgeto create better career paths and ultimately take greatersatisfaction and pride in the important work it does.Finding the right blend of techniques and tools,the perfect marriage of process and function cannotbe achieved if we can’t get beyond testing asan afterthought, or an addendum to development.

It’s time to reevaluate how we approach testing. Considertools that have been designed speci�cally to meet theneeds of real testers in the �eld, and blend techniquesthat are capable of providing the speed, transparency and�exibility that modern software development demands.Our comprehensive test management solution, qTest,was designed to empower modern QA departments withthe features and functionality they demand. We alsoo�er qTest eXplorer, a tool that enables testers to capture screenshots, edit, annotate, and share them directly. We welcome your input and feedback as we strive to produce tools thatput testers �rst.

We hope you found this eBook useful and welcome yourcomments and input. We hope to foster a greater spirit ofcommunity across the testing profession.

# # #

Email: info@qasymphony.com

Phone: 1-844-798-4386

Web: www.qasymphony.com

Join the conversation!

For more information on QASymphony please contact us at: