Kategorien
Learning Testing

Changing Your Testing Mindset (agileTD 2013)

At the Agile Testing Days 2013 I attended Janet Gregory´s tutorial on „Changing Your Testing Mindset“. Also I already knew quite some of the things she talked about, it was a good tutorial and I had some great conversations with Janet as well as with the other participants. I can highly recommend to visit this tutorial if your want to learn some essential things about testing in an agile context.

Here are some of the most important things I took away from the tutorial:

„The Thinking Tester“ vs. „Zombie Testers“

Technical Awareness

as a skillset for agile testers; in a group discussion we came up with the following items

  • be able to read DB schemas and execute SQL statements
  • technical know how on the AUT
  • detailed domain expertise
  • system overview (to identify possible impacts)
  • speak business & technical language and act as facilitator
  • logical thinking
  • knowing things that go „beyond the system“

Agile Testing Pyramid

testing_pyramind

The pyramind is just a model, it has to be adapted to your context, e.g. in a COBOL project unit tests are very hard, but you can do other automated tests/ scripts on that level.

Testing Tours

E.g. Define a tour, go to Paris: What are the things you _must_ see as a tourist?
Supermodel tour: What features does marketing use to sell the product?

Miscellaneous

  • Instead of discussing acceptance criteria with POs & devs, discuss about a list of concrete tests, this enhances the conversation.
  • If an acceptance test has more then one happy path, this is an indicator that it´s more then one story!
  • Embraces agile priniciples: Simplicity, Feedback & Respond to change, in the sense of „Responding vs. Reacting“
  • Learn to ask questions early, this results in fast feedback!
  • You don´t consider asking your PO when he´s out of the room.

2 Antworten auf „Changing Your Testing Mindset (agileTD 2013)“

Hi Christian,

thansks for sharing your learnings from the workshop of Janet. Some points are really interesting ( like the testing tours) and I would try them with our teams. Some other points ( ie the miscelaneous part) are not really clear (too short) and it would be great if you detail them..:-)

Btw I decided to go to the David Evans workshop about effective user stories, as it is th we are dealing with and trying to optimize. I promie to write a boog about it ;^)

And last but not least.. good talk too !

Hi Anis,

thanks a lot for your constructive feedback.

I´ll try to elaborate on the miscellaneous-topics:

Instead of discussing acceptance criteria with POs & devs, discuss about a list of concrete tests, this enhances the conversation.
This was an advice by Janet, she said that disussing with product owners & deveöopers over concrete tests (or examples) enhances a communication about a user story much more then pure discussion about acceptance criteria do.

If an acceptance test has more then one happy path, this is an indicator that it´s more then one story!
The point Janet wanted to make by this was, that if a test can be executed in two different ways to have succesful result, it might be possible to split up the user story into to (independent) user stories instead.

Embraces agile priniciples: Simplicity, Feedback & Respond to change, in the sense of „Responding vs. Reacting“
The first part is a direct quote from the slides, it is about how an agile tester behaves. The additional note by means explains the last point a bit more: A tester should not just react on things that happen, but really respond to them in order to act meaningful.

Learn to ask questions early, this results in fast feedback!
Aiming for „fast feedback“, which is one of the core principles of being agile: The faster you get feedback, the faster you can learn & adapt.

You don´t consider asking your PO when he´s out of the room.
One of my „AHAs“ from that day: While doing a simulation where participants acted as developer, tester & product owner, Janet took the POs out of the room. No one of the remaining people even considered to go out to ask the POs the many questions they had. I think in real live this is very often the same, so a development team should share one office, this enhances (direct) communication.

Hope this helped a bit? If you´ve more questions I´m happy to answer them!

Looking forward to read your blog post about David´s tutorial!

Best,
Christian

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.