PowerPoint Presentation

StaticTestingChapter 6ObjectivesEnd Goalsto examine the necessity of testing all documentation produced by a software development projectto list the variety of software development documentation that should be testedto describe the techniques for testing software development documentationCoverageOverview of TopicsGoal of Static TestingCandidate Documents for Static TestingStatic Testing TechniquesTracking Defects Detected by Static TestingIntroductionWhat is Static Testing?

Static Testing!All good software development projects produce documentation as well as code.This documentation serves a wide variety of purposes from shaping the softwareitself to assisting the end user in successfully operating the software. RecallingChapter 3, this documentation fulfi lls the specifi cation item in the SPRAE checklist.The process of testing this documentation is called static testing. The termstatic in this context means not while running or not while executing, andis used in contrast to testing software by running or executing it. Statictesting is considered a recommended strategy for all development phases.

4Goal of Static TestingHas the largest potential for reducing defects in software under development

defect reduction in the software by reducingdefects in the documentation from which the software is developedStatic testing is the least expensive form of testing and, with Chapter 1 defect sourcesin mind, has the largest potential for reducing defects in software under development.The primary goal of static testing is defect reduction in the software by reducingdefects in the documentation from which the software is developed. A secondarygoal is correct operation of the software. This statement may seem like a statementof the obvious, but many software systems and products have been abandoned afteran investment of millions of dollars because the end users could not fi gure out how toproperly operate the software to do their routine business. Human nature being whatit is, the recipients of poor documentation and training do not say, I will fi gure outhow to operate this software; rather, they say, this software doesnt do what I needit to do, so I want the old system back.5Candidate Documents for Static TestingSoftware development managers documentsSoftware requirementsSoftware project planthe foundation on which all subsequent documentation and code are written. contain the roadmap that the software development willfollow for this particular system or product. Software requirements are the foundation on which all subsequent documentation andcode are written. If these critical documents are either missing (see Chapter 1s gameof Gossip) or incorrect, then no programming staff can deliver the correct software.The format for requirements varies widely from company to company. If yourcompany is new to writing requirements for your software, consider starting with thesoftware requirements templates found in the Rational Software Development ToolRequisitePro. [23] The templates in this tool enjoy a good industry reputation. So whynot use recognized quality templates until your company has gained enough of itsown experience to customize the requirements templates where appropriate if youreally fi nd the need to customize.Software project plans contain the roadmap that the software development willfollow for this particular system or product. If your software development projectsalways come in on time and under budget, then perhaps you do not need to static testthis document. If your software development projects tend to be late or over budget,then perhaps a little static testing can help identify some of the planning gaps thatcontribute to those overruns.7Software developers documentsUse CasesSoftware DesignsSoftware specificationsData Flow DiagramsDatabase and File designsOnline operating environment specificationsBatch operating environment specificationsInterfacesConnectivity (network) specificationsSecurity specificationsScreen/window/page specificationsReport SpecificationsCodeUse cases are the formal documentation of the business processes that the newsystem must provide. This documentation identifi es the actors (different rolesthe system users play) and activities (processes that are performed by specifi cactors). There is no industry consensus about who should write these use casesor how much process detail the use cases need to express. Because the developmentmanagers typically do not write use cases and the test teams typically basepart of their test plans on use cases, it seems expedient to place the authorship ofuse cases somewhere in the development teams realm with or without businessassistance.Software designs contain the high-level technical solution (the how) for thebusiness requirements (the what) that are expressed in part by use cases. It is the whatto how linkage that is most often incomplete, leading to missed, or poorly understoodfeatures and capabilities. All the software developers documents below softwaredesigns, that is, software specifi cations, data fl ow diagrams, database and fi le designs,online operating environment specifi cations, batch operating environment specifi -cations, interfaces, connectivity (network) specifi cations, security specifi cations,screen/window/page specifi cations, report specifi cations, and code are successivelydeeper details of the technical implementation of the business requirements. Not alldocuments are needed for every system or application. Part of the software developmentmanagers job is to identify which of these documents need to be written for thenew project. There are two static testing concerns that run through this list of moredetailed documents. The fi rst static testing concern is completeness, that is, the moredetailed documents must completely describe the next level of technology needed tofully respond to the higher level documents. The second static testing concern is thatas the technical details are written, some of the details stray from or are not really apart of the original business requirements (out of scope).

8Testers documentationTest PlansTest CasesTest Environment SpecificationsTest Data Sources and PreparationTest Tool Installation and OperationTesters documentation (test plans, test cases, test environment specifi cations, testdata sources and preparation, and test tool installation and operation) needs tobe tested as thoroughly as other project documents. The sequence of developmentevents that allow test plans to be developed were covered in the bathtub examplein Chapter 5. The static testing concern is similar to the more detailed developerdocumentation: completeness of testing plans against the business requirements andintended development with no gratuitous testing.9Administrators DocumentationInstallation GuidesOperation/Administration Guidesdocuments the steps that must be taken by technical staff to install and support the new system or applicationAdministrators documentation (installation guides and operation/administrationguides) documents the steps that must be taken by technical staff to install and supportthe new system or application. The static testing concern in these documents isdouble-sided. The fi rst side is clear and unequivocal support of the business requirements.The second side is stepwise instructions that can be carried out successfullyby the support staff at their expected administrative skill level.10End Users DocumentationUsers guidesHelp ScreensDocuments the steps that must be taken by business end users to perform their routine daily activities on the new system or applicationTraining ManualsEnd users documentation (users guides, help screens, and training manuals) documentsthe steps that must be taken by business end users to perform their routinedaily activities on the new system or application. As with the administrative manuals,the static testing concern with these documents is the double-sided businessrequirements/operations within expected end user business skill level.11Static Testing TechniquesBecause static testing requires a high degree of interaction among software developmentteam members, the most challenging aspect of static testing is to keep the testingactivities objective and impersonal. The force working against you is the humantendency to take ownership of documents to the extent that a perceived attack onthe document is a perceived personal attack on the owner-author. Document ownershipis, in fact, a good thing. It causes the author to do his or her best job and gain asense of pride in good-quality results. Static testing strives to help the owner-authorproduce the best possible (most correct) document by helping identify correctionsand improvements to documents that might already be of good quality. This pride ofownership reaches its zenith with program code. Because no large software applicationis 100% defect free, all program code has room for improvement. Static testingis one of the more cost-effective ways to identify these improvements.12The Two-Step ApproachCosmetic clean-upExampleCheck spelling, grammar, punctuation, formattingTechniques that seem appropriate to focus expert review on document contentsExampleDesk CheckingInspectionsWalkthroughs

Consider using a two-step approach to static testing. For the fi rst step, clean upthe cosmetic appearance of the document: check spelling, check grammar, checkpunctuation, and check formatting. The benefi t of doing the fi rst step is that whenthe document is cosmetically clean, the readers can concentrate on the content. Theliability of skipping the fi rst step is that if the document is not cosmetically clean, thereaders will surely stop reading the document for meaning and start proofreadingto the detriment of content review.For the second step, use whatever techniques seem appropriate to focus expertreview on document contents. Here are some of the more popular and effective techniquesused for content review.Static testing techniques for content reviewdesk checkinginspectionswalk-throughs

Desk checking is the least formal and least time-consuming static testing technique.Of all the techniques, desk checking is the only one whereby the author is encouragedto test his or her own document. The remaining techniques rely on independenteyes to provide a more thorough and objective review. Desk checking involvesfi rst running a spellchecker, grammar checker, syntax checker, or whatever tools areavailable to clean up the cosmetic appearance of the document. Then, the author slowlyreviews the document trying to look for inconsistencies, incompleteness, and missinginformation. Problems detected in the contents should be corrected directly by the authorwith the possible advice of the project manager and other experts on the project.Once all corrections are made, the cosmetic testing is rerun to catch and correct allspelling, grammar, and punctuation errors introduced by the content corrections.Inspections are a little more formal and a little more time consuming than deskchecking. The technique also fi nds more document defects than desk checking. Theintent of the technique is for an independent pair of eyes, usually a more seniormember of the team, to read the document and discover content problems. As recommendedwith desk checking, the document to be inspected should be made ascosmetically clean as possible by the author so that the independent reader(s) canfocus on the content. The independent reader then takes the document elsewhere andreviews it. Separating the document from the author allows the document to standon its own merit. If the reviewer inspects the document in front of the author, thehuman tendency is for the author to kibitz the reviewer, which defeats the purpose ofthe independent reviewer. Suspected problems in the content should be documentedby the independent reviewer and presented to the author in a subsequent meeting.The author then needs to provide suggested corrective action alongside the suspectedproblem. The project manager or someone senior on the project should then reviewthe list of reviewers suspected problems, and authors suggest corrective actions inorder to negotiate an agreed corrective action.Walk-throughs are the most formal and most time-consuming document testingtechniques, but they are the most effective at identifying content problems. Thewalk-through is a scheduled meeting with a facilitator, the document author, andan audience of senior technical staff and possibly business staff. The author mustscrub the document for cosmetic errors and send the document to all participantsin advance of the meeting. The participants read the document and formulate questionsabout the document contents based on their own knowledge of the new systemor application. At the appointed time, the author presents his or her document to thewalk-through meeting. The facilitator becomes the clearinghouse for questions bythe audience and answers by the author. The facilitator also ensures that the questionsare posed in an objective, nonthreatening way. The walk-through facilitatordocuments all suspected content problems and author responses for later resolutionby the project manager in a manner similar to the inspection resolutions.13Tracking Defects Detected by Static Testing

SpreadsheetsDatabasesEach of the previously described static testing techniques involved writing down suspectedor confi rmed content problems, their suggested or negotiated corrective action, anda correction completion date. These lists can be managed using simple tools like spreadsheetsor complex tools like databases. Either way, there are two compelling reasons forrecording and tracking these defects to correction. The fi rst reason is to enable the projectmanagement to verify the corrections are actually applied to the tested document in atimely manner. The second reason is to demonstrate the importance of current, correctdocumentation to the early success of the project. Without defect tracking as a reminder toget the documentation right, the attitude of Ill document that after Ive written the codewill rise up and make Capers Jones gloomy prediction a reality for your project too.14Tracking Defects Detected by Static TestingWHY?

To enable the project management to verify the corrections are actually applied to the tested document in a timely mannerTo demonstrate the importance of current, correct documentation to the early success of the projectEach of the previously described static testing techniques involved writing down suspectedor confi rmed content problems, their suggested or negotiated corrective action, anda correction completion date. These lists can be managed using simple tools like spreadsheetsor complex tools like databases. Either way, there are two compelling reasons forrecording and tracking these defects to correction. The fi rst reason is to enable the projectmanagement to verify the corrections are actually applied to the tested document in atimely manner. The second reason is to demonstrate the importance of current, correctdocumentation to the early success of the project. Without defect tracking as a reminder toget the documentation right, the attitude of Ill document that after Ive written the codewill rise up and make Capers Jones gloomy prediction a reality for your project too.15StaticTestingEND Module UpdatesDocument Version DetailsVersionDate UpdatedChanges/DetailsAuthor1.010/20/2011Created DocumentEngr. K. FajardoThis document must not be used for other purposes outside the USC Department of Computer Engineering without permission.