MACIASZEK, L.A. (2007): Requirements Analysis and System Design, 3rd ed. Addison Wesley, Harlow England ISBN 978-0-321-44036-5 Chapter 9 Quality and Change Management © Pearson Education Limited 2007 TopicsTopics Quality management • Quality assurance • Quality control Change management • Change requests • Traceability © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 2 1. Quality management Quality management is part of an overall software process management, along such other activities as people, risk and change management. Quality management divides into quality assurance and quality control. MainMain conceptsconcepts Testing is not just the debugging of programs – it is part of quality management: • Quality assurance is about proactive ways of building quality into a software system • Quality control is about (mostly reactive) ways of testing the quality of a software system Test driven development builds quality into a software system by an outright demand that a test code has to be written before the application code and that the application must pass the test to be quality assured Change management is a fundamental aspect of the overall project management Traceability underlies testing and change management © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 4 QualityQuality managementmanagement Part of an overall software process management along with: • people management, • risk management and • change management. To be performed in parallel with and in addition to project management (scheduling, budget estimation, tracking project progress). • should have its own budget and schedule • one of its tasks should be to ensure quality in project management per se • the actions and outcomes of quality and change management may involve changes to the project schedule and budget baselines, also known as the performance measurement baselines © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 5 SoftwareSoftware qualitiesqualities correctness reliability robustness performance usability understandability maintainability (repair ability) scalability (evolvability) reusability portability interoperability productivity timeliness visibility © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 6 QualityQuality assuranceassurance Software Quality Assurance (SQA) team Techniques: • Checklists •Reviews – Walkthroughs – Inspections •Audits © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 7 ChecklistsChecklists A predefined list of to-do points that need to be scrupulously checked off in the development process. Processes differ from project to project Æ checklists cannot be fixed for ever • Also, the “baseline” checklists need to be modified to account for new IT technologies and changes in IT development paradigms. © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 8 WalkthroughsWalkthroughs A type of formal brainstorm review that can be conducted in any development phase A friendly meeting of developers, carefully planned and with clear objectives, an agenda, duration, and membership A few days prior to the meeting, the participants are handed the materials to be reviewed During the meeting the problems need to be pinpointed but no solutions attempted Acknowledged problems are entered on a walkthrough issues list The list is used by the developer to make corrections to the reviewed software product or process A follow-up walkthrough may be necessary © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 9 InspectionsInspections Like the walkthrough, an inspection is a friendly meeting but done under close supervision by the project management The purpose is also to identify defects, validate that they are in fact defects, record them, and schedule when and by whom they have to be fixed Unlike the walkthroughs, inspections are conducted less frequently, may target only selected and critical issues, and are more formal and more rigorous An informational meeting usually takes place one week before the inspection meeting During the meeting, the defects are identified, recorded and numbered Immediately after the meeting, the moderator prepares the defect log – recorded in a change management tool The developer is normally requested to resolve the defects quickly and record the resolution in the change management tool The moderator – in consultation with the project manager – submits the development module to the Software Quality Assurance (SQA) group in the organization. © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 10 AuditsAudits A quality assurance process that is modeled on and similar in required resources to traditional accounting audits. Positioned within the overall software process management: • It places risk management in its view. • It relates to the strategic importance of IT to the enterprise and addresses IT governance. • It looks at the alignment of the audited project with IT investments in the context of the enterprise mission and business objectives. Differences between an audit and other QA techniques: • the producer of the audited product or process is usually a team, not a person, • an audit can be performed without the presence of the producer, • audits make extensive use of checklists and interview and less so of reviews, • audits can be external, i.e. conducted by auditors external to the organization, • an audit can last from a day to a week or more (but is always restricted to strictly defined scope and objectives). © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 11 TestTest drivendriven developmentdevelopment The idea is to write test cases and scripts as well as test programs before the application code (the unit under test) is developed (designed and programmed) • application code is written as a response to a test code and the test code can be used to test the application code as soon as it is available Advantages • allows to clarify user requirements (and the use case specifications) before the programmer writes the first line of the application code • drives in fact the software development, not just the software verification • supported by testing frameworks, such as JUnit © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 12 JUnitJUnit testingtesting public class XXXTest extends TestCase { public XXXTest(String testName) { super(testName); Test } public void testSomething() { run(TestResult) ... } public void testSomethingElse() { ... } public void runTest() { TestCase testSomething(); TestSuite testSomethingElse(); run(TestResult) } runTest() run(TestResult) } setUp() addTest(Test) tearDown() XXXTest TestResult © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 13 TestingTesting typestypes andand developmentdevelopment phasesphases Design Analysis System Customer User Programming specifications specifications constraints requirements environment Unit test Integration Functional Constraint Acceptance Installation test test test test test ReusableReusable components components Unit Performance, Security, test System Scalabilty, deployed etc. © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 14 TestTest conceptsconcepts Business Use Use Case Enhancements Case Document Documents Document Feature 1 Use Case Req 1 Enhancement 1 Feature 2 Use Case Req 2 Enhancement 2 … … … Test Plan Test Case Defects Document Documents Document Test Case 1 Test Req 1 Defect 1 Test Case 2 Test Req 2 Defect 2 … … … © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 15 TestTest casecase documentdocument © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 16 TestTest environmentenvironment © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 17 TestingTesting systemsystem servicesservices Informal testing Methodical testing • Non-execution-based (formal reviews) – Walkthroughs – Inspections • Execution-based – Testing to specs – Testing to code © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 18 TestingTesting toto specsspecs Execution-based test type • applies to executable software products, not to documents or models • also known as – black-box testing – functional testing – input/output driven testing Test module treated as a black box that takes some input and produces some output (no need to understand the program logic or computational algorithms) Requires that the test requirements are derived from the use case requirements, and then identified and documented in a separate test plan and test case documents Test scenarios can be recorded in a capture-playback tool and used repeatedly for regression testing Likely to discover defects normally difficult to catch by other means, such as missing functionality © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 19 TestingTesting toto specsspecs Inputs causing anomalous behavior Input set Ie Test Unit (as black box) Outputs which reveal the presence of defects Output set Oe [1735] © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 20 FeasibilityFeasibility ofof testingtesting toto specsspecs Example 1: Consider price calculation based on two factors: 5 types of commission and 7 types of discount → 35 test cases Example 2: Consider 20 factors, each taking on 4 values → 420 or 1.1 × 1012 test cases Conclusion: Combinatorial explosion [1816] © Pearson Education 2007 Chapter 9 (Maciaszek - RASD 3/e) 21 TestingTesting toto codecode Execution-based testing Also known as • white-box testing • glass-box testing • logic-driven testing • path-oriented testing Starts with the careful analysis of