The Role of the Tester in the Agile Enterprise

[Malcolm Isaacs]

Thanks for tuning in to the webinar.

So – did I miss anything out? Do you agree/disagree with the points I made? Share your thoughts here…

[alt]

Webinar is in two hours, right?

-^. ^=-
~~ ~~

[Daragh]

Hi Alt,

Yes the webinar is in two hours but we are just making sure the discussion is ready for afterwards. We hope you can make it and that you’ll have LOADS of questions for Malcolm 🙂

[alt]

tuned in 🙂

-^. ^=-
~~ ~~

[Celia]

I want to enable testers in an agile space to understand their limitations and want to use a profiling tool to assist. The tool I use is Enneagram as it looks at motivations and not behaviours. Has anyone else used another or the same profiling tool and obtained a good stat that enabled the testers in their teams?

[alt]

Tnx for the presentation.
Having a bit of a hard time to come up the questions – can relate to the most that was mentioned.

We are probably still on the way to become and Agile enterprise – we have changes to which to adapt also within sprints. Not everything can get ironed out/anticipated in grooming/planning session.

Kinda like a statement – we’re being agile enough to adapt within ongoing sprint rather then rejecting the changes because this is current sprint and that is supposed to wait. Not to the point where anything goes – but – the ones that are relevant to what we are doing right now – to me as a tester is seems wiser to adjust the implementations we are thinking about as soon as we know that afterwards we will have to do decent re-factoring just because we did not adapt to it right away.

What would be your take for such case: a change within current ongoing sprint – that seems to have better business value, less triggered waste afterwards etc 🙂

-^. ^=-
~~ ~~

[Carlos]

How fit Agile within ITIL context ?
How to structure the process to comply to Audit process that target Quality Assurance deliverable ?

[Daragh]

Hi everyone, I was in contact with Malcolm there and he has had a number of appointment to attend directly after the webinar. He will be available later to take questions but in the meantime please feel free to leave your feedback.

What did everyone think?

[Malcolm Isaacs]

Hi alt,

Thank you for your comments. You raise an interesting question. As you note, Agile will push back on introducing content into the current sprint. But I think there can be cases when it’s ok to accept changes in a sprint if the change brings more business value than a task in progress. I would recommend taking a few points into consideration though:
– Will the change interrupt a task currently in progress? Is there business value in that task? What’s the relative cost of pushing it off to another sprint? What is the cost of picking it up later?
– Are you planning on delivering the change to production at the end of the current sprint? Is it worth the disruption if you’re not going to deliver it to production yet? Maybe it’s better to make the change in the upcoming sprint, in which case you can plan for it in advance.
– Is the scope of the new item similar (or smaller) than the item you want to replace? If not, you run the risk of not completing other scheduled items – which might be ok – but only you can make that judgement call.

[Malcolm Isaacs]

Hi Carlos,

Thanks for your question. I think it’s possible to take ITIL and other requirements into consideration as you plan. If you must collect metrics for ITIL, or perhaps there are regulatory requirements which you wouldn’t normally collect in an Agile project, then you can add them as a user story, or make them part of the ‘Done’ criteria for a story, if that makes more sense for you.. That will ensure that you get the benefits of working with Agile methods while staying faithful to enterprise requirements.

[Dinz]

Hi Malcaolm,
I have a question.
How does the test artifacts (test cases, mind map) review process should happen in Agile Testing?
Do we need to maintain review logs as in traditional method. But it takes time to maintain review logs. is there a better way of doing it?

[Malcolm Isaacs]

Hi Dinz,

Great question! First, what do you mean by ‘review process’? In Agile, you will be working closely with other testers and developers to understand the scope of a user story, and on the definition of ‘Done’. Part of the ‘Done’ criteria is to state and refine the tests it is expected to pass in order to be considered ‘Done’. I think that this is the Agile equivalent to the review process that you are talking about. You will also need to think about why you need to maintain review logs. What value do they bring? Are they needed again after a story has reached ‘Done’? If you need to maintain a review log of a story that was ‘Done’, then perhaps you need to tighten up your definition of ‘Done’. Or consider creating a new user story rather than modifying the existing one.

Secondly, in an Enterprise setting, you might have obligations to non-Agile parts of the organization, and the policy might require reviews and review logs to be submitted to other teams or management. If you can’t change the policy, then think about folding these requirements into your sprints in the form of user stories and definitions of ‘Done’. This will allow you to continue to be Agile, and answer Enterprise requirements at the same time, within the Agile process.

[Dinz]

Thanks Malcolm.

Actually we have recently start Agile . Therefore actually we have lot of questions. Our team includes testers, business analysts, development team and they are working closely as you said.
Usually tester draw the mind map (high level view of CR which covers the testing scope) and pass to BA. Then the review done by BA. Once BA done the review, testers incorporate those changes.
Currently developers are not involved in mind map drawing. But testers take the inputs of them since they are sitting nearby.

For low complexity CRs, BA & QA sit together and do the review so that QA can incorporate changes at the same time.

But the problem is for high complexity CRs. For such CRs, we cannot expect BA & QA to sit together and do the review. Because it is time consuming and it will take the time allocation for 2 resources for one single task. BA need some time to understand the mind map, Then QA might idling.

As you pointed out review log may not add any value addition. But problem is for large CRs, there might be a possibility of missing important areas, and if there are lot of mistakes found during review it is difficult to pass without any review log. Therefore BA ideally do a review log and pass it to QA.

Could you please suggest a way to do mind map review for large CRs? (which has large number of testing scenarios)

[Malcolm Isaacs]

Hi Dinz,

I would consider a few things:
– Can you split up the complex CRs (I guess it stands for ‘Change Request’) into smaller ones, in such a way that you can deliver them across two different sprints? Perhaps doing the design and planning in one sprint, and the actual implementation in the next sprint?
– QA shouldn’t be idling while the BA is working on the mind map. There are other tasks that QA can do until the BA is ready. In any case, the BA’s work must be timeboxed so there needs to be a good estimate of how long it will take. As you do more of this, you will get better at estimating.
– You might want to consider ‘swarming’ over large CRs and getting a few more BAs and QA involved on a single CR. You could break them up into pairs of BA/QA, with each pair working on a small part of the CR, integrating (ie. sharing status) very often so that everyone is in synch with the whole CR even though each person is only working on a subset of it (a sort of ‘T’-model, where people have both broad knowledge but also specialized knowledge).

I would strongly suggest that you work with an experienced Agile coach, if you’re not doing so already.

[Nicholas]

Hi Malcolm,

I know HP has recently rolled out agile within their teams, do you feel the experience has been largely positive? Have you had any specific issues now you’ve switched to this methodology?

Within my team I find it very difficult to build in on-going testing work, for example if we wanted to setup some environments for testing, write a test plan for a feature/area outside of current sprint content, bring up automated test coverage. The solution to this seems easy, just create specific tasks/stories and bring them into a sprint. However, in reality I find that these ALWAYS get pushed to the back behind what the product owner wants in each sprint. I understand this but feel this negatively impacts us in the long-term. Do you have any advice on how to ensure these on-going tasks are completed and not overshadowed by new features etc?

[Malcolm Isaacs]

Hi Nicholas,

Thanks for your comment. I would say that yes, the experience has been positive. I can’t speak for the whole of HP, but the groups I’ve worked with have embraced, and in many cases driven the move to Agile. Part of Agile success is dependent on your organization’s ability to accept failure and mistakes as a learning experience, and apply the lessons learned moving forward. This is the responsibility of the teams and of the management, who need to support the teams and not penalize them when honest mistakes are made, and HP has been very supportive with this.

Regarding your question around testing tasks, I would recommend that instead of creating new tasks for testing, you should consider testing as part and parcel of the user story, which includes the ongoing testing work you refer to. This would be defined as part of your ‘Done’ criteria, so that a user story is not considered ‘done’ until the testing is complete. At the end of the day, are the product owner and the rest of the team prepared to deploy a user story that hasn’t been fully tested? In some cases, the answer might actually be ‘yes’, but at least the decision to compromise on testing will be made consciously and with a risk assessment, and not automatically pushed to the bottom of the backlog.

[Padmaraj]

Hi Malcolm,

I am working in Extreme Programming (XP) environment.

You discussed about Agile enterprise level testing: What you think about small team / organization who less people and ready to adopt Agile ? How tester can work small Agile team more effectively? ( any quick tips/suggestion )

[Author]

Posts