Wednesday

Part # 7 Points to watch out for when converting from waterfall to agile testing

Agile can be a challenge for the Test Analyst who has been trained and is accustomed to working in the traditional waterfall, Prince 2 environments or using the V model. A tester who finds themselves as part of “the team” using the agile scrum frame work can find that they are out of their comfort zone and may feel a little exposed. We recently held a meeting with a group of Test Analysts and asked them to identify what areas of our scrum implementation the needed to be improved and what areas they thought were going well. The key points identified are listed below.
Possible areas to Improve
50% said there were:
  • No proper test management processes.
  • Not enough sharing of information across the different groups (group = testers, product managers and developers).
  • No re-use of test scripts across the different on-line products using the same backend systems.
  • 25% said that:
  • Being left out of emails containing relevant information to the sprint.
  • Changing requirements half way through a sprint and not being clear on the actual change.
  • Test work not being prioritised enabling the tester to know what order to test tasks in.
  • Tester work is 1 to 2 sprints behind the development. (....Need to read the what done really means)
  • 100% stated that:
  • There was a lack of written requirements to test against, not enough detail in the requirements resulting in no real understanding on how a feature should work. Also a lack of forethought on features causes problems later on in th sprint.
  • No formal tracking of defects: only the tester is using the defect log and changing the status.

Areas that are going well:

  • 100% agreed that:
  • Definition of sprint cycle.
  • Sprint planning and pre-planning meetings.
  • Communicating daily with developers.
  • Good visibility as to what is coming up .
  • Agile process being well implemented- everyone understanding the business benefits of agile.
  • 75% agreed that:
    Close working with developers and business owners
  • Good use of the impediment log
  • Agile process being well implemented: everyone understanding the pros and cons of agile.
Tips for those new to the test agile role
If your thinking about joining a company, as a tester from a waterfall/Prince 2 background, that works in an agile way or your current company is planning to implement agile then I would recommend that you think about the following:
  1. Make sure that you attend the sprint planning meetings and wear your 'Business Analyst' hat – make sure you gather requirements that will enable you to write short test scripts and therefore test each backlog item and task. If need be arrange (with the Scrum Master and Product Owner) a follow-up meeting to clarify the requirements.

  2. Don’t be shy in raising impediments – it’s the Scrum Masters job to ensure that all impediments are removed so that “the team” can successful carry out their work. Impediments can include "I need more details on how this function should work."

  3. Review, on a regular basis, the product backlog and create and maintain a query log that maps each backlog item – this will help you when your in the sprint planning meeting to ask the right questions at the right time.

  4. Keep a defect log during each sprint - add those defects that are not cleared at the end of each sprint to the product backlog.

See also:
Agile Testing is not for Dummies
Agile requirements are barely sufficient!
Agile Testing
Why Testers should be in at the start







3 comments:

  1. I'm curious about how much full regression testing needs to be done in an Agile environment in order for the team to feel comfortable about the release quality. Since code is often interlinked in multiple places, changes will cause unexpected consequences, and without a full regression how do you know whether you are ready to ship it?

    Does anyone have any data or info on this?

    ReplyDelete
  2. That is exactly why agile methods advocate including as much testing as possible into the definition of done. How much is possible in reality, depends heavily on the context and the team experience

    ReplyDelete