Integrate Test Activities in Agile – Webinar Questions&Answers&Discussion ;-)

[Rik]

At 23 July 2014 Rik Marselis presented the webinar “Integrate Test Activities in Agile Projects” based on the EuroSTAR eBook thatLeo van der Aalst and Rik published in 2013.

This discussion is the Questions & Answers session of that webinar.

You can download the eBook here

You can view the webinar recording and slides here

If you want to read even more on this subject check out the book “TMap NEXT in Scrum; Effective testing in Agile projects” (www.ict-books.com) and presentations at my slideshare account (search slideshare for Rik Marselis)

Let’s have an interesting and fruitful exchange of knowledge and visions !!

[Stuart]

Hi Rik

Great presentation

Is it possible to download the slides
And even better, was the presentation recorded so the rest of my team who missed it, can download it and watch later?

Thanks

[Jonathan]

Hi RIk, Regarding the sustainable marathon in one of your last slides, what kind of things do you insert into a series of sprints to make it a sustainable marathan?

[Rik]

Hi Stuart,
Thanks. The webinar was recorded and will be available within 30 minutes. Also the slides are at the TestHuddle and EuroSTAR pages and I have also put a PDF of the slides on slideshare.
Regards,
Rik

[Christer Mörling]

Hi Rik, thanks for a interesting webinar, Regarding the last slides on end-to-end testing in larger systems; Whats your experience on cross-functional teams working with multiple systems and Continuous Integration?

[Rik]

Hi Jonathan,
to make a sustainable marathon a common practice is to have a hardening sprint once in a while where no new user stories are picked up but only technical debt is worked on.
Also you need to be careful about the team’s velocity, The limitation is not what the programmers in the team can build but what the team as a whole can realize together. And sometimes the developer (being optimistic always) will think much more can be done than they actually can.
A good Scrum Master will guide the team on this.
Regards, Rik

[Krzysztof]

What about non-constant speed of development? e.g. team is working fast during few days (or even sprints) to deliver software quickly to get feedback, then slow down for all current (or future) planning and refactoring, then go normal speed and do the same cycle again? Can this behaviour be bad for agile?

[Abdul]

Hi Rik,

Excellent presentation!

Now, what will be your suggested steps to get management, who control the purse strings, to adopt what you have presented, as a bench mark for testing activities, within an Agile environment?

Thanks.

[Rik]

Hi Christer,
My advice is to have a separate team that supplies a “end-to-end-testing service”.
So the Scrum Teams can request an end-to-end-test as a service from a specialized team.
Of course this requires some planning ahead, and also that service-team will have to be kept up-to-date with what is being developed in the organization, for example by taking part of the Scrum-of-Scrums.
Regards, Rik

[Stephen]

Hi Rik, thanks for a great presentation.

You talked about sprints often have having just one Test proffestional. In a larger organisation there may be more tester available, would you switch the tester out for each sprint depending on the highest priority skills for that sprint?
e.g. first sprint could have a Test Manager to define the strategy and get the project going
Second sprint being a manual tester/test analyst with expertise in the components being delivered in that sprint
Subsequent sprints may have Automation Testers, Functional/Non-Functional, etc as appropriate.
Final sprints including the manager again for wrap up and final review and reports, prep for UAT

Steve

[Rik]

Hi Krzysztof,
In principle the team is responsible for everything, so also for the speed they think is achievable. And of course once in a while there may be the need for real fast delivery of products and they may want to work very hard (for example by doing overtime) and that may be very effective.
But they must keep in mind that such behaviour is only sustainable when it is interchanged with less busy sprints.
Be aware that the “business-managers” (beyond the product owner) may get the impression that an extraordinary performance is actually “normal” and then start expecting the same velocity in all sprints.
So if it is well managed and well communicated some extra effort doesn’t have to be a problem but make sure that people won’t take extraordanary things for granted.
Regards, Rik

[Tonje]

Hi Rik.

Thank you for a great presentation.
I will be sure to check out the material you link to.

Thank you.

Tonje.

[Stuart]

Hi Rik

With Agile now working it’s way into large projects, how do you handle teams spread over separate locations and timezones?
i.e. Stand-ups etc.

[Donovan]

Hi Rik, thanks for a great presentation.

I can see the value of separating E2E testing from our normal sprint testing strategy, but I often run into the problem of how to interpret the definition of done as applied to stories I am testing if they are not fully deliverable due to dependencies outside of the story being developed by my team. It gets difficult to talk about with the team, at times, because the user story says, “as (actor) I want to be able to do x,y z with (new functionality)” but doesn’t go into technical detail about everything that is needed for that to work (i.e. deliverables from other teams in my organisation or even 3rd party software). As a tester, I tend to think about the functional requirement in the user story and whether or not we’re delivering that, regardless of dependencies. My question is, when is ‘done’ really done? i.e. is it ok to call our story done and complete if there are parts that can’t be demonstrated yet due to dependencies?

[Rik]

Hi Abdul,
The higher the management they less they know about details so they must be inspired by things that matter to them. And normally that is by pointing at achieving the right quality level and not wasting money on fixing and rework by implementing early quality measures.
Regards,
Rik

[Rik]

Hi Stuart,
About distributed teams:
Principle one is that the entire Scrum Team must be in the same location. Even being in the next building can already be a problem. Let alone being at another continent.
On the onther hand: sometimes you need collaboration of people that can not be in the same location. Then you can make use of modern technology, like videoconferencing and using chat-functionality.
I know an example of distrubuted teams having the daily stand-up in the video-conference room and they are quite happy about it.
Regards,
Rik

[Rik]

Hi Donovan,
To solve your problem of “when is it really done” some Agilists distinguish between “Definition of Done” DoD, “Definition of Ready” DoR and “Definition of Shippable” DoS.
I quote from our book “TMap NEXT in Scrum” The formulation and fulfillment of the DoR aims at ensuring that all criteria for successfully launching a sprint have been met. The formulation of a DoD is always necessary to determin whether or not activities and products meet the specified criteria and are consequently “done”. When the sprint has been completed the DOS determines whether or not the product can be released into production and used.”
The DoR and DoD relate to the sprint-goals. The Definition of Shippable relates to “release-goals” and thus the end-to-end-testing will relate to the DoS.
Does this help you?
Regards,
Rik

[Stephen]

Hi Stuart
There’s a webinar by XBOSOFT tommorrow about “Remote Agile Testing”. The link I have is supposed to be unique to me and they ask us not to share them. I received the invite in one of the many newsletters I’m subsribed to. I can’t remember which one. You might be able to find it on the XBOSOFT site though

[Donovan]

Hi Rik,

Your answer was helpful and intriguing… I was already planning on getting your TMap book and now I definitely will. Thanks again!
Best,
Donovan

[Rik]

Hi Steve,
You ask about switching testers from team to team. I wouldn’t do that. A Scrum team is most effective when they stay together as a team.
However, the team may recognize that they lack certain skills. These extra skills can be obtained by bringing “support-people” in for assisting at certain tasks.
For example while preparing the test strategy a test manager may be involved by the team to support them.
And in a later stage a test tool specialist may be involved.
regards,
Rik

[Willem]

Hi Rik,

Thank you for an interesting presentation. It was good to see all those factors I already know seperately in relation to each other and related to agile.
My question:
In one of the sheets, you said the desired quality level should be in the DoD. I’d think it should also be in the DoR, because we always say “rubbish in, rubbish out”.
As Donovan already said: a user story should be tailored to what the team actually will develop, in enough detail for it to be built and tested during the sprint. The upper left part of the ‘V” should make shure that it meets those entry criteria.
What do you think?

Regards,

Willem

[Donovan]

Hi Willem, Rik, and all,

Just wanted to mention that, while I didn’t specifically write about story grooming and review, I can see why you would infer it from my comment/question and I do agree that DoR should hinge on it being able to be built and tested. As Rik pointed out, there are other ways of looking at DoD also and DoS which I will now have to read up on.

Basically, I agree that meeting entry criteria helps a lot with these types of problems, but I am still concerned with whether or not we consider a story to be done if some aspect of it is not functioning due to any outside factor, whether it was identified in risk analysis or completely unforeseen.

I’m not sure how long this forum will continue, but I will check on it again later as I have to leave. Thanks to all and especially Rik for an interesting discussion.

[Rik]

Hi Donovan and Willem,
The DoR indeed is important to make sure the quality level is right from the start.
Donovan’s struggle with “am I ready if I have delivered only part of a solution” (which is the case if you are dependent on things from outside your team) is in my opinion solved by having a DoD that refers to what you as a team have to do. Things outside reach of your team you don’t have to do. But of course the teams together must make sure that one way or another they also fullfil the DoS. And that will probably require some sort of coordination (or Supervision as I tend to call it). There for example a test manager (new style) can play a significant role.
Regards, Rik
By the way: this forum will remain so we can continue exchanging experiences here !!

[Emma]

@Stuart The recording of the webinar is available here: https://huddle.eurostarsoftwaretesting.com/resource/integrate-test-activities-in-agile/ feel free to share it with your colleagues 🙂

[Author]

Posts