No test levels needed in agile software development! · About agile -About agile ---Agile Manifesto...
18
1 No test levels needed in agile software development! No test levels needed in agile software development! No test levels needed in agile software development! No test levels needed in agile software development! Leo van der Aalst Lector Software Quality and Testing PNSQC, October 11h 2011 Portland Copies may not be made or distributed for c ommercial use Excerpt from PNSQC 2011 PNSQC.ORG ____________ __________ ____________ __________ ____________ __________ ____________ __________ ____________ ____ _
Transcript of No test levels needed in agile software development! · About agile -About agile ---Agile Manifesto...
1
No test levels needed in agile software development!No test levels needed in agile software development!No test levels needed in agile software development!No test levels needed in agile software development!
Leo van der AalstLector Software Quality and Testing
PNSQC, October 11h 2011
Portland
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
AgendaAgendaAgendaAgenda
• About agile
• Testing in agile software development
• No test levels needed
2
• No test levels needed
• Product risk analysis (one-table approach)
• Summary
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
About agile About agile About agile About agile ---- Some iterative methodsSome iterative methodsSome iterative methodsSome iterative methods
• Rapid Application Development (RAD)- 80’s, Barry Boehm, Scott Shultz and James Martin
• Scrum- 1986, Ikujiro Nonaka en Hirotaka Takeuchi
3
- 1986, Ikujiro Nonaka en Hirotaka Takeuchi
• Dynamic Systems Development Method (DSDM)- 1995, DSDM Consortium
• eXtreme Programming (XP)- 1996, Kent Beck, Ken Auer, Ward Cunningham, a.o.
• Feature Driven Development (FDD)- 1997, Jeff de Luca
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
About agile About agile About agile About agile ---- Agile Manifesto (2001)Agile Manifesto (2001)Agile Manifesto (2001)Agile Manifesto (2001)
• Individuals and interactions over processes and
tools
• Working software over comprehensive
4
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
While there is value in the items on the right, the items on the left are valued more!
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Vision on testing in agile environmentsVision on testing in agile environmentsVision on testing in agile environmentsVision on testing in agile environments
• Manifesto is starting point
• Integrated test process
- testing activities must be integrated in both the
development process itself and in the team
5
testing activities must be integrated in both the
development process itself and in the team
- testing should move the project forward
- testing tools are increasingly important
- testing is part of (definition of) done
• Find balance by making well-considered choices
• (Re)use values of proven test approachesCopies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Put the test vision into practice by:Put the test vision into practice by:Put the test vision into practice by:Put the test vision into practice by:
• Seeing testing as the driver of the project
• Integrating testing in the entire process
• Start testing from the beginning of the project
6
• Start testing from the beginning of the project
• Integrating testing in the team
• Giving testing a role in the requirements elicitation
• Making it possible to test with a limited test basis
• Seeing testing as a part of "done"
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
First things to do (being a tester)First things to do (being a tester)First things to do (being a tester)First things to do (being a tester)
• Make sure you understand the business
(domain knowledge)
• Involve yourself in unit testing
7
• Involve yourself in unit testing
• Assist other team members in non-testing
activities
• Communicate about what is not documented
• Design test cases so they can be automated
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
No test levels needed No test levels needed No test levels needed No test levels needed ---- CharacteristicsCharacteristicsCharacteristicsCharacteristics
• No separate testlevels like system test or
(user/production) acceptance test
• All team members work together
8
• All team members work together
• All disciplines work together, support eachother
• No designer, developer, user or test teams
• No test levels/teams with their own budget
• Team members accept the feature with their own
acceptance criteria in mindCopies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
No test levels needed No test levels needed No test levels needed No test levels needed ---- TraditionallyTraditionallyTraditionallyTraditionally
wish, legislation, policy, opportunity, problem
operation & management
9
development
acceptance
systemSupplying partySupplying partySupplying partySupplying party
Accepting partyAccepting partyAccepting partyAccepting party
functionaldesign
realisation
technicaldesign
requirements
UT, UT, UT, UT,
UITUITUITUIT
STSTSTST
SITSITSITSIT, FAT, , FAT, , FAT, , FAT,
UAT, PATUAT, PATUAT, PATUAT, PAT
tests
tests
tests
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
wish, legislation, policy, opportunity, problem
operation & management
No test levels needed No test levels needed No test levels needed No test levels needed –––– IntermediateIntermediateIntermediateIntermediate
10
user stories
requirements
features
time-boxedtest/development
acceptance functionality
suitability
user-friendliness
performance
security
continuity
manageability
reusability
maintainability
etc.
system
development
tests
tests
tests
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
wish, legislation, policy, opportunity, problem
operation & management
No test levels needed No test levels needed No test levels needed No test levels needed –––– Agile wayAgile wayAgile wayAgile way
11
user stories
requirements
features
time-boxedtest/development
tests
functionality
suitability
user-friendliness
performance
security
continuity
manageability
reusability
maintainability
etc.
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Product risk analysis Product risk analysis Product risk analysis Product risk analysis –––– StakeholdersStakeholdersStakeholdersStakeholders
UserUserUserUser
StoryStoryStoryStory
CharacteristicCharacteristicCharacteristicCharacteristic StakeholderStakeholderStakeholderStakeholder
US 1Functionality Person A
User-friendliness Person B
12
User-friendliness Person B
US 2Functionality Person A
Security Person C
US 3 Functionality Person A
US 4 Performance Person C
US 5 Performance Person C
US 6Functionality Person A
Suitability Person B
.. ..
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Product risk analysis Product risk analysis Product risk analysis Product risk analysis –––– Risk tableRisk tableRisk tableRisk table
UserUserUserUser
StoryStoryStoryStory
CharacteristicCharacteristicCharacteristicCharacteristic StakeholderStakeholderStakeholderStakeholder DamageDamageDamageDamage ChanceChanceChanceChance
ofofofof
FailureFailureFailureFailure
RiskRiskRiskRisk
ClassClassClassClass
US 1Functionality Person A 3 3 9
User-friendliness Person B 2 1 2
13
User-friendliness Person B 2 1 2
US 2Functionality Person A 2 2 4
Security Person C 3 2 6
US 3 Functionality Person A 2 1 2
US 4 Performance Person C 2 1 2
US 5 Performance Person C 1 1 1
US 6Functionality Person A 2 2 4
Suitability Person B 2 2 4
.. .. .. .. ..
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Product risk analysis Product risk analysis Product risk analysis Product risk analysis –––– Strategy tableStrategy tableStrategy tableStrategy table
UserUserUserUser
StoryStoryStoryStory
CharacteristicCharacteristicCharacteristicCharacteristic StakeholderStakeholderStakeholderStakeholder DamageDamageDamageDamage ChanceChanceChanceChance
ofofofof
FailureFailureFailureFailure
RiskRiskRiskRisk
ClassClassClassClass
IntensityIntensityIntensityIntensity TestTestTestTest
DesignDesignDesignDesign
TechniqueTechniqueTechniqueTechnique
US 1Functionality Person A 3 3 9 ●●● ECT-MCC
User-friendliness Person B 2 1 2 ● SYN
14
User-friendliness Person B 2 1 2 SYN
US 2Functionality Person A 2 2 4 ●● ECT-MCDC
Security Person C 3 2 6 ●● SEM-MCDC
US 3 Functionality Person A 2 1 2 ● DCoT-EQ
US 4 Performance Person C 2 1 2 ● EG
US 5 Performance Person C 1 1 1 ● EG
US 6Functionality Person A 2 2 4 ●● ECT-MCDC
Suitability Person B 2 2 4 ●● PCT-TDL2
.. .. .. .. ..
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Product risk analysis Product risk analysis Product risk analysis Product risk analysis –––– Progress tableProgress tableProgress tableProgress table
UserUserUserUser
StoryStoryStoryStory
CharacteristicCharacteristicCharacteristicCharacteristic SSSS
HHHH
DDDD CCCC
oooo
FFFF
RRRR
CCCC
IntensityIntensityIntensityIntensity TestTestTestTest
DesignDesignDesignDesign
TechniqueTechniqueTechniqueTechnique
Test CasesTest CasesTest CasesTest Cases
createdcreatedcreatedcreated
(Y/N)(Y/N)(Y/N)(Y/N)
Test CasesTest CasesTest CasesTest Cases
executedexecutedexecutedexecuted
(Y/N)(Y/N)(Y/N)(Y/N)
Tests PassedTests PassedTests PassedTests Passed
(Y/N)(Y/N)(Y/N)(Y/N)
US 1Functionality A 3 3 9 ●●● ECT-MCC
User-friendliness B 2 1 2 ● SYN
15
User-friendliness B 2 1 2 SYN
US 2Functionality A 2 2 4 ●● ECT-MCDC
Security C 3 2 6 ●● SEM-MCDC
US 3 Functionality A 2 1 2 ● DCoT-EQ
US 4 Performance C 2 1 2 ● EG
US 5 Performance C 1 1 1 ● EG
US 6Functionality A 2 2 4 ●● ECT-MCDC
Suitability B 2 2 4 ●● PCT-TDL2
.. .. .. .. ..
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
SummarySummarySummarySummary
• No separate test levels
• All acceptors present in relevant iterations
- prepare/execute their own tests (with/without help)
16
- prepare/execute their own tests (with/without help)
• Risk determined per feature/qc by and per acceptor
• Test strategy determined per feature/qc
- test intensity / test design techniques
• Just one table on white board
• Product is explicitely accepted by all acceptors
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Thank you for your attention!Thank you for your attention!Thank you for your attention!Thank you for your attention!
Questions?Questions?Questions?Questions?
17
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
Contact informationContact informationContact informationContact information
• EmailEmailEmailEmail
- [email protected]@[email protected]@fontys.nl
- [email protected]@[email protected]@leovanderaalst.nl
• PhonePhonePhonePhone
18
• PhonePhonePhonePhone
- +31 (0)6 2277 8105+31 (0)6 2277 8105+31 (0)6 2277 8105+31 (0)6 2277 8105
• InternetInternetInternetInternet
- www.fontys.nl/lectorenwww.fontys.nl/lectorenwww.fontys.nl/lectorenwww.fontys.nl/lectoren
- www.leovanderaalst.nl/home_eng.htmwww.leovanderaalst.nl/home_eng.htmwww.leovanderaalst.nl/home_eng.htmwww.leovanderaalst.nl/home_eng.htm
Copies may not be made or distributed for commercial use Excerpt from PNSQC 2011 PNSQC.ORG_________________________________________________________________________________________________________
![A systematic literature review of the agile methodology ...ieomsociety.org/southafrica2018/papers/68.pdf · The agile manifesto [12], designed in 2001, is rooted in a value statement](https://static.fdocuments.in/doc/165x107/602398ef822961700274d5ee/a-systematic-literature-review-of-the-agile-methodology-the-agile-manifesto.jpg)
![Manifesto for Agilefiles.meetup.com/11341602/201309_P1_Agile_Groupies... · From wikipedia- Agile Manifesto In February 2001, 17 software developers[6] met at theSnowbird, Utah, resort,](https://static.fdocuments.in/doc/165x107/5f4d3476347c3c040e06c1c2/manifesto-for-from-wikipedia-agile-manifesto-in-february-2001-17-software-developers6.jpg)
