Sven Rosvall - Extreme Programming - SoftTest Ireland


Published on

Visit SoftTest Ireland and sign up for access to free Irish Software Testing events.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sven Rosvall - Extreme Programming - SoftTest Ireland

  1. 1. Extreme Programming Sven Rosvall sven-e@lysator.liu.seExtreme Programming (XP) is a rebellious new development methodology that hasgot a lot of press recently. But is it so "extreme" as the name indicates? And whatmakes it so "extreme"?This talk aims at giving a quick introduction to XP and what is so special. XP has astrong focus on human communication, simplicity and testing. There are lots ofwork for testers in an XP environment. We will see how testing can drive the wholedevelopment process. Testers are now in charge instead of being given the endresult from developers during the hectic final stages of the project 1
  2. 2. Values of XP • Communication • Simplicity • Feedback • Courage•Communication between team members, management and customers.•Do the simplest thing that could possibly work. Don’t do anything more. Do onlywhat you need today. Tomorrows complexity will be dealt with tomorrow.•Feedback on the state of the system (testing). Feedback from customers. Feedbackon project progress.•Courage to do radical, needed changes.These values go hand in hand.•Communication spreads courage to the whole team.•It is easier to be courageous with a simple system.•Feedback gives courage because you know how the system performs. 2
  3. 3. Why is XP popular? Waterfall model doesn’t work: • Relies on getting specifications right • Customer changes his mind • New technology • Late system testing • Poor visibility of progress•It is impossible to get specifications right before you have a complete system.•Customers always change their mind. They might not know in advance what theyreally need. Competitors may have added features.•The world changes. New technology is introduced. Not only new tools andoperating systems our project is based on. There may be smaller upgrades withsubtle changes that may break or improve our system.•System Testing cannot start until we have a system. All pieces must be integrated.Customers can only get a feel for it is how to work with the system at this point.•Progress reports say. “Analysis Phase complete”. Customer says “Good, but whatdoes Analysis Phase really mean?” Think of the Emperors new clothes.A lot has changed since the Waterfall model first saw the light. Manymethodologies have improved things but not enough. 3
  4. 4. What is XP? • Customer focused • Iterative, frequent releases • Test intensive (Testing first) • Lightweight software development methodology•The customer pays us. Give him respect and keep him happy. Keep him informedon progress. Show early releases. Let customer participate in planning and design.•XP is the first truly iterative development methodology I have seen that does notcompromise quality. A system is delivered early and frequently to give visibilityinto progress and what is developed.•Testing is a crucial practice in XP. Automated as much as possible. •Test cases define what is to be developed and communicates functionality better than specifications to developers and to customers. It is easier to verify that a test case is satisfied than a requirement in a specification document. •Testing drives development. No development task is complete without passing its tests. •Testing assures that no code change breaks anything else. •Testing can start early because we have a system ready from the start.•XP is a lightweight methodology in that thick documentation is avoided andreplaced by other means. XP is ideal for 5-15 people in a project. Bigger projectscan often be broken down into manageable sub-projects. 4
  5. 5. When not to do XP • Company culture • Expensive integration/testing • Big projects • Uninterested Customer • Required up-front designXP requires communication. There may be “heroes” who want to be seen as indispensable experts andare afraid of sharing their knowledge.Some companies value their workers by how many hours they work, not what they do. There are alsomany managers who think meetings are waste of useful time and want people to work instead of talkingto each other.Integration and regression testing can be very expensive. Every developer won’t have access to his ownmainframe or moon-lander. But centralised builds on a dedicated test machine and testing with reportsmade available to all team members can often be an acceptable replacement. Simulators at various scalescan also do great jobs.If integration or regression testing takes too long, it takes too long to get feedback on recent changes.This can sometimes be solved by breaking down the system in manageable pieces that can be integratedand tested on their own. Regular large scale integration and testing will catch any problems at this levelreasonably fast.If Quality Assurance takes two months before releasing, this slows down the feedback loop badly.Instead QA should trust the automatic testing being performed.Big projects causes problems with communications. This can be solved by dividing the project intosmaller pieces. One group delivers a module to another, who act like customers.The customer may not be interested in giving feedback and prioritising the development. He may justwant something delivered and installed. You will have problems with this kind of customer in waterfallprojects too.There may exist a requirement for up-front design. Maybe because of tradition, maybe becausemanagement or customers want to see that the developers understand the problems in the project.There are still useful practices in XP that can be used in any project. 5
  6. 6. XP Practices Onsite Planning Customer Game Simple Design Metaphor Short 40h Releases Week Refactoring Testing Pair Coding Programming Continuous Standards Integration Collective Ownership•Customer on site to ask for clarifications, planning, testing, etc.•Everybody in the team uses the same Metaphor. (Mental Model)•Short Releases so that new features can be tested quickly. Typically every 2-4weeks.•Testing can start immediately because we have a (small) system after the firstrelease. (I.e. 2-4 weeks.)•Simple Design. Don’t do more than what is needed now. No need for up-frontcomplex design of things that might not ever be used. It is easier to change a simpledesign than a complex design when the customer may change his.•Refactoring is required when the Simple Design must be improved. We may havegained experience on how to design after having tested the feature with the simpledesign. The refactored design can be verified with the test suite, which has beenproven before.•Pair Programming. Two brains works much more efficiently than two individuals.They inspire and review each other all times. Tests are also designed in pairs.•Collective Ownership. Don’t rely on individual to help you out. Do all changes youneed for your feature yourself (in pairs) in any module.•Continuous Integration. Integrate your new feature and test it now.Testing is a development tool, even drives development. 6
  7. 7. XP Practices Onsite Planning Customer Game Simple Design Metaphor Short 40h Releases Week Refactoring Testing Pair Coding Programming Continuous Standards Integration Collective OwnershipAll practices work together:•We can plan short releases because the customer is with us defining what is needednow and the customer has seen a working system and agrees on the systemmetaphor.•Anyone on the team can add code to refactor or add a new feature because we havea common coding standard, simple design, work in pairs and have a test suite.•We can refactor with confidence because we have a test suite to verify that wehaven’t broken anything.•We can test frequently because we continually integrate small increments.•We stick to a simple design because we only need to implement what new testcases tell us to implement. 7
  8. 8. XP vs. Waterfall Activities Req. Analysis Impl. Integr. Review Test Delivery Customer X X X X X Planning X X X Metaphor X X X X X Simple X X Design Refactoring X X Cont. Int. X X X X Testing X X X X X X Short Rel. X X X Coll. Own. X X X Pair Prog. X X X Code Std X XThis table shows a cross-relation between XP and Waterfall models. It shows whichXP activities are supporting which Waterfall activities.We see here that all Waterfall activities are well covered, even though XP doesthem in a different way.Note that testing is an essential activity throughout XP. 8
  9. 9. User Stories • Describes One Feature • Communication between Customer and Developer • Basis for Planning • Basis for Test CasesUser Stories are very important in XP.•User stories replace system and function specifications.•When requirements are changed, this is reflected in a small number of user stories.•US are simple enough to be understood by customers and developers.•Each US is estimated and assigned to an iteration and a responsible developer.•Test cases are derived from US.US are organised on small cards so that they can be shuffled around duringplanning. Simpler than using project planning software such as Microsoft Project. 9
  10. 10. Iterations • Prioritisation of User Stories • Implement a set of User Stories • ReleaseAn iteration lasts typically 2-4 weeks. Customers and developers decide togetherwhich user stories are included in each iteration. Replanning at the beginning ofevery iteration.An iteration encompasses all activities of a project cycle. We can do this becausewe have a simple design and automated testing. We are integrating and testingcontinuously all the time so we know the system works. Packaging will also beautomated to speed up the iteration.Integration and testing is not listed separately on this slide as they are ongoingactivities. 10
  11. 11. Testing • Write tests before implementation • Test execution as soon as first feature implemented • All tests are re-run before accepting new features • Automating testsTest cases are written before development starts for a User Story to get as muchindependence of the test cases from knowledge of the design.Test cases are both at system level and at unit level.Tests are automated as much as possible as tests are executed very frequently. Theyare not only run at the end of each iteration before release, but also before eachimplemented feature is accepted as working and not breaking any other feature.Tests are used to drive development. They are the metric to say that the developerhas done his job. This metric is used by management to see progress.Developers are also helped by tests. They know clearly when their job is done. Nofuzz. There is no risk developers are stuck fine tuning code that fulfils no purpose asthere are no test cases for such work. The developer is confident that his new featuredoes not break anything as this is proven by testing. The developer feels happybecause he can see his achievements clearly.Customer is co-responsible for tests. Any bug reports coming in are seen as a failureto define a test case. There are no bugs (failed test cases) in XP projects, onlymissing test cases. 11
  12. 12. Testers Role • Better test writer than developers • Better test writer than customers • Knows test tools • Test automation • Test execution•Developers sometimes have difficulties distancing themselves from their systemand seeing things from a users perspective.•Customers sometimes don’t know all the error conditions that should beconsidered.•Test Tools that neither developers nor customers have resources to learn.•Automation is time consuming. Using Test Tools and frameworks.•Execute Manual Tests that cannot be automated.•Explorative testing etc to find any bugs/missing test cases and misunderstoodrequirements. 12
  13. 13. Example ProjectOnline banking is a service many of us know. It is a kind of application that evolvesover time. Perfect for dividing into iterations and release often to customers.The Metaphor here is a set of accounts that the user can work with. The pagednature of the web is also part of the metaphor.Need a “dummy customer” to act on behalf of all anonymous users.First iteration: Show this page. This page shows the features that has most value tothe customer. (Login is often seen as the first feature, but it has no real value.) Getfeedback on look and feel. Correct logo and colours, menu of commands logicallyordered. Easy to view information on screen.Early feedback may have suggested stripes in transaction list to make it easier tofollow lines.Testing against a snapshot database, because we don’t have database support yet.Note that this first iteration is not a publicly available release. We need a workingdatabase and login etc. to have a satisfactory solution. 13
  14. 14. Deploying XP in QA C++ QA C++, A static analysis tool for C++ source code. • Core analyser team 3-5 people. • Had been running for 2 years when XP was adopted. • Introduced XP during following 4 years. • 400 KLOC C++ code.The core analyser was easy to define tests for. Most test cases consisted of sourcecode that the tools should parse and expected warning messages.No dedicated tester. Instead a tiered automated test suite was built. The full suitewas run every night (8 hours). A limited set of the test suite had to be run beforecode was allowed to be checked in.The test suite consisted of:•1000 selected code samples to demonstrate new features.•800 code samples from bug reports.•A compiler test suite with 14 000 test cases was bought and integrated into testsuite.•A number of customer projects we managed to get our hands on.•The source code for QA C++ itself. 14
  15. 15. Lessons Learned from QA C++ - Too small team with very specialised roles made pair programming difficult. - Difficult to make management co-operate and find a customer. + Core parser was rewritten four times. + Never late production releases. - Slow feedback.Building a C++ parser is a daunting task. Adding analysis to this does not onlyrequire excellent understanding of the C++ language, but also understanding howthe tool is used and what needs customers have.Had done sporadic snapshot releases before. These were taking too much time assome files were missing in the release. Improved integration build scripts to be ableto deliver complete release frequently.Finding a customer was impossible. Customers were seeing QA C++ as just anothertool in their toolbox. No customer saw QA C++ as business critical tool. Later wehad a resource in the sales support team dedicated to QA C++ who acted as a proxycustomer. This was a huge improvement as this person knew very well what thecustomer wanted.A good test suite was already in place, but had to be improved to make it easy to runand view the results.Thanks to the automated test suite we dared to rewrite major parts of the tool whenthe design had to be enhanced to cope with new features. The test suite wascomprehensive enough to tell us if the new code was behaving as well as the oldcode did.We had an excellent track record on releasing on time, with very few bugs.Although we managed to send out a new release every month, the people on thebeta list were to busy to install new versions this often. Our japanese distributorwanted 6 months to make sure that the new version was as good as the previous,that all their customisations worked properly and to translate it. 15
  16. 16. Adopted Practices in QA C++ Onsite Planning Customer Game Simple Design Metaphor Short 40h Releases Week Refactoring Testing Pair Coding Programming Continuous Standards Integration Collective OwnershipWe did not have a customer to ask for details and priorities from the start. Insteadwe indicated to management what the next versions were going to include. Later wehad a resource in the sales support team dedicated to QA C++ who acted as a proxycustomer.We knew what to do, the C++ standard (700 pages) was our ultimate requirement.Easy to create user stories and test cases from this. However, customers requiredsupport for various compiler extensions.Planning suffered from lack of understanding what features were needed in themarket. We wanted to do a proper C++ parser but most customers were using VisualC++.Pair programming was difficult as the team was small and very specialised. No-onehad capacity to know more than one area in the tool. We did occasional pairprogramming to try it. This had always positive results. The resulting code hadoutstanding quality. But it was exhausting to get introduced into someone elsesproblem domain while maintaining your own.Coding style consistency suffered due to the lack of pair programming. We used ourown tool to enforce some coding guidelines. You can never cover everything in acoding standard.-----------------------------It was easy to introduce testing as a test suite was already in place.Everyone in the team thought XP was cool. 16
  17. 17. Agile Development • A collection of lightweight methodologies • Patterns for design and organisation – Agile Software Development Alistair Cockburn, ISBN 0-201-66969-9 –“Agile methods are people-oriented rather than process-oriented. They rely onpeople’s expertise, competency and direct collaboration rather than on rigorous,document-centric processes to produce high-quality software.”“Travel light. Just keep the models needed. The less models, the less to update.”XP is one of many agile methodologies. 17
  18. 18. Resources• Books: – Extreme Programming Explained: Embrace Change Kent Beck, ISBN 0-201-61641-6 – Test-Driven Development, By Example Kent Beck, ISBN 0-321-14653-0 – Testing Extreme Programming Lisa Crispin, ISBN 0-321-11355-1 18
  19. 19. Resources• Web links: – – – MIXED%29%2AR%28createdate%29%2AK%28simplesite%29%2AF% 28Lisa+Crispin%29%2A&sidx=6&sopp=10&ObjectId=5045&Function= DETAILBROWSE&ObjectType=MAGAZINE 19