8. Quality Assurance

Size: px

Start display at page:

Download "8. Quality Assurance"

Geraldine Park
6 years ago
Views:

1 8. Quality Assurance Prof. Dr. Dirk Riehle, M.B.A. Friedrich Alexander-University Erlangen-Nürnberg Version of Agile Methods by Dirk Riehle is licensed under a Creative Commons Attribution- ShareAlike 3.0 Unported License. Based on a work at dirkriehle.com.

4 Content of Quality Assurance Chapter 1. Quality Assurance Quality and quality assurance Types of tests and testing Traditional vs. agile QA 2. Principles General principles Coding guidelines Collective code ownership 3. Programming Refactoring Test-first programming Test-driven Development 4. Team Collaboration Configuration management Build management Continuous integration Pair programming 2012 Dirk Riehle - All Rights Reserved 4

5 Quality (Definition) Definition (Relative) The quality of a software system is the degree to which it conforms to its stakeholders' (sponsors, users, developers) expectations. Conformance Verified against specification Problematic if there is none Allows for good enough As established in feedback loop Definition (Absolute) The quality of a software system is the preferential ordering defined by its stakeholders when compared with alternative options. Preference Better user experience More complete functionality Less bugs, more robust Better maintainable 2012 Dirk Riehle - All Rights Reserved 5

6 Quality Assurance (Definition) Definition Quality assurance is the process of ensuring that a software system has a defined degree of quality. Assurance Process Overall quality is typically realized by assuring the quality of the individual practices and Process Practices A.k.a. constructive, internal Conformance with definition External validation (CMMI) Constituent Parts A.k.a. external assurance Mostly, artifact testing constituent parts that are used to create and make up the system Dirk Riehle - All Rights Reserved 6

7 Software Testing Component Tests A component test tests an isolated component, verifying it against specified component behavior. Acceptance Tests An acceptance test tests a system as a whole, verifying it against specified functional requirements. Black-box Tests A black-box test derives its test functions and values from the specification of the system. White-box Tests A white-box test derives its test functions and values from an analysis of the systems internals. And many other types of tests 2012 Dirk Riehle - All Rights Reserved 7

8 Traditional vs. Agile Quality Assurance Traditional QA SD and QA are separate groups, separate people SD and QA follow different schedules SD and QA are frequently at odds with each other Agile Methods QA SD and QA are one group of people SD and QA work is integrated with each other Same person does SD and QA for one feature 2012 Dirk Riehle - All Rights Reserved 8

12 Pair Programming (Practice) Definition Pair programming is programming carried out by pairs of programmers, where one programmer implements, and the other programmer reviews. Properties Similar situations Programmer and reviewer Driver and co-driver Pilot and navigator Effectiveness The effectiveness is debated. One study shows that one pair is more effective than two individual programmers [L1] Dirk Riehle - All Rights Reserved 12

for small stuff Don't overheat, take a break Switch

13 Pair Programming (Continued) Find comfortable partner Switch roles often Communicate regularly Don't force it for small stuff Don't overheat, take a break Switch partners at times 2012 Dirk Riehle - All Rights Reserved 13

14 Agile vs. Open Source Review Process Agile Methods Coding Guidelines Code more often read than written Make it easy to get acquainted Open Source Coding Guidelines Code more often read than written Showing respect for project Collective Code Ownership Development is feature by feature Typically co-located development Everyone has write access Individual Code Ownership Development is module by module Typically distributed development Strictly regulated write access Pair Programming Changes are reviewed directly Everyone's a peer Patch Review Changes are submitted for review Two-class reviewing hierarchy 2012 Dirk Riehle - All Rights Reserved 14

16 Test-First (Practice) [B1] Definition Test-first is a programming practice in which developers iterate over an 1. add new or enhance test 2. make test work loop, where programming application functionality is a byproduct of making the tests work. Properties Clarifies code functionality and interfaces Improves code quality through second use scenario Builds up test suite for continuous integration (later) 2012 Dirk Riehle - All Rights Reserved 16

17 Test-First (Example) public class TagsTest extends TestCase { public void testastag() { assertequals(tags.astag("flo wer"), "flower"); 1 public class Tags { public static String astag(string n) { return "flower"; public class TagsTest extends TestCase { public void testastag() { assertequals(tags.astag("flo wer"), "flower"); assertequals(tags.astag(" 35j lnm#&in>b << f2"), "35jlnminbf2"); assertequals(tags.astag(",,,,,,"), ""); 2 public class Tags { public static String astag(string n) { StringBuffer result = new StringBuffer(n.length()); for (int i = 0; i < n.length(); i++) { char c = n.charat(i); return result.tostring(); 2012 Dirk Riehle - All Rights Reserved 17

21 Tool Support for Test-First Programming JUnit Is a unit testing framework Supports tests and test suites Supports test setup/fixtures Is small and easy to learn Is not just for unit tests Alternatives TestNG (Java Unit Testing) xunit (other languages) JUnitMax (commercial) (Selenium) JUnit popularized unit testing: Never in the field of software development have so many owed so much to so few lines of code. [M1] 2012 Dirk Riehle - All Rights Reserved 21

22 JUnit Key Concepts Test Case Is a test method Uses assertions etc. Test Suite Is a grouping mechanism Builds a tree of test cases Test Failure Test failure indicates failing test Test error indicates bug Setup Methods Create simple test setup Are before and after method Test Setup Create complex test setup Are realized as Decorator Test Result Collects test failures Is a Collecting Parameter 2012 Dirk Riehle - All Rights Reserved 22

23 JUnit Runtime Instantiation A test suite groups a set of further test suites or test cases The unit test hierarchy typically mirrors the package structure Tests can be run starting with any node in the hierarchy :TS :TS :TS :TS :TS :TC :TC :TC :TC :TC 2012 Dirk Riehle - All Rights Reserved 23

24 TagsTest (TestCase Class, JUnit 3.8) public class TagsTest extends TestCase { public static void main(string[] args) { junit.textui.testrunner.run(tagstest.class); public TagsTest(String name) { super(name); public void setup() { // no setup public void testastag() { assertequals(tags.astag("flo wer"), "flower"); assertequals(tags.astag(" 35j lnm#&in>b << f2"), "35jlnminbf2"); assertequals(tags.astag(",,,,,,"), ""); public void testasstring() { Tags tags1 = new Tags("tag1, tag2"); assertsame(tags1.getsize(), 2); assertequals(tags1.asstring(), "tag1, tag2"); assertequals(tags1.asstring(true, '+'), "tag1 + tag2"); 2012 Dirk Riehle - All Rights Reserved 24

25 Test Hierarchy (TestSuite Class, JUnit 3.8) public class TestRunner { static public void run(class testclass) { run(new TestSuite(testClass)); public class TestSuite implements Test { private Vector ftests= new Vector(10); public TestSuite(final Class theclass) { Class superclass= theclass; Vector names= new Vector(); while (Test.class.isAssignableFrom(superClass)) { Method[] methods= superclass.getdeclaredmethods(); for (int i= 0; i < methods.length; i++) { addtestmethod(methods[i], names, theclass); superclass= superclass.getsuperclass(); if (ftests.size() == 0) { addtest(warning("no tests found in "+theclass.getname())); 2012 Dirk Riehle - All Rights Reserved 25

28 How to Write a Test? 2 / 2 Unit Testing Test all functions Think from features Cover all edge cases Acceptance Testing Think from user interface Test all relevant parameters Cover all edge cases 2012 Dirk Riehle - All Rights Reserved 28

29 Tell a Friend (Acceptance Test Example) public class TellFriendTest extends TestCase { protected UserSession session; protected WebFormHandler handler; public void setup() { ModelMain.configureWebPartTemplateServer(); Wahlzeit.configurePartHandlers(); session = new UserSession("testContext"); session.setconfiguration(languageconfigs.get(language.english)); ContextManager.setThreadLocalContext(session); public void testtellfriendpost() { Address from = Address.getFromString("info@wahlzeit.org"); Address to = Address.getFromString("fan@yahoo.com"); Server.setInstance(new Mock Server(from, to, bcc, subject, body)); Map<String, String> args = new HashMap<String, String>(); args.put(tellfriendformhandler. _from, from.asstring()); args.put(tellfriendformhandler. _to, to.asstring()); handler.handlepost(session, args); 2012 Dirk Riehle - All Rights Reserved 29

30 Tell a Friend (Acceptance Test Example) public class TellFriendTest extends TestCase { protected UserSession session; protected WebFormHandler handler; public void setup() { ModelMain.configureWebPartTemplateServer(); Wahlzeit.configurePartHandlers(); session = new UserSession("testContext"); session.setconfiguration(languageconfigs.get(language.english)); ContextManager.setThreadLocalContext(session); public void testtellfriendpost() { Address from = Address.getFromString("info@wahlzeit.org"); Address to = Address.getFromString("fan@yahoo.com"); Server.setInstance(new Mock Server(from, to, bcc, subject, body)); Map<String, String> args = new HashMap<String, String>(); args.put(tellfriendformhandler. _from, from.asstring()); args.put(tellfriendformhandler. _to, to.asstring()); handler.handlepost(session, args); RATHER PAINFUL 2012 Dirk Riehle - All Rights Reserved 30

33 Roman Numerals Explained Base Values 'I' = 1 'V' = 5 'X' = 10 'L' = 50 'C' = 100 'D' = 500 'M' = 1000 Parsing Rules Smaller base cases to the right are added to value Smaller base cases to the left are subtracted Rule 2 takes precedence over rule Dirk Riehle - All Rights Reserved 33

35 Video Lessons Observations 1 / 2 Implements tests first, functions second Provides trivial implementations first Incrementally provides full implementations Programs with no slack at all, only progress Observations 2 / 2 Uses many IDE refactoring functions Views test code and function code in parallel windows Uses JUnitMax for unobtrusive feedback Deletes code after finishing coding kata 2012 Dirk Riehle - All Rights Reserved 35

36 Advanced Test-First Practices 1 / 2 Test Execution Define context With test setups Create test databases Use test data builders Reset data to clean state With test doubles Test Psychology Cope with run-time Create different setups Create different test suites Use null objects Use stub objects Use mock objects 2012 Dirk Riehle - All Rights Reserved 36

37 Advanced Test-First Practices 2 / 2 Testing Concurrency Derive invariants Don't overspecify / constrain Testing Legacy Code Define component boundary Instantiate with test doubles Use modern tools Use locks, conditions, etc. Avoid signal(), wait() Still, this is hard to do right! Use proactive mechanisms Test against expected behavior May not need to understand code If you have to refactor code Write unit tests first Refactor in small steps 2012 Dirk Riehle - All Rights Reserved 37

38 Test-Driven Development (TDD) Definition Test-driven development is a development process that follows the test-first practice to implement a product requirements document like Scrum's product backlog. Please note: Test-first is the original test-driven development. The additional focus on working off a PRD is mine (DR). Properties TDD grows the product incrementally and steadily TDD teams can release after every feature implementation TDD creates code of pristine (and lean) quality 2012 Dirk Riehle - All Rights Reserved 38

39 Test-Driven Development Illustrated feature n+2 feature n+1 on to next feature enhance test suite feature n test suite n implementation n feature n-1 feature n-2 test suite n-1 test suite n-2 implementation n-1 implementation n Dirk Riehle - All Rights Reserved 39

40 Test-Driven Development Core Process 1. Translate partial or full feature description into test suite 2. Implement feature to fulfill ( green-bar ) test suite 3. Revise test suite from new insights 4. Refactor test suite to keep design and code clean 5. Refactor implementation to keep design and code clean 6. Move on when test suite is complete and all tests succeed 3 6 feature 1 2 test suite implementation Dirk Riehle - All Rights Reserved 40

41 Quiz: Test-First Programming 1. You are programming a unit test for the Money.divideBy() method. Should you also test for any possible ArithmethicException? Never Always Depends 2. Your unit tests for the Money class all need a few example values to work with. Where should you create them? In each test case method In the test class' setup method In a separate test setup class 2012 Dirk Riehle - All Rights Reserved 41

43 Continuous Integration (Practice) Definition Continuous integration is a defined code integration process, where 1. Developers push regularly 2. Every push triggers a build 3. An executable is created 4. All tests / tools are run 5. Feedback is provided to all developers and any development manager. The goal is to receive immediate feedback if anything is wrong and to be able to pinpoint it right away. Properties Is a staged process From repository to build server From build to integration server From integration to test server Is a wholly automated process With no intervention needed Where feedback is made visible 2012 Dirk Riehle - All Rights Reserved 43

44 Tool Support for Continuous Integration Specialized tools Build tools: make, ant, Metrics tools: jdepend, Sonar, Integration tools Utilize specialized tools For example, Hudson or Jenkins Visualization tools Historical: lava lamps Today: dashboards 2012 Dirk Riehle - All Rights Reserved 44

48 Continuous Delivery Definition Continuous delivery is a defined product delivery process, where every commit or push by a developer leads to the deployment of a new product version, if the version passes all tests. Properties Is next logical step after continuous integration Requires effective system monitoring and DevOps Is typically used in highly agile environments (websites) Continuous delivery and DevOps is a fast moving target and a possible research topic; will have to define terms like immune system Dirk Riehle - All Rights Reserved 48

7. Software Development

7. Software Development Prof. Dr. Dirk Riehle, M.B.A. Friedrich Alexander-University Erlangen-Nürnberg Version of 22.03.2012 Agile Methods by Dirk Riehle is licensed under a Creative Commons Attribution-