200 likes | 347 Views
Software test I. ITU: Usability med projekt Brugercentreret design, for å r 2008 27.2.08 v/ Egil Boisen. Kursets sigte. Projektrapport (det I bliver eksamineret i) Brugercentreret design/ usability (baserer sig på hele specialiseringen, ikke kun ‘usability’ forstået som test-metoder)
E N D
Software test I ITU: Usability med projekt Brugercentreret design, forår 2008 27.2.08 v/ Egil Boisen
Kursets sigte • Projektrapport (det I bliver eksamineret i) • Brugercentreret design/ usability (baserer sig på hele specialiseringen, ikke kun ‘usability’ forstået som test-metoder) • Interaktive systemer • Problemorienteret tilgang • Speciale-forberedende • Akademisk refleksion; de gode grunde ift. applicering af redskaber; teori. • Fagspecifikt: • HCI som teoretisk baggrund • Fra klassisk UI-/ MMI-design til CHAT • Test-metoder ift. systemudviklingens faser • Bruger-behov: Observation, interviews/ fokusgrupper • Design: Målgruppeanalyse, konceptudvikling, review (Heuristisk evaluering), tests (tænke-højt tests på prototyper), • Test-begreber (software testing) • Arbejde med fund: validitet, reliabilitet, Grounded Theory
Pædagogiske overvejelser • Læringstrin • Metoder: hvad gør man • Forklaringer: hvorfor • Holdninger/ tilgange/ selvstændighed/ kritisk sans • Målstyret ift. projekternes/ jeres behov • Feedback + forandringer • Fokus på det akademiske • HCI • Personlig tilstedeværelse
Correct requirement Correct requirement Correct requirement Designed to meet req. Built to meet req. Product works as expected Designed to meet req. Mistakes in req. Designed to meet req. Built to meet design Wrong product Mistakes in design Built to meet design flaws Defects: bugs, flaws, wrong product Mistakes in build bugs
Correct requirement Correct requirement Correct requirement Designed to meet req. Built to meet req. Product works as expected Designed to meet req. Mistakes in req. Designed to meet req. Wrong product Built to meet design Mistakes in design Built to meet design flaws Three purposes of testing Validation Verification Reliability ~ bugs Mistakes in build bugs
Sources of failures: errors in.. • Specification • Forståelse/ beskrivelse af brugerbehov + brugerforudsætninger + praksis/ kontekst • Design • Utility + usability + user experience • Implementation • Bugs: syntax + logisk + semantisk niveau • Use of system • Manglende brugerkyndighed eller usability? • Environmental conditions • Intentional damage • Ibrugtagning og vedligehold
Defects ~ Error ~ Failure • Defect: bug in code • Error: human action • Failure: deviation of component/ system ~ expected delivery • Ikke alle defects fører til failures • Ikke alle failures skyldes defects
Correct requirement Correct requirement Correct requirement Designed to meet req. Built to meet req. Product works as expected Designed to meet req. Designed to meet req. Mistakes in req. Wrong product Built to meet design Mistakes in design Built to meet design flaws Testing objectives Validation Verification Reliability ~ bugs Mistakes in build • Sources of failures • ‘Kvalitet’ • Risk • Scope bugs
Kvalitets-dimensioner • Fitness for use • Tomaterne passer i opskriften • Attributes • Tomaterne har den rigtige størrelse/ farve/ smag • Manufacturing process (incl. testing) • Tomaterne er økologisk dyrkede • Value for money • Tomaterne er prisbillige/ holdbare • Feelings • Tomaterne har den rigtige ‘historie’ (?) • User expectations/ acceptance
Cost of finding defects Cost Req. Design Build Test Live use Time
Number of defects found Antal vs01 vs02 vs03 vs04 vs05 Releases
Cost of finding defects Cost Finding + fixing defects Prototype testing Review Req. Design Build Test Live use Time
preparation User req. System req. Global design Detailed design Implemen-tation component test Integration test System test acceptan-ce test operational system V-model & test levels User needs
Targets of testing • Functional testing (utility) • Suitability, accuracy, security.. • Non-functional testing (black box) • Reliability (robustness), usability, efficiency, maintainability, portability • Structural testing (white box) • Software arcitecture • Changes • Re-testing + regression tests • Maintenance testing
Test objectives: defects/ kvalitet • Finding defects • Men hvad er en defect? Hvad er kvalitet? • Fixing defects • Re-testing • Regression testing • Improving processes: • testing, requirements, design, development processes • Implementeringsstrategier? • Markedsføring?
Test activities: Basic steps • Planning and control • Objectives; scope + risk (=> exit criteria) • Test approach: hvad skal testes; hvem; hvornår; hvordan • Test resources + schedule • Analysis and design • Implementation and execution • Evaluating exit criteria and reporting/ Test closure activities
Software test ~ køreprøve • Static and dynamic tests • At føre en bil; i trafikken ~ i praksis og teoretisk. • Satisfy specified requirements • Færdselsregler, køreteknik, overblik. • Fit for purpose • Not focused on perfection • Planning and preparation • Vælge rute ift. requirements/ purpose • Evaluation • Antallet af fejl + grad af væsentlighed • Detect defects + afrapportere
Næste gang: Besøg hos DSB Rejsekort • DSB Rejsekort projektet • Kalvebod Brygge 32, d. 2/4 kl.9 – 11.30 • ..vi mødes kl. 8.45 ved indgangen/ trappen • Præsentation af testanlægget (Tune) • Oplæg: Test af processer og SW (Birgitte) • Eksempel på procestest • Testplan og testcase (demo) • Defect-skrivning • Litteratur: ISTQB, 2007: kap. 3 (minus 3.3) + kap. 4 (minus 4.3, 4.4) + kap.5 (minus 5.3, 5.4). • Indhold: Emnerne: ‘designing test cases’; ’use case testing’; test plans, estimates and strategies; risk; defect management. • Øvelse: Test case-skrivning. Tænke højt tests. Defect-rapportskrivning.
Øvelse: Heuristisk evaluering • I projektgrupperne; ift. eget projekt: • Opstil key usability goals (rangordne listen) • Opstil key user experience goals (3 – 5) • Diskuter og opstil 5 – 10 heuristikker
Øvelse: Påbegynd testplan • I arbejdsgrupperne, påbegynd arbejdet med testplan, med fokus på • Test objectives • Approach • herunder: • Hvilke redskaber ser I behov for? • Hvad er en ‘defect’ i jeres projekt? • Hvordan beskriver I ‘kvalitet’ og kvalitetssikring (f.eks. validation, verification, reliability osv.) • Hvor placerer jeres arbejde sig i software life cycle? • Angiv teoretiske inspirationskilder