Bab 3
•Download as PPTX, PDF•
0 likes•35 views
This document discusses static testing techniques, including reviews. It describes the review process and roles involved in reviews. The review process consists of six main phases: planning, entry check, kick-off meeting, preparation, review meeting, rework, and follow-up. Key roles include the moderator, author, scribe, and reviewers. The goal of reviews is to improve quality and productivity by finding defects early.
Report
Share
Related slideshows
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
More Related Content
What's hot
What's hot (20)
Similar to Bab 3
Similar to Bab 3 (14)
Recently uploaded
Recently uploaded (20)
Bab 3
- 1. BAB 3 STATIC TECHNIQUES FADILLAH ALAZMI 11453105197 SISTEM INFORMASI TESTING DAN IMPLEMENTASI SISTEM 7 E
- 2. Static techniques Static test techniques provide a powerful way to improve the quality and productivity of software development. This chapter describes static test techniques, including reviews, and provides an overview of how they are conducted. The fundamental objective of static testing is to improve the quality of software work products by assisting engineers to recognize and fix their own defects early in the software development process. While static testing techniques will not solve all the problems, they are enormously effective. Static techniques can improve both quality and productivity by impressive factors. Static testing is not magic and it should not be considered a replacement for dynamic testing, but all software organizations should consider using reviews in all major aspects of their work including requirements, design, implementation, testing, and maintenance. Static analysis tools implement automated checks, e.g. on code.
- 3. 1. REVIEWS AND THE TEST PROCESS Studies have shown that as a result of reviews, a significant increase in pro- ductivity and product quality can be achieved [Gilb and Graham, 1993], [van Veenendaal, 1999]. Reducing the number of defects early in the product life cycle also means that less time has to be spent on testing and maintenance. To summarize, the use of static testing, e.g. reviews, on software work products has various advantages: • Since static testing can start early in the life cycle, early feedback on quality issues can be established, e.g. an early validation of user requirements and not just late in the life cycle during acceptance testing. • By detecting defects at an early stage, rework costs are most often relatively low and thus a relatively cheap improvement of the quality of software prod ucts can be achieved. • Since rework effort is substantially reduced, development productivity figures are likely to increase. • The evaluation by a team has the additional advantage that there is an exchange of information between the participants. • Static tests contribute to an increased awareness of quality issues.
- 4. 2. REVIEW PROCESS 2.1 Phases of a formal review In contrast to informal reviews, formal reviews follow a formal process. A typical formal review process consists of six main steps: • Planning The review process for a particular review begins with a 'request for review' by the author to the moderator (or inspection leader). A moderator is often assigned to take care of the scheduling (dates, time, place and invitation) of the review. On a project level, the project planning needs to allow time for review and rework activities, thus providing engineers with time to thoroughly participate in reviews. For more formal reviews, e.g.
- 5. Cont.... Although more and other entry criteria can be applied, the following can be regarded as the minimum set for performing the entry check: • A short check of a product sample by the moderator (or expert) does not reveal a large number of major defects. For example, after 30 minutes of checking, no more than 3 major defects are found on a single page or fewer than 10 major defects in total in a set of 5 pages. • The document to be reviewed is available with line numbers. • The document has been cleaned up by running any automated checks that apply. • References needed for the inspection are stable and available. • The document author is prepared to join the review team and feels confident with the quality of the document.
- 6. Cont.... • Kick-off An optional step in a review procedure is a kick-off meeting. The goal of this meeting is to get everybody on the same wavelength regarding the document under review and to commit to the time that will be spent on checking. Also the result of the entry check and defined exit criteria are discussed in case of a more formal review. In general a kick-off is highly recommended since there is a strong positive effect of a kick-off meeting on the motivation of reviewers and thus the effectiveness of the review process. At customer sites, we have meas-ured results up to 70% more major defects found per page as a result of per-forming a kick-off, [van Veenendaal and van der Zwan, 2000] During the kick-off meeting the reviewers receive a short introduction on the objectives of the review and the documents. The relationships between the doc-ument under review and the other documents (sources) are explained, espe-cially if the number of related documents is high.
- 7. Cont.... • Preparation The participants work individually on the document under review using the related documents, procedures, rules and checklists provided. The individual participants identify defects, questions and comments, according to their understanding of the document and role. All issues are recorded, preferably using a logging form. Spelling mistakes are recorded on the document under review but not mentioned during the meeting. The annotated document will be given to the author at the end of the logging meeting. Using checklists during this phase can make reviews more effective and efficient, for example a specific checklist based on perspectives such as user, maintainer, tester or operations, or a checklist for typical coding problems.
- 8. Cont.... • Review meeting The meeting typically consists of the following elements (partly depending on the review type): logging phase, discussion phase and decision phase. Every defect and its severity should be logged. The participant who identifies the defect proposes the severity. Severity classes could be: Critical: defects will cause downstream damage; the scope and impact of the defect is beyond the document under inspection. Major, defects could cause a downstream effect (e.g. a fault in a design can result in an error in the implementation). Minor, defects are not likely to cause downstream damage (e.g. non-compli ance with the standards and templates).
- 9. Cont.... • Rework Based on the defects detected, the author will improve the document under review step by step. Not every defect that is found leads to rework. It is the author's responsibility to judge if a defect has to be fixed. If nothing is done about an issue for a certain reason, it should be reported to at least indicate that the author has considered the issue. Changes that are made to the document should be easy to identify during follow-up. Therefore the author has to indicate where changes are made (e.g. using 'Track changes' in word-processing software). • Follow-up The moderator is responsible for ensuring that satisfactory actions have been taken on all (logged) defects, process improvement suggestions and change requests. Although the moderator checks to make sure that the author has taken action on all known defects, it is not necessary for the moderator to check all the corrections in detail. If it is decided that all participants will check the updated document, the moderator takes care of the distribution and collects– f the feedback. For more formal review types the moderator checks for compli-ance to the exit criteria.
- 10. 2.1 Roles and responsibilities • The moderator The moderator (or review leader) leads the review process. He or she deter-mines, in co-operation with the author, the type of review, approach and the composition of the review team. The moderator performs the entry check and the follow-up on the rework, in order to control the quality of the input and output of the review process. The moderator also schedules the meeting, disseminates documents before the meeting, coaches other team members, paces the meeting, leads possible discussions and stores the data that is collected. • The author As the writer of the document under review, the author's basic goal should be to learn as much as possible with regard to improving the quality of the document, but also to improve his or her ability to write future documents. The author's task is to illuminate unclear areas and to understand the defects found.
- 11. Cont.... • The scribe During the logging meeting, the scribe (or recorder) has to record each defect mentioned and any suggestions for process improvement. In practice it is often the author who plays this role, ensuring that the log is readable and understand-able. If authors record their own defects, or at least make their own notes in their own words, it helps them to understand the log better during rework. However, having someone other than the author take the role of the scribe (e.g. the moderator) can have significant advantages, since the author is freed up to think about the document rather than being tied down with lots of writing. • The reviewers The task of the reviewers (also called checkers or inspectors) is to check any material for defects, mostly prior to the meeting. The level of thoroughness required depends on the type of review. The level of domain knowledge or tech- nical expertise needed by the reviewers also depends on the type of review. Reviewers should be chosen to represent different perspectives and roles in the review process. In addition to the document under review, the material review-ers receive includes source documents, standards, checklists, etc. In general, the fewer source and reference documents provided, the more domain expertise regarding the content of the document under review is needed.
- 12. Cont.... • The manager The manager is involved in the reviews as he or she decides on the execution of reviews, allocates time in project schedules and determines whether review process objectives have been met. The manager will also take care of any review training requested by the participants. Of course a manager can also be involved in the review itself depending on his or her background, playing the role of a reviewer if this would be helpful.
- 13. 2.2 Types of review • Walkthrough A walkthrough is characterized by the author of the document under review guiding the participants through the document and his or her thought processes, to achieve a common understanding and to gather feedback. This is especially useful if people from outside the software discipline are present, who are not used to, or cannot easily understand software development documents. The content of the document is explained step by step by the author, to reach consensus on changes or to gather information.
- 14. Cont.... • Technical review A technical review is a discussion meeting that focuses on achieving con-sensus about the technical content of a document. Compared to inspec-tions, technical reviews are less formal and there is little or no focus on defect identification on the basis of referenced documents, intended read-ership and rules. During technical reviews defects are found by experts, who focus on the content of the document. The experts that are needed for a technical review are, for example, architects, chief designers and key users. In practice, technical reviews vary from quite informal to very formal.
- 15. Cont.... • Inspection Inspection is the most formal review type. The document under inspection is prepared and checked thoroughly by the reviewers before the meeting, compar-ing the work product with its sources and other referenced documents, and using rules and checklists. In the inspection meeting the defects found are logged and any discussion is postponed until the discussion phase. This makes the inspection meeting a very efficient meeting.
- 16. 2.3 Success factors for reviews • Find a 'champion' A champion is needed, one who will lead the process on a project or organiza-tional level. They need expertise, enthusiasm and a practical mindset in order to guide moderators and participants. The authority of this champion should be clear to the entire organization. Management support is also essential for success. They should, amongst other things, incorporate adequate time for review activities in project schedules. • Pick things that really count Select the documents for review that are most important in a project. Reviewing highly critical, upstream documents like requirements and architec-ture will most certainly show the benefits of the review process to the project. These invested review hours will have a clear and high return on investment. In addition make sure each review has a clear objective and the correct type of review is selected that matches the defined objective. Don't try and review everything by inspection; fit the review to the risk associated with the docu-ment. Some documents may only warrant an informal review and others will repay using inspection. Of course it is also of utmost importance that the right people are involved.
- 17. Cont.... • Explicitly plan and track review activities To ensure that reviews become part of the day-to-day activities, the hours to be spent should be made visible within each project plan. The engineers involved are prompted to schedule time for preparation and, very impor-tantly, rework. Tracking these hours will improve planning of the next review. As stated earlier, management plays an important part in planning of review activities. • Train participants It is important that training is provided in review techniques, especially the more formal techniques, such as inspection. Otherwise the process is likely to be impeded by those who don't understand the process and the reasoning behind it. Special training should be provided to the moderators to prepare them for their critical role in the review process.
- 18. Cont.... • Manage people issues Reviews are about evaluating someone's document. Some reviews tend to get too personal when they are not well managed by the moderator. People issues and psychological aspects should be dealt with by the moderator and should be part of the review training, thus making the review a positive experience for the author. During the review, defects should be welcomed and expressed objectively. • Follow the rules but keep it simple Follow all the formal rules until you know why and how to modify them, but make the process only as formal as the project culture or maturity level allows. Do not become too theoretical or too detailed. Checklists and roles are recom-mended to increase the effectiveness of defect identification.
- 19. 3. STATIC ANALYSIS BY TOOLS Static analysis is an examination of requirements, design and code that differs from more traditional dynamic testing in a number of important ways: • Static analysis is performed on requirements, design or code without actually executing the software artifact being examined. • Static analysis is ideally performed before the types of formal review dis cussed in Section 3.2. • Static analysis is unrelated to dynamic properties of the requirements, design and code, such as test coverage. • The goal of static analysis is to find defects, whether or not they may cause failures. As with reviews, static analysis finds defects rather than failures.
- 20. • Coding standards Checking for adherence to coding standards is certainly the most well-known of all features. The first action to be taken is to define or adopt a coding stan-dard. Usually a coding standard consists of a set of programming rules (e.g. 'Always check boundaries on an array when copying to that array'), naming conventions (e.g. 'Classes should start with capital C) and layout specifica-tions (e.g. 'Indent 4 spaces'). • Code metrics As stated, when performing static code analysis, usually information is calculated about structural attributes of the code, such as comment fre-quency, depth of nesting, cyclomatic number and number of lines of code. This information can be computed not only as the design and code are being created but also as changes are made to a system, to see if the design or code is becoming bigger, more complex and more difficult to understand and maintain. The measurements also help us to decide among several design alternatives, especially when redesigning portions of existing code.
- 21. Example : IF A = 354 THEN IF B > C THEN A = B ELSEA= C ENDIF ENDIF Print A The control flow generated from the program would look like Figure 3.2. The control flow shows seven nodes (shapes) and eight edges (lines), thus using the formal formula the cyclomatic complexity is 8-7 + 2 = 3. In this case there is no graph called or subroutine. Alternatively one may calculate the cyclomatic complexity using the decision points rule. Since there are two decision points, the cyclomatic complexity is 2 + 1 = 3.
- 22. Cont.... The important thing for the tester is to be aware that the above mentioned static analysis measures can be used as early warning signals of how good the code is likely to be when it is finished. In summary the value of static analysis is especially for: • early detection of defects prior to test execution; • early warning about suspicious aspects of the code, design or requirements; • identification of defects not easily found in dynamic testing; • improved maintainability of code and design since engineers work according to documented standards and rules; • prevention of defects, provided that engineers are willing to learn from their errors and continuous improvement is practised.