Lecture 18 Software Quality Part 2 Conways Law

Lecture 18: Software Quality (Part 2) Conway’s Law: “The structure of a computer program reflects the structure of the organization that built it. ” 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Outline Last time: Software quality – what it is and who wants it? [discussed previously] Good quality and “Good enough” quality How can we measure quality? Quality / Testing myths How, when, and what to test Today: Bugs: stages and tracking over their lifetime Test-Driven Development (TDD) with Unit tests How can we improve software quality? 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

References “Professional Software Development”, by Steve Mc. Connell many other books, online resources, and discussions with professionals in the field 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Reminder A Bug’s Life Throughout its life, a bug can be in one of these states: Open (or re-opened) Work-in-progress External Resolved Can’t reproduce By design Won’t fix Postpone Fixed Closed 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Tracking Bugs and Trends: Bug Burn-Down Charts Graphs the number of bugs over time, grouped by any of their states or properties (e. g. , open, how recent, etc. ) Helps to track bug trends over the lifetime of a project. Example: [see whiteboard sketch] 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Test-Driven Development with Unit Tests 1. Write a test first (!) for a given (yet unwritten) class method – this way, tests serve as a specification 2. 3. 4. (i. e. , expressing the intent) for the class’ code (methods) Write stubs for the class’ relevant method(s) – just enough to make the test compile Fail the test – this crucial step ensures falsifiability Make changes to the class’ methods – just enough to pass the test Pass the test – ensuring that step #4 was successful 5. 6. Refactor, as necessary 7. Pass the test – ensuring that refactoring didn’t break code 8. Return to step #1 – 2011 to. Lecture cover additional intents of the CSS 360 Autumn 18 30 Nov 2011

Unit Testing – An Example using JUnit: import org. junit. *; (where the JUnit routines are) import org. junit. Test; @Before – for setting up a test suite (i. e. , set of tests) @Test – for describing an individual test in a suite Assert. assert. Equals(comment. String, intended. Value, actual. Value) [Discussing sample JUnit code – shown separately] 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Best Practices for Testing Tests must fail the first time you run them … to ensure that they are falsifiable The ideal tests are independent of each other: e. g. , with no side effects and no special order of execution Tests that are simple to write and quick to execute create an incentive to be written and run often Seek the equivalence classes for the domain you’re testing Use an established testing methodology (e. g. , SFDPO) rather than making up tests “at random” … and more 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Important Practices for Good Quality Processes Perform testing in an environment separate from the production environment The hierarchy of the QA organization is best separated (independent) and not answerable to the Development organization 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Activity Mechanisms for Raising the Quality of Software Assume you are brought in on an ongoing software project plagued by poor quality. What one or two approaches (mechanisms) would you propose to help raise the quality of the software in production? Make assumptions as needed, to concretize the question. 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18

Mechanisms for Raising the Quality of Software: Some Ideas Which of these mechanisms may help your project(s)? a) Involvement / frequent iterations with customers and other stakeholders b)Pair programming c) Code reviews (not limited to “code”; reqs/design review, etc. ) d)External auditing e) Using automated tools (e. g. , static analysis, code coverage, IDEs, etc. ) to help discover non-trivial properties that affect quality f) Refactoring g) Code integration (if not already in place) h)Testing: integration testing, regression testing, acceptance testing; automated testing; test-driven development (with unit testing) i) Component reuse j) Team building activities (or ensure) clear responsibilities within the team 30 k) Nov. Establish 2011 CSS 360 Autumn 2011 Lecture 18

Perennial Recipes for Disaster (a. k. a. Poor Quality Products) Ignore what the customers say they want – “developers surely must know better”. Put in all the features that could potentially ever be useful. Do not worry about quality aspects (and ignore the related practices) until the deadline approaches. Do not waste time on design or documentation – after all, code is the most important thing, and time is already short to do all that needs to be done anyway. … 30 Nov 2011 CSS 360 Autumn 2011 Lecture 18