Introduction to Software Engineering: Tools and Environments

Session 7

Oded Lachish

Room: Mal 405 Visiting Hours: Wednesday 17:00 to 20:00 Email: [email protected] Module URL: http://www.dcs.bbk.ac.uk/~oded/Tools2012-2013/Web/Tools2012-2013.html

1 Last time

• Debugging with Eclipse • Code coverage with corbetura • Static code analysis – Checkstyle, PMD, FindBugs

Hopefully by now we know how to mock software. Hopefully we also have some tools for debugging.

Remember: an important goal of these tools is minimal interaction with product code.

2 Verification Overview

3 What have we seen until now

Dynamic Verification • The software’s behaviour is checked dynamically during execution

Static verification • The software is checked via a static analysis

4 Dynamic verification

Scope: • Small – unit testing (Junit) • Large ‐ Integration testing (Cucumber) • Even larger ‐ System test Types of tests • Functional • Stress (non functional) Main disadvantage • Can’t cover all the cases

5 Static verification

Formal Verification: • Formally proving that code abides certain behavioural rules Can be done automatically or semi automatically. (We didn’t do since it is applicable only in a very small number of cases) Code convention • Check that software abides a recommended coding style. The coding style is there to improve readability, to prevent future bugs etc. Tools: Checkstyle, PMD and Findbugs

Anything else?

6 Code Review Jupiter http://jupiter‐eclipse‐plugin.googlecode.com/svn/trunk/site/

7 jupiter

Code review plug‐in for eclipse Important features: • Open Source

• Cross‐platform ‐ available for all platforms supported by Eclipse.

• XML data storage: stores data in XML format. • Supports sorting and searching

• File integration: easy to jump go back and forth between reviews

and source code.

8 Jupiter –Four Step Process

Code review plug‐in for eclipse Step 1: Configuration • Insertion of review information by leader of review –(important – must be committed) Step 2: Individual review • Each person by himself • Issues are created • At this stage only issues created by the selected user

9 Jupiter –Four Step Process

Code review plug‐in for eclipse Step 3: Team • One person updates their local environment so that it contains all the review files • All issues can be seen • The team modifies issues upon need Step 4: Rework Phase • Author of code resolves issues (fixes code) • Author of code updates issue accordingly • Review files are committed and permanently stored as part of the project

10 Review ID

A review ID consists of the following • The set of files to be reviewed • The list of reviewers • The review session author • Review storage location • Item entries ‐ Type, Severity, Resolution, and Status fields (are customizable.) • Default items ‐ default values for fields when a new issue is created. • Filters – filter to be applied when issues are displayed

11 Creating Review ID ‐Start

Press

You should get Press 12 Creating Review ID –ID creation

Pick a review name

Enter description

13 Creating Review ID – adding files

Press

You should get 14 Creating Review ID –ID creation

Pick a review name

Enter description

15 Creating Review ID – Added files

16 Creating Review ID – Adding a Reviewer

Press

This should appear

Add name

17 Creating Review ID – Session Author

18 Creating Review ID – Session Author

Press to get options

19 Creating Review ID – Finish

20 Creating Review ID –What New?

Review directory Jupiter perspective

21 Jupiter advanced options –getting there 1

Press

22 Jupiter advanced options –getting there 2

Press

23 Jupiter advanced options –getting there 3

Pick Press

24 Jupiter advanced options –getting there 4

Press

25 Jupiter advanced options –entry items

Items may be added, removed and reordered

26 Jupiter advanced options – filters

Options for focusing only on specific issues

27 Adding an issue

Right click and press

28 Adding issues

29 Review Table

30 Changing phase to Team

Press

A new issue appears. This is from a different author. (check if you can add such an issue by yourself)

31 From Individual phase to Team Phase

Code

32 After decision made

Decision made issue removed

Make another decision

33 Rework Phase Issues and what need to be done

Only issues relevant to the person responsible for them appear

Now only revision text can be changed

34 Bug‐Tracking‐Systems

35

36 What is Bugzilla?

Bug‐Tracking‐System‐ a system for keeping track of bugs and how they are resolved Important features: • Open Source • inter‐bug dependencies and dependency graphing • extensive configurability And many more features

37 Why use Bugzilla?

When software quality is at a high priority bug tracking is essential.

1. Monitoring bugs and their resolution as part of the workflow 2. Keeping in touch with the bug resolution process through e‐mail integrated features 3. Archiving bug related information 4. Accountability 5. Open‐source enables customers to use system

38 Installing Bugzilla

Taken from: http://cvs1.up.ac.za/bugzilla‐doc/stepbystep.html#AEN515

The software packages necessary for the proper running of bugzilla are: 1.MySQL database server and the mysql client (3.22.5 or greater) 2.Perl (5.004 or greater, 5.6.1 is recommended if you wish to use Bundle::Bugzilla) 3.DBI Perl module 4.Data::Dumper Perl module 5.Bundle::Mysql Perl module collection 6.TimeDate Perl module collection 7.GD perl module (1.8.3) (optional, for bug charting) 8.Chart::Base Perl module (0.99c) (optional, for bug charting) 9.DB_File Perl module (optional, for bug charting) 10.The web server of your choice. Apache is recommended. 11.MIME::Parser Perl module (optional, for contrib/bug_email.pl interface)

39 Landfill: The Bugzilla Test Server http://landfill.mozilla.org/

This demonstration is taken from the above link. Requires e‐mail address ‐ to open account

Bugzilla Trunk Demo ‐ A demo installation running the "trunk" (meaning, very latest unstable)

40 Welcome to Bugzilla

41 Pick a product

42 Bug report

43 Starting to enter a bug

Bugzilla suggests possible duplicates. Why is this important?

44 45 Making sense of it all

Status –open bugs • UNCONFIRMED ‐ just added to the database. Not confirmed that this bug is valid. Can either change to CONFIRMED (if confirmed) or directly to RESOLVED (if it is resolved). • CONFIRMED ‐ a recently filed actual bug. If someone is working on it is changed to IN_PROGRESS or directly to RESOLVED (if it is resolved). • IN_PROGRESS ‐ can change to CONFIRMED if directed to another person, or resolved and become or directly to RESOLVED (if it is resolved).

46 Making sense of it all

Status –closed bugs • RESOLVED ‐ code changed, now it is QA’s turn. Can either be reopened or if QA approve change to VERIFIED. • VERIFIED ‐ QA approved bug should be gone now –final state. Other options • FIXED a fix for this bug is checked into the tree and tested. • INVALID not a bug. • WONTFIX bug that there is no plan to fixed. • DUPLICATE already appeared • WORKSFORME bug can’t be reproduced or explained –waiting for additional information which may lead to reopening of bug. 47 Life cycle of a bug

Taken from http://wiki.eclipse.org/Image: BzLifecycle.png

48 Important fields

• Assignee ‐ the person in charge of resolving the bug. • Bug ID ‐ the numeric id of a bug, unique within this entire installation of Bugzilla. • CC ‐ users who may not have a direct role to play on this bug, but who are interested in its progress. • Classification ‐ bugs are categorized into Classifications, Products and Components. classifications is the top‐level categorization. • Component ‐ second‐level categories; each belongs to a particular Product. Select a Product to narrow down this list. • Depends on ‐ the bugs listed here must be resolved before this bug can be resolved. • Reporter ‐ the person who filed this bug. • Severity ‐ how severe the bug is, or whether it's an enhancement.

49 Bugzilla Report Generator

50 Report selected

51 Generated report table format

52 Generated report

53 Simple search

54 Advanced search

55 Change over time

56 Old Charts

57 Bug Count

58 Create Chart ‐ 1

59 Create Chart ‐ 2

60 New Chart

61 How to write bug reports

Seems that writing bug reports is an art: The report should be: • Concise • Clear • Only one bug per report • Don’t confuse fact with speculation

!! – A bug report should contain enough information to reproduce the bug.

(for more guidelines: https://landfill.bugzilla.org/bugzilla‐tip/page.cgi?id=bug‐writing.html)

62 http://trac.edgewall.org/

Most of the material below has been taken from: http://trac.edgewall.org/wiki/WikiFormatting

63 What is Trac?

Enhanced wiki and issue tracking system for projects. Important features: • web based • minimalistic approach • extensive configurability and many more features

64 Wiki formatting rules examples

http://trac.edgewall.org/wiki/WikiFormatting

65 Trac tickets Trac has a database for tickets. Ticket Fields • Reporter —The author of the ticket. • Type —The nature of the ticket (for example, defect or enhancement request). • Component —The project module or subsystem this ticket concerns. • Version — Version of the project that this ticket pertains to. • Keywords —Keywordsthat a ticket is marked with. Useful for searching and report generation. • Priority —The importance of this issue, ranging from trivial to blocker. A pull‐down if different priorities where defined. • Milestone —When this issue should be resolved at the latest. A pull‐ down menu containing a list of milestones. • Assigned to/Owner —Principal person responsible for handling the issue.

66 Trac tickets editing

Some Trac installations may put restrictions in place about who can change what. For example, the default installation doesn't permit to non‐ authenticated users ("anonymous" users) to change anything, even to comment on an issue, for obvious spam prevention reasons. Check the local contributing policy, which you can usually find on the front page WikiStart, or contact your local Trac administrator.

67 Trac project monitoring

Monitoring Trac can be done by RSS (Really Simple Syndication)

Trac tells you when you can use the RSS via the standard orange XML icon.

68 Trac reports

Trac timeline • Reports Trac events in chronological order including a brienf description and the name of the person responsible Type of creation and changed events reported: • Wiki pages • Tickets • Source code Also reports milestones achieved. Of course: filters can be applied

69 Trac reports http://trac.edgewall.org/report/1

70 Trac timeline http://trac.edgewall.org/timeline

71 Trac project monitoring

Monitoring Trac can be done by RSS (Really Simple Syndication)

Trac tells you when you can use the RSS via the standard orange XML icon.

72 Trac Installation

Required 1. Python 2. Database, SQLite, PostgreSQL, or MySQL. And its Python binding 3. Genshi templating system ‐ for HTML rendering. 4. Setuptools Optional • Apache –web server • Subversion and the corresponding Python binding 73