Software Testing and Quality Assurance

COMP 7890Fall 2013

1

Today

• Introduction 

• Software testing and QA

• Course objectives

• Activities and deliverables

2

Acknowledgement

• Some of the material used in this presentation are from course slides of – Prof. Lionel Briand

• Software Verification and Validation course (2011)

– Prof. Steve Easterbrook  • Engineering Large Software Systems course (2012)

3

Introduction to the Class

• Date/hour– Tue/Thu 2:30pm‐3:50pm

• Location– E2‐ 461 EITC

• Course webpage– http://cs.umanitoba.ca/~hemmati/courses/comp7890/fall2013/

4

Instructor

• Hadi Hemmati

• Contact– E2‐586 EITC– hemmati@cs.umanitoba.ca– Please include “COMP 7890” in the subject

• Office hours– Tue/Thu 11:00a.m.‐12:00p.m., or by appointment

5

My Background• Worked as a software engineer

– @ a telecommunication company 

• Ph.D. on model‐based testing from Norway– Worked with testing teams @ Cisco Systems Inc.

• Postdoc on mining software repositories at Queens University– Worked with Blackberry (RIM) testing teams

• Postdoc on analytics and cloud at University of Waterloo– Worked with CA Technologies Inc. 

6

My Research Area• Software QA

– With focus on testing

• Software engineering– Empirical studies– Model‐driven software engineering– Search‐based software engineering– SE for new domains, e.g. Could computing

• Software Analytics– Mining Software Repositories– Application of machine learning and data mining in SE

7

Research Lab

• Software Engineering and Analytics– Hiring – Contact me, if you are a course‐based student interested to switch to thesis‐based 

• Look at my publications for more details– http://cs.umanitoba.ca/~hemmati/publications.html

8

How much do you know about testing and QA?

• Nothing

• Done some testing of own code/know basics through SE courses

• Taken specialized QA, testing, V&V, etc. courses

• Have professional testing experiences 

9

Experience in presentation, writing, and review? 

• Taken scientific writing and presentation course

• Taken other seminar‐based courses

• Written papers 

• Presented in a conference/workshop

• Done conference/journal papers review 

10

Why Do We Need to Study Software Testing and QA?

11

Software Is Everywhere

12

Software Engineering Is a Very Human‐Intensive Process

13

Errors Occur Wherever Humans Are Involved in Taking Actions and Making Decisions

Incident

Failure

Fault

Error

results in

causation

propagation

14

Example 1

• Incident: Your mail server doesn’t let you log in.

• Failure: The user account cannot be accessed in the user database. 

• Fault: The user database can not be reached.

• Error: There was no backup user database in the system.

15

Example 2• Fatal Therac‐25 X‐ray Radiation 

• In 1986, a man in Texas received between 16,500‐25,000 radiations in less than 10 sec, over an area of about 1 cm.  

• He passed away 5 months later.

• The root cause of the incident was a SW failure 

16

Example 2: Cont.

• Incident: A patient passed away

• Failure: The device applied higher frequency of radiations than what was safe. Safety range: [1…10,000 Hz]. 

• Fault: The software controller of the device did not have a conditional block (if …. else statements) to perform range checking on the frequency of the radiation to be applied

• 2 Errors:• The SW developer of the device controller system had forgotten to 

include a range checking conditional block on the frequency of the radiation to be applied.

• The device operator was NOT supposed to enter anything outside [1…10,000 Hz] range.

17

Software Is (almost) Always Buggy

First bug was a real insect: Engineers found a moth in the system (1947)

Grace Hopper

18

Failures and Incident Are Everywhere

19

Examples of Software Failure

Northeast blackout (2003)

Toyota anti‐lock brake (2010) NASDAQ trading outage (2013)

Explosion of Ariane 5 (1996)

20

Dealing with SW Faults

Testing

Fault Handling

Fault Avoidance Fault ToleranceFault Detection

Debugging

ComponentTesting

IntegrationTesting

SystemTesting

Design Methodology

Automated Verification

AtomicTransactions

ModularRedundancy

CorrectnessDebugging

PerformanceDebugging

InspectionsRequirements Engineering

21

What is Covered in this Course?• Covered 

– Testing• Discussed

– Inspection and code review– Program analysis

• Not covered– Model checking– Debugging– Performance analysis and measurement– Reliability engineering and fault tolerance– Safety analysis– Etc.

22

Testing as a Practical QA Technique

NIST study (2002): bugs cost $59.5 billion a year. 

~80K Job posting for testers in indeed.com

Systems getting more complex  ‐ 20+ change/minute‐ 50M tests/day

23

Basic Concepts

24

Verification Approaches

“Program testing can show the presence of bugs, never their absence” (Dijkstra)

25

Course Objectives

• At the end of this course students are expected to– Know the basic concepts of software testing and QA

• Through lectures – Be familiar with the state‐of‐the‐art techniques in testing and QA

• Through research papers– Be able to read, present, and critique research papers in the field

• Through delivering presentations and discussions in class– Be able to apply a few testing techniques on real‐world applications

• Through final projects

26

Any Question?

Activities: Presentations (1)

• Lecture presentation (11 topics)– Two students present each lecture (60 min.)

• You decide how to split the work• Both are responsible for proper presentation and answering questions

• Each presenter will be evaluated individually 

– Others also read the material before the class and submit 2 intellectual questions with answers, about the topic. Then we discuss in class (20 min.) 

• Email me by the midnight before the scheduled class

28

How to Present a Lecture?

• Slides are available for most chapters– http://ix.cs.uoregon.edu/~michal/book/index.html– Feel free to use or modify 

• Key points– Covering all important material (you may check with me to make sure you know what are the key points)

– Time management– Clarity of the presentation

• General advices on presentation– http://homes.cs.washington.edu/~mernst/advice/giving‐talk.html

29

Which Type of Questions?• Clarifying questions are welcome 

– but won’t be considered as one of the two questions• Specific to the topic (you have to read) and smart (the answer is not there)

– BAD • Q: “Is model‐based testing (MBT) scalable?”• A: “No much”

– Fair• Q: “Given the fact that model‐based testing requires models of the system, is it really 

scalable to large scale systems?”• A: “Since modeling is manual it is a hinder for MBT scalability”

– GOOD• Q: “Which phase in model‐based testing has the most scalability issues and why?” • A: “Modeling phase, since the rest can be potentially fully automated. Though the state 

space explosion in theory can happen in the automation phases but in practice modularity and abstraction level of testing avoids state explosion.

• You also need to discuss about the questions in the class

30

Evaluation Method

• Both presentation and discussions will be graded by the instructor– Lecture presentation (10 points)

• Knowing what you are presenting and ability to answer the questions (5 points)

• Time management and properly covering main parts of the material (3 points)

• Clarity of the presentation (2 points)– Questions (20 points for whole semester questions. Part of “active participation”)

• Relevant, specific, correct, smart, well discussed in the class• You have to provide an answer to initiate the discussion

31

Activities: Presentations (2)

• Research paper presentation (20 papers)– One student per paper (20 min.)– One student may present Topic 11 instead of research paper  her/his second lecture must be different than Topic 11

– Others also read the papers before the class and submit one critical question, with answer, per paper. 

• Then we discuss in class (20 min. per paper) • Email me by the midnight before the scheduled class

32

How to Write a Critical Question? 

• Can be a question, comment, proposal, etc.• Questions

– Same as lecture questions• Comments

– Criticize the correctness, validity, practicality, etc.– Relation to other techniques/papers discussed

• Proposals– Potentials for extension, improvement, and application of the paper 

33

Evaluation Method

• Same as lecture presentation (10 points)

34

Activities: Final Project• Teams of 2‐3 students 

– Individual projects in exceptional cases • Each team decides on a topic/high‐level description, after 

discussing with the instructor– Sends a written proposal by Oct. 1st (tentative)– Gets informal feedback (F2F or by email)

• Project (Start soon!)– Review related work (send it by Nov 1st, tentative)– Implement, experiment, and analyze– Presents the results (last three sessions)– Write a report (Dec 10th tentative)

• Review– One or two project reports of the other teams (Dec 17th tentative)

35

Projects• Topics

– Applying QA techniques on your research – Applying your research on QA– Apply QA techniques in new domains

• Mobile, cloud, etc.– Compare QA techniques – Replicate a study with several programs

• Systems– Your choice: sourceforge, github, lab program, etc.– Should be confirmed by the instructor 

• Size, complexity, relevance, etc.• Tools

– Either implement algorithms, or use open source/trial versions– Dealing with the tool/implementation issues is your responsibility 

36

Project Proposal

• First get confirmation from the instructor about the idea

• Write one page (free style)– Idea– Systems under test– Research questions and the experiment design

• Evaluated by (5 points)– How novel and valid the idea is?– How big, complex, and interesting the systems are?– How precise the experiment design is?

37

Project Presentation

• Similar to the research paper presentation• 20 min. talk + 10 min. discussion• No pre‐submitted questions• The project should be complete and the results should be presented

• Grading (10 points)– Group presentation but individual evaluation– The research quality (5 points)– The presentation quality (5 points)

• Graded as before

38

Project Reports• Write a report like the reviewed research papers 

– 10 pages, IEEE conference style, double col.– Outline: 

• Abstract • Intro• Motivation• Background• Related work (1 pages)  should be submitted before• Methodology • Experimentation: (context, design, RQs, results, discussion, validity)• Conclusion• References

– Advices on research paper writing • http://web.engr.illinois.edu/~taoxie/publications/writeissues.pdf• http://web.engr.illinois.edu/~taoxie/publications/writepapers.pdf

39

Grading the Project Reports (30 points)

• Originality (5 points)– How novel it is? Except for replication studies

• Correctness (10 points)– Of the algorithms, designs, implementations, experiments, and 

conclusions• Contribution (5 points)

– How important are the findings• Related work (5 points)//note that it has an earlier deadline

– Are the important related work discussed and if possible compared

• Writing (5 points)– Same criteria as the other technical writing evaluation criteria 

40

Review of the Project Reports • How to write?

– Critical thinking• What to write?

– One page free style– A paragraph summary– Three points in favor, with details– Three points against, with details– Other comments, e.g., typos– Plus the scores for (originality, correctness, contribution, RW, and writing)  

• Advices on reviewing a paper– http://homes.cs.washington.edu/~mernst/advice/review‐technical‐paper.html

• Grading (15 points)– Summary, comments, and scores (5 points) – Negative/Positive aspects of the report (5+5 points)

41

Attendance

• Active participation in the class is mandatory– Max two absences are allowed without fine (you can use your grace days for late deliveries or missed classes. If not used you get 5 bonus points per unused grace day)

• You can NOT miss your presentation days (‐10‐10)– After using the grace days, your total score reduces by 10 points (out of 100) per day of delay / absence

• You need to be in class to get “active discussion” points• If a group delivers a report late all members get the negative mark

42

Summary of Grading• Active participation + questions + discussions (20 points)• Lecture presentation (10 points)• Paper presentation (10 points)• Proposal (5 points)• Project presentation (10 points)• Project report, including the related work (30 points)• Project review (15 points)

• Attendance mandatory – 2 grace days (can be used for late delivery of proposals, reports, and reviews, 

as well)– ‐10 points per day, afterward 

• Bonus points – unused grace days (5 per day)

43

Reading Material• Books (available in the library “course reserve” or ebook)

– Book chapters listed in the schedule• Mauro Pezzè and Mivhal Young, “Software Testing and Analysis: Process, 

Principles, and Techniques”, John Wiley & Sons, 2008.• Andy Oram and Greg Wilson, “Making Software: What Really Works, and Why 

We Believe It”, O’Reilly Media, 2010– Other useful books

• Aditya P. Mathur, “Foundations of Software Testing”, Addison‐Wesley Professional, 2008

• Paul Ammann and Jeff Offutt, “Introduction to Software Testing”, Cambridge University Press, 2008

• Robert V. Binder, “Testing Object‐Oriented Systems ‐Models, Patterns, and Tools”, Addison‐Wesley,1999

• Mark Utting and Bruno Legeard, “Practical model‐based testing: a tools approach”, Morgan Kaufmann Publishers, 2007.

• Research papers (available through library)– Listed in the schedule

44

How to Read the Schedule?6 08/10/2013 B Test execution

System testing and regression testing TBA [P] Ch. 17[P] Ch. 22

10/10/2013 B Inspection and Code review Test driven development TBA

[P] Ch. 18 [O] Ch. 18 [3] [O] Ch. 12

7 15/10/2013 B Symbolic execution Program analysis TBA [P] Ch. 7

[P] Ch. 19 17/10/2013 A/B Search-based software testing TBA [4]

8 22/10/2013 A Model-based testing Object oriented testing TBA [5] and [6]

[P] Ch. x: Chapter x from Mauro Pezze’s book (in course reserve in the Engineering Library)[O] Ch. y: Chapter y from Andy Oram’s book (in course reserve in the Engineering Library)[1‐25] Papers from the following list of papers (accessible through the library)

Each session, I may also be able to lend the Mauro Pezze’s book to the students who are presenting in the next session (As soon as I get a copy that I have ordered).

If you don’t know how to access research papers, let me know and I arrange library representative to explain it to you in class. 

45

Presentation Schedule 

• I will share a Google Doc with you by 5 p.m. today(your registered email)– https://docs.google.com/spreadsheet/ccc?key=0AtlyN0BXekTOdEFBRkhCbU5CejZ5Zmxid0FRTkRjeUE#gid=0

– Look at the topics and the dates– Fill out your name as the presenter in one lecture and one paper by FRIDAY (Sept. 6th), 5 P.M.

• Don’t overwrite!• I will randomly assign you, if you don’t by the deadline!

– I will email you the final schedule as .pdf after the deadline

46

Important Dates

47

Fill out the presenters’ schedule From Sept. 5th, 5 p.m. to Sept. 6, 5 p.m.

Your 2 presentations dates T/Th between Sept. 12 and Nov. 21

Every night before a session M/W between Sept. 11 and Nov. 20

Proposals due Oct. 1  (tentative)Related works due Nov. 1 (tentative)Project presentations Nov. 26 to Dec. 3 Final reports due Dec. 10 (tentative)R t i d D 17 (t t ti )

Any Question?

Next session

• Class– Introduction to software testing – Overview of the schedule – No obligatory reading. No questions.

• You– Fill out the Google Doc by Friday 5 p.m.– Start thinking about your project– Ask any question about the course and its logistics

49

REMEMBER to put COMP7890 in the subject of any course‐related email you send me