EngineeringProcess.pps

Software TestingSoftware engineering processes

Course objectivesBecome familiar with the software engineering processesHave an image of the main software life cyclesPlace the testing processes into the right placeDescribe few classes of software projects and their specifics

ReferencesI. Sommerwille, Software Engineering, 8th edition, Addison Wesley, 2006 (chapter 4)G. Everett, R. McLeod: Software Testing. Testing Across the Entire Software Development Life Cycle, Wiley&Sons ,2007 (chapter 2)C. Kaner, J. Falk, H.Q. Nguyen: Testing computer software, Second edition, Wiley & Sons, 1999 (chapter 3)K. Benk, C. Andress: Extreme Programming Explained. Embrace Change. 2nd edition, Addison-Wesley Professional, 2004S. McConnell, Rapid Development:Taming Wild Software Schedules, Microsoft Press,1996

Software projectsThere are a potpourri of software projectsNo single structure or process that optimally applies to the requirements and environments for all sorts of projectsThe discipline and the art of managing projects makes the project successWhat makes the software projects different?Software Project Management*

Software Project Management

Software EngineeringWhat is software engineering?is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use.[Sommerville, Software engineering, 8th edition, 2007]is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software[IEEE, "Guide to the Software Engineering Body of Knowledge" (February 6, 2004)]Software Project Management*


Typical Phases in SoftwareRequirement analysis and SpecificationDesignImplementationTestingMaintenanceLife cycle: Establishes the order these activities are performedEstablishes the criteria for moving from one phase to the other

*Software Project Management


Software specificationThe process of establishing what services are required and the constraints on the systems operation and development.Requirements engineering processFeasibility study;Requirements elicitation and analysis;Requirements specification;Requirements validation.*Software Project Management


Requirements ValidationShowing that the requirements define what the customer wantsChecks:Validity checks compared to stakeholder needsConsistency checks related to possible conflictsCompleteness checks related to the coverageRealism checks ensuring that they could be implementedVerifiability proved by the potential of writing acceptance testsTechniques:ReviewsPrototypingTest case generationSoftware Project Management*


Software designThe process of converting the system specification into an executable system.Software designDescribes software structure that realises the specification;Describes data which is part of the systemDescribes interfaces between the system componentsDescribes the algorithms*Software Project Management


Design process activitiesChapter 4,10,11,12 SommervilleArchitectural design: sub-systems identified and documentedAbstract specification: abstract specification of the services and services constraints per sub systemInterface design: Unambiguously describes how the subsystems interactComponent design: allocation of services per componentsData structure design: data structures used in implementation being detailedAlgorithm design: algorithms being detailed*Software Project Management


Programming and debuggingTranslating a design into a program and removing errors from that program.Programming is a personal activity - there is no generic programming process.Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.*Software Project Management


Software testingVerification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer.Involves checking and review processes, system testing and acceptance testing.System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.Acceptance testing involves executing tests intended to asses the way the customer requirements were implemented.*Software Project Management


Software evolutionSoftware is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change.Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.*Software Project Management


Life cycle choicesLife-cycle: a particular way of performing activities related to different software projects phasesMain idea: keep the focus to the goalPossible goals:Improve development speedImprove qualityImprove project tracking and controlImprove client relationsMinimize overheadMinimize risksSupport software evolution*Software Project Management


*Waterfall Project PhasesSoftware Project Management


WaterfallFirst applied software modelBasis for many other modelsOrderly progress from initial concept to system testing and maintenanceReview at each phase end. Return to previous phase if no acceptance.Document driven



WaterfallPhases are discontinuous: do not overlapSuitable for stable product definitions and technologiesFind errors at early stagesMinimizes planning overheadSuitable even for un-experienced teams



Waterfall DrawbacksRisks not explicitly addressedThe product is not visible until final stagesThe stability of requirements is not a valid assumption in software developmentDiscovering missing features at the end of the cycle is very expensiveLack of flexibilityCostlyLonger schedules



Waterfall testingTesting at the end of the lifecycleNo interaction between testing activities and the development activitiesConsequence: keep the testing and development departments separateSoftware testing is considered as being a destructive processProgrammers should not test their own programs Programming organizations should not test their own programs.

V-Model*

V-Model testingStart testing activities early in the lifecycleClearly defines four kind of testing activities and their chaining:Unit testingIntegration testingSystem testingAcceptance testingTesting plans affects the development plans

Risk reduction: moving to iterations*Reproduced from the IBM testing course

Spiral models

SpiralBoehm 1988 (http://www.computer.org/portal/cms_docs_computer/computer/homepage/misc/Boehm/r5061.pdf)First major iterative model: planning spread across iterationsEnhance waterfall by early risk identificationsProcess is represented as a spiral rather than as a sequence of activities with backtracking.Each loop in the spiral represents a phase in the process. Each spiral iteration consists in a major risk elimination.No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.The last spiral iteration may be a waterfall cycle



SpiralThe result of each iteration are more refined prototypes until the released versionAdvantages:Early addressing of risks: as costs increases the risk decreasesThe management control is at least as much as in the waterfall case, improved by the existence of checkpoints at the end of each spiral iterationDisadvantagesRather complicated to manageCan be difficult to define milestones to indicate if you are ready to move to the next iteration



RUP phase model*Software Project Management


RUP phases

Inception - Define the project scope, gain agreement on project objectives, baseline the product VisionElaboration - Address key technical risks, produce an evolutionary prototype, baseline the ArchitectureConstruction - Iteratively and incrementally develop an operationaly complete productTransition - Deliver the product into the live end-user environment*Software Project Management


RUP good practice for business driven developmentAdapt The Process More processes is not necessarily betterBalance Competing Stakeholder Priorities - Manage often conflicting requirementsCollaborate Across Teams - Proper team organization and the setting up of effective collaborative environments.Demonstrate Value Iteratively - Develop software iterativelyElevate Level Of Abstraction - Use component-based architecturesFocus Continuously On Quality - Verify software quality*Software Project Management


Practices and Anti-patternsPractices:Ensure team ownership of quality for the product.Test early and continuously in step with integration of demonstrable capabilities.Incrementally build test automation.Anti-patterns (compare this with the V-model)To peer-review all artifacts and complete all unit testing before integration testing.To conduct in-depth peer-review of all intermediate artifacts, which is counter productive because it delays application testing and hence identification of major issues.

RUP disciplinesBusiness Modeling: business processes modeled as business casesRequirements: identification of actors and the development of system use casesAnalysis & Design: a design model is created using architectural models, component models, object models and sequence modelsImplementation: The components are implemented and structured into sub-systemsTest: iterative process carried out in conjunction with the implementation. System testing is performed after implementationDeployment: a release is created, distributed and installed on users systemsConfiguration & Change Management: controls change to, and maintains the integrity of, a projects artifacts.Project Management: Provide a framework for managing software intensive projects. Provide practical guidelines for planning, staffing, executing, and monitoring projects.Environment: Focuses on the activities and tools necessary to configure the process for a project

RUP*Software Project Management


RUP



RUP-Test DisciplineFinding and documenting defects in softwareGenerally advising about the perceived software qualityProving the validity of the assumptions made in design and requirement specifications through concrete demonstrationVerifying the software product functions as designedValidating that the requirements have been implemented appropriatelyFocuses primarily on the evaluation or assessment of quality realized through a number of core practicesActs in many respects as a service provider to the other disciplines

Agile DevelopmentCustomer centered: www.agilemanifesto.orgExtreme Programming XPSCRUMHighly iterativeAdapts to requirements changesFocus on team communicationGood for small/skilled teamsPair programmingRefactoringTest driven developmentActive customer involvementMay not scale for large projects*Software Project Management


Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Kent Becks assumptionsIf code reviews are good, we'll review code all the time (pair programming).If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).If design is good, we'll make it part of everybody's daily business (refactoring).If simplicity is good, we'll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work).If architecture is important, everybody will work defining and refining the architecture all the time (metaphor). If integration testing is important, then we'll integrate and test several times a day (continuous integration).If short iterations are good, we'll make the iterations really, really shortseconds and minutes and hours, not weeks and months and years (the Planning Game).Software Project Management*


XP Promises(Beck)To programmers:They will be able to work on things that really matter, every day.They won't have to face scary situations alone. They will be able to do everything in their power to make their system successful. They will make decisions that they can make best, and they won't make decisions they aren't best qualified to make.To customers and managers:They will get the most possible value out of every programming week. Every few weeks they will be able to see concrete progress on goals they care about. They will be able to change the direction of the project in the middle of development without incurring exorbitant costs.In short, XP:reduce project risk,improve responsiveness to business changes,improve productivity throughout the life of a system, add fun to building software in teamsSoftware Project Management*


XP phasesArchitectural Spike, where a prototype is created to validate the primary concerns of an iteration: reduces riskRelease planning phase, where the customer writes stories, the programmers estimate them, and the customer chooses the order in which stories will be developed;Iteration phase, where the customer writes tests and answers questions, while the programmers program. Versions are generated at few weeks.Release phase, where the Programmers install the software, and the Customer (hopefully) accepts the result.Software Project Management*


XPhttp://www.extremeprogramming.org/map/project.html*Software Project Management


XP IterationsSoftware Project Management*J. Shore, S. Warden: The Art Of Agile Development


XP testingTest early. This principle states that you must not wait with testing until the entire system is assembled. Instead, run test cases as soon as a unit is implemented, and assemble your system out of carefully tested units.Test first. Write test cases before implementing the unit. This is useful because test cases can serve as specifications. Any program feature without an automated test simply doesn't exist.(K. Beck)Test often. At the minimum, run your tests with each release of the system. Better yet, run your tests with every change.Have others test. Always have someone independent test your program, and be open to criticismMostly perform Unit tests and Acceptance testingAgile vs RUP: http://www.agiledata.org/essays/rup.html

SCRUMSCRUM: eight players rugby team with different roles acting together for a specific goalAgile methodologyIteration based: 1-4 weeks iterations (Sprints)Small teams: 7-9 peopleSCRUM: practices and roleshttp://www.infoq.com/minibooks/scrum-xp-from-the-trenchesSoftware Project Management*


http://scrumtraininginstitute.com/home/stream_download/scrumprimerSoftware Project Management*


SCRUM RolesProduct Owner: business representativeidentifying product featurestranslating these into a prioritized listdeciding which should be at the top of the list for the next Sprintcontinually re-prioritizing and refining the list.Team: programmers, architects, testers, etcbuilds the product that the Product Owner indicatescross-functional it includes all the expertise necessary to deliver the potentially shippable product each Sprintself-organizing with a very high degree of autonomy and accountabilityScrum Masterhelps the product group learn and apply Scrum to achieve business valuehelp the Team and Product Owner be successfulcannot be the same with the product ownerhe/she is not the leader of the team The Scrum Master is NOT the project manager!Software Project Management*


Product backlogProduct vision: product owner building the product backlog customer features but also technical tasksuser stories or use casescontinuously updated by the Product Owneritems having a business value estimate helping maximizing the ROIRelease Backlog: the subset of the Product Backlog that is intended for the current release

Software Project Management*


Sprint backlogCreating the current sprint plan from the product backlogSprint planning meeting part one: Product Owner the Team and the Scrum MasterFocuses on what are the PO prioritiesProvides the team with insight about the goal and the context of the sprintEstablishes what a done item mean (e.g. coded to standards, reviewed, implemented with unit test-driven development (TDD), tested with 100 percent test automation, integrated, and documented)Sprint planning meeting part two: the Teamfocuses on detailed task planning for how to implement the items that the Team decides to take onthe Team selects the items from the Product Backlog they commit to complete by the end of the Sprint, starting at the top of the Product BacklogIt is updated every day with the remaining time for each taskSprint Burndown chart: estimate of how much work (measured in person hours) remains until the Teams tasks are finished. It is a downward sloping graph that is on a trajectory to reach zero effort remaining by the last day of the SprintSoftware Project Management*


Daily ScrumShort (15 minutes or less) meeting that happens every workday at an appointed time. Everyone on the Team attends. To keep it brief, it is recommended that everyone remain standing. It is the Teams opportunity to synchronize their work and report to each other on obstacles. No management involved.Each member of the Team reports three (and only three) things to the other members of the Team: what they were able to get done since the last meeting; what they are planning to finish by the next meeting;any blocks or impediments that are in their way.Software Project Management*


Sprint reviewAfter the Sprint ends;The Team and the Product Owner review the Sprint;An inspect and adapt activity for the product;Product Owner learns what is going on with the product and with the Team;The Team learns what is going on with the Product Owner and the market;Attended by: Product Owner, Team members, and Scrum Master, plus customers, stakeholders, experts, executives, and anyone else interested.Software Project Management*


Sprint retrospectiveInspect and adapt regarding the process. Its the main mechanism for taking the visibility that Scrum provides into areas of potential improvement, and turning it into results.Its an opportunity for the Team to discuss whats working and whats not working, and agree on changes to try. The Team and Scrum Master will attend, and the Product Owner is welcome but not required to attend.Software Project Management*


Release sprintFinal sprint to complete the releaseIntegrate some elements, polish, etcSign of some development weakness as ideally at the end of each sprint the product should be good enough for use

Software Project Management*


Testing Tasks in the Software Development Life CycleSoftware Project Management*


Common system typesSource: McConnel, Code CompleteSoftware Project Management*

Business SystemsMission-Critical SystemsEmbedded Life-Critical SystemsInternet siteEmbedded softwareAvionics SoftwareIntranet siteGamesEmbedded softwareInventory managementInternet siteMedical devicesGamesPackaged softwareOperating SystemsManagement Information SystemsSoftware toolsPackaged softwarePayroll systemsWeb services


Life cycle modelSoftware Project Management*

Business SystemsMission-Critical SystemsEmbedded Life-Critical SystemsAgile development (Extreme Programming, Scrum, timebox development, and so on)Staged deliveryStaged deliverySpiral developmentEvolutionary deliveryEvolutionary prototypingEvolutionary delivery

Spiral development


Project planning and managementSoftware Project Management*

Business SystemsMission-Critical SystemsEmbedded Life-Critical SystemsIncremental project planningBasic up-front planningExtensive up-front planningAs-needed test and QA planningBasic test planningExtensive test planningInformal change controlAs-needed QA planningExtensive QA planningFormal change controlRigorous change control


Requirements and designSoftware Project Management*

Business SystemsMission-Critical SystemsEmbedded Life-Critical SystemsInformal requirements specificationSemiformal requirements specificationFormal requirements specificationAs-needed requirements reviewsFormal requirements inspectionsDesign and coding are combinedArchitectural designArchitectural designInformal detailed designFormal architecture inspectionsAs-needed design reviewsFormal detailed designFormal detailed design inspections


*Coding, Testing and Deployment*Software Project Management*

Business SystemsMission-Critical SystemsEmbedded Life-Critical SystemsPair programming or individual codingPair programming or individual codingPair programming or individual codingInformal check-in procedure or no check-in procedureInformal check-in procedureFormal check-in procedureAs-needed code reviewsFormal code inspectionsDevelopers test their own codeDevelopers test their own codeDevelopers test their own codeTest-first developmentTest-first developmentTest-first developmentLittle or no testing by a separate test groupSeparate testing groupSeparate testing groupSeparate QA group

Informal deployment procedureFormal deployment procedureFormal deployment procedure


*******************************PRJ270v2/pag 4-50PRJ270v2/pag 1-36

*Extreme Programming Scrum Adaptive SoftwareDevelopment (ASD) Crystal Clear Dynamic SystemsDevelopment Method(DSDM) Feature Driven Development(FDD) Lean software development Microsoft SolutionFramework (MSF) Agile Unified Process (AUP)

***********************

EngineeringProcess.pps

Documents

Transcript of EngineeringProcess.pps