Migration from Waterfall model to Agile model - QAI

Migration from Waterfallmodel to Agile modelByVipul KumarFiserv India Pvt. Ltd.5 th floor Plot No. 6Tech BoulevardSector 127NoidaUttar Pradesh

Abstract General Impacts and Changes Impact on QA and Testing QA process in Agile Testing and QA practises in Agile Developmentagainst Waterfall model Closing Statement Refrenceses

AbstractWaterfall methodology has been there for years now and is identifiedfor being the most classic and proven methodology for simpleprojects. This is probably best suited for shorter duration projectwhere vision and directions are clearly defined.But over the time, since projects have become more and more complexand demands more support and meeting the changes andchallenges of business such as financial market and banking whereregulations of government and demands of customers, forces IT tomeet their changes and deliver it quickly. Here comes the conceptof Agile, a methodology that accentuates more on ethics and valuesrather than processes.Switching to Agile may be caused due to many reasons, may be yourmanagement is all of sudden falling in love with Agile, or may be itsmandate for your project to meet customer expectations or deliverquickly for meet changing business needs. Whatever is the case,either way, you, as a team member; need to learn the new ways ofworking, learn agile and most importantly need to know how totransit from waterfall to agile and what are the things team need toremember and keep in consideration? Here we are going to discussall these concerns.

In the first part we will take a look on general impacts of this transitionand later on we will see detailed impact on QA and Testing when yourproject moves from Waterfall to Agile methodology.General Impacts and ChangesThe shift from waterfall to agile will have following impacts and changes inwork culture:Releases and delivery are more frequentIncreased variety of workEstimating your work at your ownImpact on quality assurance-Quick and immediateMore leaders and module leadsReduced documentation efforts and more communication/meetingsMore hit and trial methodsPriority driven workTeamwork becomes more crucialTerminology changes

1. Releases and delivery are more frequent:Production releases become more frequent, near daily, not like inwaterfall where release comes at the end of the road. These releasesbecome the part of daily life and surely team gets comfortable with itlike other happenings of the daily life.2. Increased variety of work:At the time of inspection the work and sprints are planned for next 2-3weeks. The focus is always on delivery and this creates opportunity forteam members to work in different roles. A tester who has theknowledge of entire in and outs of project may have to play the role ofbusiness analyst.

3. Estimating your work at your own:Team members are supposed to do estimation of their work on theirown for a sprint. Honesty and intelligence of estimation are blood andbone of overall planning and if a member over estimates or underestimates his work, not just overall planning will impact but also hisability are viewed poorly by team.4. Impact on quality assurance-Quick andimmediate:Quality assurance and testing usually requires a different environment thandevelopment and requires migration of code. However as very less codegoes to production each time, regression testing becomes crucial.Prioritization of test cases and requirements is key of a successfulregression (or any type of testing) in agile. Many times exploratory will bethe best way to discover the defects. QA will require working harder than inother methodologies, to keep up with development and also maintainingtheir traditional approaches. QA is tightly-coupled to development becausethe size of the change package can be medium to small but the frequencyof deployment is very often

5. More leaders and module leads:The dynamic nature and work environment create opportunity formultiple leaders and modules leads. Distribution of responsibility androles creates space for new leading areas like project owner and scrummaster.6. Reduced documentation efforts and morecommunication/meetings:Unlike other long-established models of development, agile includesless documentation. The client is online and mostly verbalcommunications and mails are used for further progress.

7. More hit and trial methods:Quick releases quicker fixing is the core of agile deliveries. Faster youwork, better ways you need to find to get the job done. To find thebetter ways hit and trial is the key.8. Priority driven work:when team got to work faster and frequent releases are done onproduction, prioritization becomes the driving force to it. Based onbusiness criticality and needs, requirements in each sprint are to beprioritized and delivered. It doesn’t go like in Waterfall where you followa straight line of development mostly.

9. Teamwork becomes more crucial:since entire team is tagged common: team member; seniors resourcesneed to work mixing with junior resources and the performance thebased more on delivery than seniority. There will be usually more “WEWE WE” in a successful agile implementation, rather than “ME MEME”. And this will be the key of success in agile methodology.10. Terminology changes:team become aware of new terminology. Sprints, Scrum, Online clientare few examples of those which we don’t find in waterfall model

These are few other points that team must rememberalong with above mentioned points:Agile is not a way to reduce documentations. Agile has its owndocumentation concepts and works primarily on oral communicationand commitments. This is the place where ethics and values playtheir roles.It does not to encourage unnecessary changes but to tackle therequired changes, effectively.Agile does not says to put planning aside. Planning is a crucial partof it but the way we plan in Agile differs and based on prioritiesrather than a straight line of development.The last and most important thing to remember is Agile is not foreveryone and Waterfall either is not suitable for every project. Teamand management need to be very careful while picking up themethodology that most suits to their requirement.

Impact on QA and TestingQA process in Agile:A very short definition of Agile testing is a testing that follows thefundamentals of Agile Software Development.The process of Agile testing is not very different from traditionaltesting involved in Waterfall model but it’s a speedy and veryflexible way of testing to meet the changing requirements and rapiddevelopment of software. The typical process is as follows:

Business requirements are created by customer and business analysisgroup, development group and testing group review it. Involvement oftesting group is a mandate here so that they can plan their strategy fortesting the requirements. Further during design phase user stories arecreated and reviewed by client and accordingly requirements arechanged and altered. Testing team follows up all these changes until aconsolidated document of requirements is prepared and reviewedfinally. This will ensure that all the parties are on the same page. Therewill be lots of changes in the requirement and test team need to beflexible enough to make sure that these changes are addressed in theirtest strategies and planning.

Just like in waterfall, while development team is busy in coding, testingteam will create its test plan, test cases and other testing artefacts.Customer reviews all these documents and gives thump up! This willensure the test coverage and also helps to find out ambiguity in testplan if any.Once code is delivered for testing, a quick smoke test is done just likein Waterfall model but the core of smoke test here is not to make sure ifapplication is ready to test but to report show stoppers and criticaldefects first hand so that it development team can work them out and itcan save valuable time during project life cycle. As we already knowhow close testing and development groups work together, smoke testbecomes one of the most crucial point of testing.

One the application is under test after bugs fixed in smoke test,different type of testing, similar to waterfall model are applied. Thesetypically are Functional testing, integration testing, and system testingetc. Here regression testing becomes much more crucial. Every nowand then you have code change. Each time code is changedregression is done. Apart from your scripted test cases, exploratorytesting is the most used and best utilized in agile testing environment.

Testing and QA practises in AgileDevelopment against Waterfall modelWhatever we have discussed above are generic changes andchallenges apart from technical issues that entire team will have to dealwith. But there are certain QA related precautions and challenges alsothat QA team need to take care.QA team need to be careful and understand that developersmostly in Agile are not just technically sound in their work but also mayhave good understanding of automation scripts (remember the point“Increased variety of work”). So QA must remember developmentalso has good understanding of not just product (vs. their specificmodule) but also good knowledge of testing. Dev team must bepracticing Test Driven Development or may be Behaviour Drivendevelopment.

In this case just finding the bugs isn’t going to do wonders. You,as a QA guy need to provide some value adds. Here are sometips:Provide a different outlook of the project. From development side,it’s too obvious for them to get so much engrossed in coding thatthey miss to see application from end user’s eyes. As a QA yourvalue add will not be just a bug, but bringing up those points and outof box scenarios that a typical user will follow.Be in constant touch with development and client. Most of the timesyou may find several defects with have same root cause and youstat logging dozen of defects and at the end of the day, afterspending hours on all defects separately development team figureout a common root cause. In such scenarios best will be just be intouch with developer, let them know what all you are finding andraise a single bug for multiple related defects.

Do a great job to isolate the bugs. You see this is a rapiddevelopment and quick to quicker deliveries to customer,development cannot spend too much time in finding out the path torecreate an issue testing team reported. In Waterfall model you mayrepost exactly what you see and the same path to recreate a bugwhat you followed (however it is advisable there also bug should beas clear as possible) because we have some timelines and straightto go path in front of us. But in agile we have too little time mostly inhands and too much to do in that time that developers cannotspends hours to know how to recreate the bug. Just spend littleextra time to figure out the simplest way of reproducing the bugrather than jumping at your seat and filling the defect logimmediatelyTest team should always be ready to welcome changes even late intesting. Whereas in waterfall, you would find these kind of latechanges very rare and they are mostly treated as Change Requestsand are developed and tested in a separate go, in Agile there arealways chances of changed requirements that will drive a change incode and hence a change in testing.

Closing StatementAt testing strategy side, exploratory testing is heart and soul in agilemethod. If you have been working in waterfall model for long, you musthave dealt with long scripts designing and running those scripts whiletesting.One reason this approach is not appropriate for agile projects is therequired lead time to do it well. It's not unusual for an agile project tohave sprints of two to four weeks, and test cases aren't writtenovernight. Exploratory testing is more lightweight and quick way tokeep up with constantly changing requirements and codes and thefrequency of delivery involved in agile. Prioritize your testing forregression, keep explanatory as heart and soul of your strategy andagile will be really fun for you.

Referenceshttp://en.wikipedia.org/wiki/Agile_testinghttp://www.pettichord.com/http://www.softwaretestingtimes.comhttp://www.exforsys.com/tutorials/testing/testing-for-agile-softwaredevelopment.html