Presentation is loading. Please wait.

Presentation is loading. Please wait.

Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.

Similar presentations


Presentation on theme: "Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software."— Presentation transcript:

1 Damian Gordon

2  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.  Dynamic Testing is the testing of software by executing the software of either a component or system.  Static Testing and Dynamic Testing are complementary methods and tend to find different types of defects effectively and efficiently.

3  Static Testing detects defects such as deviations from standards, missing requirements, design defects, non- maintainable code and inconsistent interface specifications.  Dynamic Testing detects defects such as checking if outputs from the expected values.

4  One key approach in Static Testing is the Review Process.  Reviews can find defects, are informational, communicational, and educational.  Participants in the review learn the content of the software systems, the role of their own work, help planning for future stages of the work.  Reviews often represent milestones, and support the establishments of a baseline for the software product.

5

6  The type and quantity of defects found during the review stage can help focus the testing process.  In some cases customers or users attend the review process and provide feedback to the developers and document authors.  Studies have shown the reviews significantly increase productivity and product quality.

7  They can be either informal or formal.  The formality of the review process is related to factors such as the maturity of the development process, any legal or regulatory requirements or the need for an audit trail.  In practice most reviews are informal.  A two-person team can conduct an informal review, as the developer/author can get a colleague to review the code and documentation.

8  Phases of a Formal Review 1.Planning 2.Kick-Off 3.Preparation 4.Review Meeting 5.Rework 6.Follow-up

9  1. Planning  The authors/developers request a review.  A moderator is assigned – this is the leader of the review process.  The project planning needs to incorporate time to undertake the review.  The planning must start with deciding an entry criteria to ensure that document is ready for review.

10  1. Planning  Entry Criteria  The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. Test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria.

11  1. Planning  Minimum set of criteria for performing entry check: ◦ A short check of a product sample by the moderator does not reveal a large number of defects, e.g. After 30 minutes of checking, no more than 3 major defects are found in 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.

12  1. Planning  The review will focus on a few different things: ◦ Focus on higher-level documents, e.g. Does the design comply to the requirements ◦ Focus on standards, e.g. Internal consistency, clarity, naming conventions, templates ◦ Focus on related documents at the same level, e.g. Interfaces between software functions ◦ Focus on usage, e.g. For testability and maintainablity

13  2. Kick-Off  The review starts with a kick-off meeting, to make sure everyone is on the same wavelength regarding the document under review.  The meeting consists of a short introduction to the objectives of the review and the documents.  Role assignments, checking rate, the pages to be checked, process changes and possible other questions are discussed at this meeting.

14  3. Preparation  Participants identify defects, questions, and comments, according to their understanding of the document and their role.  A checking rate is decided, which is the number of pages checked per hour, usually about 5 to 10 pages per hour, depending on complexity.

15  4. Review Meeting  Usually made up of the following phases: ◦ Logging phase ◦ Discussion phase ◦ Decision phase

16  4. Review Meeting  Logging Phase:  The issues that have been identified in the Preparation stage are logged.  To ensure progress and efficiency, no real discussion is allowed during the logging phase.  Each defect is logged with a severity: ◦ Critical: defects will cause downstream damage. ◦ Major: defects could cause downstream damage. ◦ Minor: defects are not likely to cause downstream damage.

17  4. Review Meeting  Discussion Phase:  Each of the defects that require discussion are discussed, with a chairman preventing discussions from getting too personal.

18  4. Review Meeting  Decision Phase:  At the end of the discussion phase, a decision is taken about the document under review. If the number of defects found per page exceeds a certain level, the document may need to be reworked, and reviewed again.

19  5. Rework  Based on the defects detects, the author will improve the document under review, step- by-step.

20

21  Always, every, all, none, never, … (absolutely sure?)  Certainly, therefore, clearly, obviously, customarily, most, … (persuasion lingo)  Some, sometimes, often, usually, ordinarily, customarily, most, … (vague)  etc., and so forth, and so on, such as, … (not testable)  Good, fast, cheap, efficient, small, stable, … (unquantifiable)  Handled, processed, rejected, skipped, eliminated…  If … then … (missing else)

22  Roles and Responsibilities  The moderator  The author  The scribe  The reviewers  The manager

23  Roles and Responsibilities  The moderator serves as the review leader, they determine 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.  The moderator also schedules meetings, disseminates documents, leads discussions and stores relevant data.

24  Roles and Responsibilities  The author writes the original document and seeks to improve the quality of the document by working with others.

25  Roles and Responsibilities  The scribe records all of the defects during the logging meetings.

26  Roles and Responsibilities  The reviewers (also called checkers and inspectors) check the documents for defects.  Reviewers are chosen to represent different perspectives in the review.

27  Roles and Responsibilities  The manager decides on the execution of reviews and determines whether review process objectives have been met.

28  Types of Reviews  Walkthrough  Technical Review  Inspection

29  Types of Reviews  Walkthrough  The author guides the review team through the document, to achieve a common understanding and gather feedback.  This means the author does a range of preparation, and the review team don’t need to do a detailed study before the meeting.  A walkthrough is especially useful for higher-level documents, like requirements specifications and architectural documents.

30  Types of Reviews  Technical Review  This approach focuses on developing a consensus about the technical content of the document.  Defects are found by technical experts, who focus on the content of the document (as opposed to considering any relevant legislation and standards, referenced documents, and intended readership).

31  Types of Reviews  Inspection  This approach is the most formal review type.  The document is inspected thoroughly be the reviews before the meeting, comparing the work product with its sources and other referenced documents, and using rules and checklists.  The defects found are logged and any discussion is postponed until the discussion phase.  This makes the inspection meeting a very efficient meeting.

32  Let’s do one.


Download ppt "Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software."

Similar presentations


Ads by Google