TestArchitect

RELATED ARTICLESperformed followed by the functional entityfollowed by descriptive text (if required). Hereare several common examples:Logon User - Logon UserEnter Customer Name - Enter CustomerNameEnter Customer Address - EnterCustomer AddressValidate Customer Name - ValidateCustomer NameSelect Customer Record - SelectCustomer RecordTest design – keyword applicationKeyword test case design begins as anitemized list of the test cases to be constructed–usually as a set of named test cases. Theinternal structure of each test case is thenconstructed using existing or new keywords.Once the design is complete, the appropriatetest data (input and results) can be added.Testing the keyword test case design involvesexecuting the test case against the applicationor applications being tested.At first glance this does not appear to be anydifferent than any other method for test casedesign but there are significant differencesbetween keyword test case design and anyfreehand/textual approach to test casedesign. Keyword test case designs are:Consistent – the same keyword is usedto describe the business event everytimeData Driven – the keyword contains thedata required to perform the test stepSelf Documenting – the keyword,description contains the designers’intentMaintainable – with consistency comesmaintainabilityAutomation -- supports automation withlittle or no design transformation(rewrite)Test design – adaption based ondevelopment/testing paradigmThere are two primary development andtesting approaches being used bydevelopment organizations today: adaptive(agile) and predictive (waterfall/cascade).Both approaches certainly have theirproponents–though the increasingly adaptive(agile) system development lifecycles aregaining precedence. The question becomeshow does this affect the test design paradigm?The answer appears to be that it really doesnot affect the test design paradigm but it doesaffect the timing.Predictive (waterfall/cascade) developmentlifecycles can be supported by a straightforwarddesign, build, execute and maintaintest design paradigm that may later supportautomation. Eventually, one would expect thepredictive testing team to design, build,execute, maintain and automate their testcase inventory. This could be accomplishedusing both Tier 1 commercial automation toolsand open source automation tools. As long asthe automation tools support modular baseddesign (functions) and data driven testing (testdata sources) keyword-based automation canbe supported–the most significant differencebeing the time and effort required toimplement the testing framework. Adaptive(agile) development lifecycles come in severalflavors–some support immediate keywordbasedfunctional test design and automationwhile others do not. Agile test drivendevelopment (TDD) using FitNesse, a testingframework which requires instrumentation byand collaboration with the development team,certainly supports keyword-based test casedesign and automation. Other agile paradigmsonly support instrumentation at the unit testlevel or not at all, i.e. a separate keywordbasedtest case design and automation toolsetmust be used. The challenge for non-TDD agilebecomes designing, building, executing andmaintaining functional tests within the contextof a two to four week sprint. The solution is acombination of technique and timing. For theimmediate changes in the current sprint,consider using exploratory testers and anitemized list of test cases with little, if anycontent–basically a high-level check list. Oncethe software for a sprint has migrated to andexisted in production for at least one sprint, atraditional set of regression test cases can beconstructed using keywords. This separates thechallenge into sprint-related testing andregression testing.www.logigearmagazine.com Page 7 of 14 January 2011 | Volume V