EuroSTARonline: The 3 Pillars Approach to Agile Testing Strategy

[Daragh]

If you would like to ask Bob Galen & Mary Thorn any questions, or discuss his EuroSTARonline presentation, you can do so here.

I look forward to seeing what you have to say 🙂

You can view the slides & webinar recording Here

[alt]

One question i have: my team is having concerns that for the UI tests (top of pyramid) to avoid many tests checking one thing – i prefer to make them more a actual business use cases (full/half process) checking several things as the test goes on. What would be your opinion regarding this? 🙂

-^. ^=-
~~ ~~

[alt]

another question: we don’t have fully cross-functional team – yet we collaborate.

in short – after fine scrutiny at grooming and some addtitional at the planning ->for us -> tester produce test ideas – and then we divide in 3 groups (test automation wise) that afterwards deal with client unit/int and backend unit/in tests – testers left with manual/gui –

the sunshine moment Devs help out with Gui and some manual 🙂 – i love to work in my agile team :p

any direction you could suggest for us to try evolve further on?

-^. ^=-
~~ ~~

[alt]

(:

-^. ^=-
~~ ~~

[peat]

Hi alt, no such thing as a silly question, ever. Weirdly phrased ones, sure.

[Alejandra Viglietti]

Hi!

I’m interested in the ebooks to go deeper in this topic.

Thanks in advanced!

[Mary]

Alt – My opinion is something like this. UI tests are fragile and slow, so go through the screens you have to once but then focus on writing them at the integration level. In my opinion the testers are best to write UI tests, the developers are best to write the Unit tests, and the whole teams owns writing the Integration tests. Like Bob would say it is just additional work that needs to get done. As far as UI automation, while I am not fond of checking many things on a page at one time while automating the benefits of speed to run makes me sometime be ok with that. When you use tools like Specflow or Cucumber driving Selenium it allows for both scenarios. My testers understand that I prefer not to check 20 things at one time though.

I am quite not sure i understand your automation process, but this is how I recommend it working. Testers create test ideas, as part of that along with a conversation with developers and PO they decide on what is getting automated and at what level(unit, int, ui). In sprint planning tasks are created for all the automation that needs to get done, and then people pick up those tasks when it is time. Now, most of the time my testers pick up the UI automation and developers pick up the unit testing automation. But the integration tests can be picked up by anyone on the team. That does mean my testers usually have to be able to code in say C# or Java.

I hope that answered your questions.

[alt]

Mary – thanks for the answers 🙂 you did respond – yes 🙂

-^. ^=-
~~ ~~

[Matt]

Hi guys! I only caught the first 20 minutes of your talk before with all the buffering it came too hard to continue 🙁 Are the talks going to be published on here somewhere so I can watch at a more civil hour (on an Aussie timezone)? Cheers.

[Bob]

Regarding UI tests, and I’m not sure if this will contradict Mary or not…but always remember she knows best.

The Pyramid implies Unit-level to Component/API/Acceptance-level to UI/Functional-level automation. As you go up the pyramid, the tests are:
– larger
– Wider
– Take longer to run
– Take longer to fix, when they break
– Consider the customer workflow more

So @alt, UI tests by definition test customer use cases or workflows. I’d actually consider them leaning towards workflows or transactions. I’ve sometimes used the term “steel or gold threads” to define the key workflows that we’ll be automating. I often limit the # to somewhere between 10 and 20 for an application…to make sure we’re leaning our efforts.

Just another reaction.

[Bob]

If you’re interested in following Mary and my “escapades” as we finish and publish and iterate on our 3-Pillars book, best is to join our mailing list designed for that.

You can do that here

It will also give you access to a “Downloads” area for other Agile Testing materials…

Thanks,
Bob.

[Bob]

@alt – this level of collaboration sounds wonderful!

One reaction/thought. It sounds like you’re splitting the work and folks “go off” and do that work. I’d rather you process a story as a team. Yes, individuals do work related to the story, but they do it from a “getting the story done-done-done ASAP” perspective and not working within a functional silo mindset. Some folks define this as “swarming” around stories. WIP limits come into play here as well.

If this is the behavior, then I think….you’ve got it 😉

[Author]

Posts