Definition of an Agile Offshore Approach Agile Testing

The details of our agile offshore approach were as follows:

  • Staff
  • The U.K. team included one project manager, two developers, one test manager, and one test analyst/tester.
  • The Indian team included one team leader and five developers.
  • The U.S. team included one marketing manager.
  • Agile requirements
  • Use cases– Where new requirements were needed(this was, after all, mostly a migration-style project), they were elicited using a use case–based approach. The majority of new requirements were obtained from our U.S. marketing manager and involved some intensive transatlantic teleconferences(where, oddly, we still suffered from language issues – more on this later).
  • Requirements documentation– Requirements were documented using a commercial product. This product included a web-based interface that allowed our Indian and U.S. colleagues to be able to review, comment on, and make use of the requirements. In practice, this was a very successful aspect of the project, and as long as we phrased the requirements in a concise, clear, and unambiguous manner,1 the results(i.e., the code implemented against the requirements)were good.
  • Iterative approach
  • Two-week iteration period – We employed a two-week iteration period. We had previously seen projects where iterations based around a week-long period had been successful(more on this later) but the work items were too large on this project; hence, our use of a two-week period. (Interestingly, we believe a week-long iteration might have been possible had we not had the additional communication overhead of offshoring the project.)
  • Time boxing– The two-week iterations were time-boxed. Where rapidly approaching time-box deadlines meant that not all the requirements for that iteration could be implemented, the decisions on what requirements would be left out were based on priority values assigned to the requirements in the requirements management tool. (Risk and priority were in effect attributes associated with any particular requirement). It was also possible to include information describing relationships between requirements in the tool, such as dependencies;this allowed the U.K. project manager to assess the impact of proposals from the developers about omitting specific requirements.
  • Agile meetings
  • GeneralWherever possible, all meetings would include the whole team (typically Indian and U.K. staff, with occasional attendance by the U.S.-based marketing manager). Because of the communications challenges of offshoring, meetings were considered to be an essential aspect of making the project successful, and great importance was placed on holding and attending them. To avoid too many meetings and not enough work, all meetings were as brief and focused as possible(following the principles of the agile project management method Scrum).
  • Initial project startup and planning meeting– This meeting was convened on the Friday before the project was to begin to kick off the project, to introduce the staff to each other, confirm roles and responsibilities, review and agree on tasks and timescales, agree on our offshore working protocol(such as the when and how of communications), and to plan and prepare for the first iteration(to begin on the following Monday).
  • Two-weekly Friday iteration startup meetings– These meetings were used to review the results of the previous iteration, to document any lessons learned, and to plan and prepare for the next iteration(which would begin on the following Monday morning). The meeting would involve a review of the requirements for the next iteration, their priority and any risks and/or dependencies, and agreement on the tasks and timescales. The test plan for the iteration would also be discussed and agreed.
  • Weekly conference call progress meetings – Held midweek on the Wednesday,these brief meetings were really just to confirm that all members of the team were on track and that there were no problems, risks, or dependencies that might cause the team to fail to meet its deadlines.
  • Local daily stand-up meetings– We also ran daily fifteen-minute stand-up meetings2 first thing each day with the U.K. team for the purposes of reviewing what the team had achieved the previous day, what it planned to do today, and what issues, risks, or dependencies might disrupt its plans. We asked the Indian team to follow this approach as well.
  • Project closedown meeting– At the end of the project we scheduled a large videoconference meeting that included all the stakeholders from the project (which was planned to coincide with the U.K. presence of our marketing manager) to formally close the project, review the deliverables, ensure all artifacts were filed, and to review and document all of the lessons learned during the project(many of which were rolled up from lessons documented in previous meetings). This was a very valuable event both from a process improvement and project administration perspective, but also from a human perspective. By then, our resident offshored resource had returned to India, and it gave all the team members on both continents the chance to thank each other and to say goodbye–quite an emotional moment, as it turned out.
  • Agile development approach
  • General – Since we were developing using Java and Eclipse, we largely followed the agile Eclipse Way development process.
  • Pair programming– We employed an agile development approach using pair programming(as per Extreme Programming).
  • Continuous integration– The developers used a continuous integration(and test)approach. This would continue daily at a local level, with a weekly (on Thursday close of business) email consolidated build and test in the United Kingdom. In practice, this did cause some quality issues.
  • Test-driven development – Developers were expected to review the requirements and design their tests before coding began.
  • Automated unit testing– Developer testing was automated using the popular JUnit tool.
  • Agile software quality management
  • Test management and planning were based around the iteration plan, with functional tests planned at the end of each iteration(plus rerun regression tests from previous iterations– ee later bullet point). Unit testing(and evidence of unit testing) was provided by the developers as they coded. A key goal was for testing to begin as early as possible and continue frequently throughout the project.
  • Test coverage was achieved by ensuring that each requirement had one or more test cases associated with it and that each test case had one or more test scripts associated with it. This was a very straightforward process using the requirements management tool selected for the project, and it was possible to produce extremely useful test design, implementation, and coverage reports as and when needed.
  • Unit testing was very successfully achieved using the JUnit tool.
  • Acceptance testing– Use cases were also employed by the test analyst to generate acceptance testing scenarios, which was found to be a very natural and straightforward solution to producing realistic and effective acceptance tests.
  • Regression testing was achieved using a Java-based capture– replay tool, allowing us to automate the acceptance tests in the form of Java scripts, which we were then able to replay against new builds and releases of the product.
  • Pair testingwas a technique we developed to be a software quality equivalent of the pair programming techniques the developers were using. Our test manager and test analyst worked together to design and implement the tests needed to verify functionality, which were subsequently recorded by the capture–replay tool(to be reused against later builds and releases).
  • Test automation– As described earlier, JUnit and a capture–replay tool were used to automate the testing process wherever appropriate. In the case of the capture–replay tool, we also used it to set up, initialize, and manage the complete regression testing activity.

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

Agile Testing Topics