Definition of the Agile Development and Testing Process Agile Testing

My agile process incorporated the following characteristics:

  • RUPesque–Having been exposed to the Rational
    Unified Process(RUP)at college, I employed a fundamentally RUP-like approach to the iterations(that I termed the RUPesque method). I also included elements of the V-model to enable me to convince my manager that I was doing some formal planning of the project. (It seems managers like to be reassured about these things.)
  • A small team (not co-located;see Section 20.5 for details of how I overcame the issues of lack of co-location) comprised
    1. the customer/user(basically the team I had been assigned to during my industrial placement),
    2. the project manager(my boss),
    3. the developer and tester(me),and
    4. ad hoc resources(a member of the team as and when needed for pair development and test–see later discussion).
  • Short iterations (matched to a week-long cycle to coincide with and to piggyback on an existing weekly team telephone conference call on Friday afternoon to allow the users[i.e., the team members]to review the previous week’s development and provide comments for the next week’s work).
  • Agile requirements –capture and maintenance(documented using an agile requirements tool).
  • Rapid prototyping –I relied heavily on a prototyping approach in which I would produce simple mock-ups(essentially just demonstrating the navigation and the basic features requested by the users)to show to the users in order to obtain their feedback on the suitability of the proposed system (formally during the Friday conference call, but also informally[but then documented in the requirement tool]via the SameTime instant messaging system[a facility available under Lotus Notes]).
  • Pair development To make particularly fast progress, I organized a number of intensive sessions where I worked with an experienced member of the team at the same workstation, bashing out code, and producing very good results .Pair development was particularly valuable where I had very challenging timescales and proved to be an excellent technique for very intensive development and testing and rapid delivery of good-quality software.
  • Pair testing – Again, working with my colleague, we identified suitable test scenarios, test data(including boundary and partition values), and employed statetransition techniques to design tests to verify correct navigation. I have broken this out separately from pair development, because I was so impressed by what turned out to be a particularly effective means of reducing defects.
  • Manual tester packs – I don’t subscribe to the popular notion that all students are lazy, fun-loving, hedonistic parasites(well, not completely). To avoid additional wasted testing effort, and to ensure I wasn’t stuck in the office after5 p.m. or(God forbid)testing on the weekend, I made sure that testing was as slick and efficient as possible. My main solution was to ensure I got maximum reuse from the tests that I(and my colleague, during pair testing) created. To this end:
    1. I created a simple test script template in the IBM Symphony word processor package and adopted a consistent script naming convention(a unique identifier formed from the iteration number, the Wiki page[and subpage], and an incremented number– e.g., 02-TeamOrgChart-01).
    2. To promote test reuse, I ensured that all test scripts that were developed were filed(both electronically as Symphony files and as paper-based copies in my test reuse folder, which was a file box with separate tabs into which the tests for separate iterations were stored).
    3. Regression testing was achieved by photocopying those tests that were required from earlier iterations and including them in the testing pack for the current iteration.
    4. I employed test refactoring to ensure the testing load did not grow to unmanageable volumes;the earlier tests were reviewed and omitted if it was felt that that aspect of the system being tested was now stable(in practice, that there had not been a defect observed since the last but one iteration).
    5. Acceptance testing did involve creating some new tests (by reviewing the requirements and identifying areas that needed additional test scenarios)but also involved the reuse of a random selection of manual test scripts from the previous iteration.
    6. In retrospect, in order to save even more of my valuable time and to reduce effort, I would have used automated testing tools if we had had budget and/or access to them. (Ironically, I discovered a day after the end of the project, we could have obtained a thirty-day temporary copy of Rational Functional Tester, which would have been very useful for recording and playing back web and Java tests overnight and/or over the weekend!)
  • Continuous integration and code refactoring – Although this may sound like a virtue, this was in fact a necessity. As I worked across the weekly iteration, I incorporated changes as and when they were received, and as and when I was able to make them, republishing them in the live system. In fact, as I describe later, this is one of the few areas I feel could be improved (again, perhaps by tool support), allowing me to rerun the test suite overnight following changes, or even over the weekend.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics