3.static techniques

3.static techniques

• 1.
  STATIC TECHNIQUES Disusun Oleh: Bobi Henfajri Setiawan Nim :11453104759 Program Studi (S1) :Sistem Informasi Testing Dan Implementasi Sistem Fakultas Sains dan Teknologi Universitas Islam Negeri Sultan Syarif Kasim Riau http://www.uin-suska.ac.id/http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/
• 2.
  Static test techniquesprovide 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 cond ucted. The fundamental objective of static testing is to improve the quality of software work products by assistin g engineers to recognize and fix their own defects early in the software development process. While static testi ng 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 repla cement 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 imple ment automated checks, e.g. on code.
• 3.
  Review Process 1. Recallthe phases, roles and responsibilities of a typical formal review. (K1) 2.Explain the differences between different types of review: informal review, technical review, walkt hrough and inspection. (K2) 3. Explain the factors for successful performance of reviews. (K2) Reviews vary from very informal to formal (i.e. well structured and regulated). Although inspection is perhaps the most documented and formal review technique, it is certainly not the only one. The for mality of a review process is related to factors such as the maturity of the development process, any l egal or regulatory requirements or the need for an audit trail. In practice the informal review is perha ps the most common type of review. Informal reviews are applied at various times during the early st ages in the life cycle of a document. A two-person team can conduct an informal review, as the autho r can ask a colleague to review a document or code. In later stages these reviews often involve more people and a meeting.
• 4.
  Phases of aformal review In contrast to informal reviews, formal reviews follow a formal process. A typical formal review p rocess consists of six main steps: 1. Planning 2. Kick-off 3. Preparation 4. Review meeting 5. Rework 6. Follow-up. 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 (da tes, time, place and invitation) of the review. Kick-off An optional step in a review procedure is a kick-off meeting. The goal of this meeting is to get ev erybody 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 discu ssed in case of a more formal review.
• 5.
  Continue….. Preparation The participants workindividually on the document under review using the related docum ents, procedures, rules and checklists provided. The individual participants identify defect s, questions and comments, according to their understanding of the document and role. Review meeting The meeting typically consists of the following elements (partly depending on the review type): logging phase, discussion phase and decision phase. 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 judg e if a defect has to be fixed. Follow-up The moderator is responsible for ensuring that satisfactory actions have been taken on all (logged) defects, process improvement suggestions and change requests.
• 6.
  Roles and responsibilities Themoderator The moderator (or review leader) leads the review process. He or she determines, in co-opera tion with the author, the type of review, approach and the composition of the review team. The author As the writer of the document under review, the author's basic goal should be to learn as muc h as possible with regard to improving the quality of the document, but also to improve his or her ability to write future documents. The scribe During the logging meeting, the scribe (or recorder) has to record each defect mentioned and any suggestions for process improvement. The reviewers The task of the reviewers (also called checkers or inspectors) is to check any material for def ects, mostly prior to the meeting. The manager The manager is involved in the reviews as he or she decides on the execution of reviews, allo cates time in project schedules and determines whether review process objectives have been met.
• 7.
  Types of review Walkthrough Awalkthrough 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. Technical review A technical review is a discussion meeting that focuses on achieving consensus about the technical content of a document. Compared to inspections, technical reviews are less for mal and there is little or no focus on defect identification on the basis of referenced docu ments, intended readership and rules. Inspection Inspection is the most formal review type. The document under inspection is prepared an d checked thoroughly by the reviewers before the meeting, comparing the work product w ith its sources and other referenced documents, and using rules and checklists. In the insp ection meeting the defects found are logged and any discussion is postponed until the disc ussion phase. This makes the inspection meeting a very efficient meeting.
• 8.
  Success factors forreviews Find a 'champion' A champion is needed, one who will lead the process on a project or organizational level. They need expertise, enthusiasm and a practical mindset in order to guide moderators and participants. Pick things that really count Select the documents for review that are most important in a project. Reviewing highly cr itical, upstream documents like requirements and architecture will most certainly show th e benefits of the review process to the project. These invested review hours will have a cl ear and high return on investment. Explicitly plan and track review activities To ensure that reviews become part of the day-to-day activities, the hours to be spent shou ld be made visible within each project plan. Train participants It is important that training is provided in review techniques, especially the more formal t echniques, such as inspection.
• 9.
  Continue….. Manage people issues Reviewsare about evaluating someone's document. Some reviews tend to get too persona l when they are not well managed by the moderator. People issues and psychological aspe cts 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. Follow the rules but keep it simple Follow all the formal rules until you know why and how to modify them, but make the pr ocess only as formal as the project culture or maturity level allows. Do not become too th eoretical or too detailed. Continuously improve process and tools Continuous improvement of process and supporting tools (e.g. checklists), based upon the ideas of participants, ensures the motivation of the engineers involved. Report results Report quantified results and benefits to all those involved as soon as possible, and discus s the consequences of defects if they had not been found this early. Just do it! The process is simple but not easy. Each step of the process is clear, but experience is nee ded to execute them correctly.
• 10.
  Static Analysis ByTools There is much to be done examining software work products without actually running the system. For example, we saw in the previous section that we can carefully review require ments, designs, code, test plans and more, to find defects and fix them before we deliver a product to a customer. In this section, we focus on a different kind of static testing, where we carefully examine requirements, designs and code, usually with automated assistance t o ferret out additional defects before the code is actually run. Thus, what is called static a nalysis is just another form of testing. Static analysis is an examination of requirements, design and code that differs from more traditional dynamic testing in a number of important ways:
• 11.
  Continue….. Static analysis isperformed on requirements, design or code without actually executing the software artifact being examined. -Static analysis is ideally performed before the types of formal review discussed 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 review s, static analysis finds defects rather than failures. For static analysis there are many tools, and most of them focus on software code. Static analysis too ls are typically used by developers before, and sometimes during, component and integration testing and by designers during software modeling. The tools can show not only structural attributes (code metrics), such as depth of nesting or cyclomatic number and check against coding standards, but also graphic depictions of control flow, data relationships and the number of distinct paths from one line of code to another.
• 12.
  Reference Graham, d., etal. 2006. Foundation of Software Tes ting: ISTQB certification London, UK: Internation al Thomson Business Press