Tag: Agile Testing Days

Agile Testing Days 2016 — Part 6: Conference Day 3

Testing 1 Comment

For the 3rd conference day, I’d like to mention two highlights: Ida Karine Bohlin‘s “The Tinder Project—How To Test The Right Swipes” and Gojko Adzic‘s keynote “Snow White and the 777.777.777 Dwarfs“.

Ida introduced Tinder, an online service to meet people. It can be used to find someone to have a chat at an airport or meet a lifetime partner. She described how she applied her testing knowledge to search for a partner on Tinder. The compilation of acceptance criteria  was hilarious already, including a good dozen aspects from handsome (but not weak) to strong enough so he could help with heavy luggage at airports. She presented the testing quadrant for identifying test approaches she applied and a testing pyramid to be used. To me, the topic of agile testing was very well presented, the talk was very funny and entertaining. Well done, Ida! I believe it would make a great keynote to introduce the topic of agile testing at a conference!

Gojko presented some aspects, that he believes will change the world of testing in dramatic ways. Two of the reasons for these changes are the ever decreasing cost of computation in general (e.g. by  services such as AWS Lambda), and the decreasing time needed to fix issues after production defects are found.

When applying a micro service architecture, the single service can be tiny — Gojko talks about a few dozen lines of code. With so little code, finding the cause of a bug is typically easy. (At least a lot easier than in a code base containing hundreds or thousands of lines.)

Let me finish with just one tweet about this talk (there are many more on Twitter):

Due to Gojko’s presentation there was a whole new session dedicated to “Gojko’s Future” during the unconference day that followed this 3rd day of Agile Testing Days 2016. But since that’s another day, I will cover it in the next blog post.

Agile Testing Days 2016 — Part 4: Conference Day 1

Uncategorized 1 Comment

Similar to the past few years, I participated in the opening session of the Agile Testing Days playing the role of Super Agile Person—only this year Super Agile Person represented the ghosts of testing past, present and future. Playing and singing along with the audience to the tunes of Jingle Bells was great fun. Thanks to Elad who posted a short video sequence of this on Twitter

https://twitter.com/eladsof/status/806050167925383169/

I enjoyed the opening keynote by Abby Fichtner a lot. It made me think about the close relationship between vulnerability and braveness. Here’s Samantha Laing‘s sketch note summary:

The next two sessions rushed by in no time — I was thinking about my own session in the afternoon too much, I believe.

Since I had to prepare some Raspberry Pies,  set up my own network for my workshop, I missed the 2nd keynote of the day. A huge “Thank You!” to Dragan Sekuloski for helping me setting up the workshop!

Sadly one thing went wrong: When presenting a topic as “Testing and the Internet of Things” two aspects are essential: The things and the internet. Alas, the internet wouldn’t work! So the story of Goblin King Jareth XLII and his labyrinthian world of connected rooms had to proceed without the prepared game. Sad but true.

Given how bad it started, the workshop then went pretty well: Thanks to understanding and wonderfully active participants we were able to collect a good number of topics the King was interested in. In particular the King wanted to learn about 3 topics:

  1. What risks are we facing?
  2. What interfaces are we dealing with in the Internet of Things (IoT)?
  3. What should be tested (and what shouldn’t)?

Here is a list of what we listed during the session:

Risks

  1. Power outages
  2. Cables can be pulled
  3. Malicious input
  4. No proper instructions
  5. Unreliable hardware
  6. Memory leaks
  7. Loss of device
  8. Dependencies
  9. Display resolution

Some of these are not limited to the IoT, and in fact many can happen in other contexts as well. However some of the risks, when dealing with the IoT, are more, well, risky.

Interfaces

Here we did not precisely differentiate between interfaces and transport mechanism.

  1. Skin (think of heart rate monitoring fitness trackers)
  2. Sound, microphones, pressure changes (think about services like Siri)
  3. Light, eyes, radiation (iris scanners, light barriers)
  4. RFID, NFC (card readers, new payment methods, theft prevention)
  5. Brain waves

Not all of these are easy to measure or available everywhere. The point is that in the IoT we are dealing with a lot more interfaces and mechanisms to transport information than in ‘ordinary’ web apps or most other software systems. And each additional interface also provides a new way for attackers to get into the system.

What to Test

  1. Battery life
  2. Replies of other systems
  3. Bad conditions (e.g. when using light to communicate through air, what about fog?)
  4. Connections
  5. Distance (How far away from a card reader can a card be read?)

It gets really interesting when these topics are combined. Since the initial reading of RFID cards worked on the computers during the workshop, we discussed these questions as well:

  1. Is it necessary to test the uniqueness of the IDs stored on the cards? When? Why?
  2. What about testing the card readers?

An interesting observation: The card readers used in the workshop actually register as a USB keyboard when connected to a computer. This means that we could unplug the reader and still enter data using a real keyboard. Since the real IDs of the cards were also printed on the cards themselves, we even had IDs the system would recognise!

After my workshop I took a break from the conference and went for the next great offer right in front of the hotel: A conference private Christmas market! After enjoying some “Grünkohl mit Würstchen” it was already time for the next big thing: The “Ho-Ho-Ho-ly STWC & MIATPP Award Night”.

As in the previous years the 1st conference day ended with a great costume party and ceremonies for the award winners of the year. Congratulations to the Dutch team “Pan Galactic Gargle Blasters” for winning the “Software Testing World Championship” and to Maaret Pyhäjärvi for winning the well deserved “Most Influential Agile Testing Professional Person Award”!

costume-party-2016_s

 

Update (12. Dec. 2016): As promised, here is a PDF version of the slides used in the workshop: https://seasidetesting.com/wp-content/uploads/2016/12/stephans-labyrinth.pdf

Agile Testing Days 2016 — Part 3: Tutorial Day 1

Learning trust Uncategorized 2 Comments

This year at the Agile Testing Days, I attended Samantha Laing and Karen Greaves 1/2-day workshop “The Collaborative Team”. It turned out that there was just one other participant in this tutorial, so actually it was much more like a private coaching session. A big thank you for offering the session anyway and making this possible.

The information and exercises were all about building and keeping trust in the team. I found it very interesting that, in order to increase the trust level, it is also important to know what the team can (and can not) influence.

Knowing this, makes it easier for teams to cope with undesirable situations. For example one of my recent teams was moved out of the building where most other teams are located, to a place some minutes walking down the road. For me, it was much easier to understand and accept this, after we learned about the reasons management gave us. — I still didn’t actually like the situation, but at least it was clear why this decision had been made.

This is a theme we touched in the tutorial time and time again: Talking and listening to each other helps immensely.

Another important takeaway for me were the exercises about the power of questions. The ability and patience to listen to people until they have spoken is so important. I have been given solutions (or suggestions for immediate steps) so often, when instead it would have been important to first understand the problem in more detail, rather than providing the tips that came to mind first. — I admit that I have done this, too.

With the experience from this workshop and the material we were given, I feel much better prepared to help teams improve, not limited to software testing but also in the topics we covered in this coaching session.

I liked the half-day format of the session a lot for two main reasons. First of all, this coaching session with two coaches and two attendees was very intensive and a little bit exhausting (but in a good way). Second of all, I had a free afternoon that I was able to spend in the beautiful city of Potsdam. 🙂

Thank you very much Karen & Sam and of course co-attendee Elena! If you have the chance to get this kind of session at a conference (or elsewhere), I can only and full-heartedly recommend it.

My ‘Day 1’ of this conference ended with a delicious speakers dinner in a very festive atmosphere.

agiletd-2016_conference-dinner_s

Agile Testing Days 2016 — Part 2

Testing No Comments

StephanKaemper_atd_banner_880x440

Here’s a short reminder that I’ll be speaking at the Agile Testing Days 2016 this December. As the banner says: If you’re planning to attend the conference, ask me for a discount (it’s a coupon code) and I’ll be happy to send it out.

There’s a promotion video in the previous post “Agile Testing Days 2016 — Part I: Promotion Video“. Hope you enjoy it!

 

The Agile Testing Days 2015: Nuggets

Learning Testing 1 Comment

The opening session of the Agile Testing Days 2015 was Western-themed and Janet Gregory and Lisa Crispin asked the audience to watch for gold nuggets at the conference — particularly valuable information or other things we would take home. I (actually my alter ego Super Agile Person) was invited to present my suggests at the ending session. So these are the nuggets I found at the conference:

  1. I got a Calgary Stampede hat from Lisa and Janet. Thank you so much!calgary-stampede-hat_2It’s great, it fits and it even has inner values printed on the inside:
    1. Commitment to Community
    2. Integrity
    3. Pride of Place
    4. Western Hospitality

    The first two of them are particularly applicable in all communities.

  2. In their opening keynote Alex Schladebeck (violin) and Huib Schoots (trombone) connected music to testing and played music too. They even handed out a large number of kazoos to the audience to play along with them!
    I find the connection they drew fascinating, since other presentations I attended this year presented connections between testing and other activities. Two examples from FullStackFest are Ernie Miller‘s talk “How to Build a Skyscraper” and Lauren Scott‘s presentation “Shall I Compare Thee to a Line of Code?“.
    I’m thinking about other connections, but that’s another blog post.
  3. Many people use templates to write user stories or charters for exploratory testing sessions. A widely used user story template is this: 
    As a <role>;
I want <feature>,
so that <benefit>

    While these templates can be very helpful to start, they are also somewhat limiting — and can lead to outcomes like ‘As the product owner I want feature X, so that feature X can be used’. This is not — repeat not — how the template is used well.
    While templates can be worthwhile to get started with using user stories (for example), they can become too constraining as a team becomes more proficient in using them.
    In that case, I suggest to use the term Free Style User Stories and Karen Greaves already helped me spreading the word:


    Thank you!
    This too, will be covered in a future blog post.

  4. Finding followers and starting a movement is possible for everyone. This was a popular topic in a number of sessions, Dr. Sue Black‘s keynote “If I Can Do It, So Can You” in particular.

Note, ‘nugget finding’ is not limited to conferences! What are the nuggets you found in the past week?

Aspects of a Good Session

Uncategorized 5 Comments

Still in time for this year’s submissions for the Agile Testing Days 2015 here’s a list of takeaways from an Open Space session at the Agile Testing Days 2014.

This blog post is the result of George Dinwiddie and me asking what makes a good conference session at one of the Open Spaces. In this session we were about 8 people, so the information gathered may not be a representative for all attendees of the whole conference—and it may or may not represent other conferences.

That said without further ado, here’s the list:

  • Context for the content
    Providing context helps listeners to relate to the content and understand the circumstances in which the information was gathered. Both can be important to transfer the presented information to ones own work place.
  • Funny
    This has also been noted down as ‘makes you laugh’, which may be subtly different from ‘funny’. Most people like to laugh or at least smile. It also helps to remember a presentation if it’s entertaining as well as informative.
  • Little text
    Don’t bother people with too much text on slides. Many people will start reading—and at the same time stop listening to what’s being said. In addition to that some of the people who do not start reading, will be annoyed because the text is too small to be read.
  • Share pain points and problems, not just successes
    There’s hardly any project at all that doesn’t run into some kind of trouble. That’s OK.
    Tell people about the issues your project experienced—and also how you managed them.
  • Tell a story—a personal story
    Most people love listening to stories, even more so for a personal story.
  • Short
    Well, keep it short and stay in your assigned time box.
    Extra credit if you manage to give your audience some extra time to switch conference room after your session.
  • Experience things
    Let the audience have an experience versus just listening.
    At best this is an interactive workshop. At least this is a vicarious experience.
  • Interactive
    People like to provide input, even when attending a conference talk. Providing some interactive tasks also helps people to engage with the presented topic.
  • Speaking from experience
    At least at the Agile Testing Days, people like to learn about, dare I say it, real life experiences.
  • Can ask questions along the way
    If you can (or even like) answering questions and responding to comments along the way, by all means do so.
    However, I respect it when presenters prefer to answer questions after the talk.
  • Things that connect different topics
    Learning about new ways in which things are connected is interesting for many people. (However, I recommend against forcing this into a presentation.)
  • An outlandish topic
    Some like bizarre, unconventional stories. This certainly helps to get the audiences attention.
    Notwithstanding, don’t forget to link the presentation to the overall theme of the conference.

Some things that came to mind after the session: 

  • Images
    Provide meaningful and consistent pictures, graphs and diagrams.
  • Big, easy to read text
    This matches well with ‘Little text’ from above.

Please do not hesitate to add a comment, if you would like to add to (or disagree with) the list.
In any case, consider submitting a proposal for the Agile Testing Days! It’s a great conference, it’s fun and there was a costume party in the past few years.

The Agile Testing Days 2014: Conference Day 3

Learning Testing 1 Comment

The last conference day started with a very personal & inspiring (and slideless!) keynote from Antony Marcano, entitled “Don’t Put Me in a Box”. He made a good point about how people have many ‘labels’ outside their job such as mother or father, friend, cook, helpful neighbour etc., while in a job there’s often only one label: The job title. In fact, he asked as few listeners in the audience about what they do and everyone answered with a role or a job title.

He explained how this may be an impediment for agile teams. If (or when) we stay in the box of our job title, we might not get a chance to help in an area that’s outside the main focus of our job description.

The following talk “Pull Requests and Testing Can Be Friends” by Alan Parkinson presented some very interesting points. One of them was this: While it may not be necessary for testers to be able to write code, it may be very useful to be able to read code.

His presentation was mainly how his company uses pull requests in Git. I found it interesting that they use pull requests for a lot of things, including reporting and tracking bugs found when testing the change that implemented the pull request. The reason they do so is simple: The context in which that bug was found is that pull request, therefore these two should be kept close together. They implemented this by having a discussion for each of their pull requests. To me this makes a lot of sense for a development team.

After that I attended Chris George’s talk “Easing the Pain of Legacy Tests” (Be sure to watch the slides, they’re great!). He explained how his team started with a long running (as in: 16 hours) test suite that reported about 20% of the tests as failed; and not always the same 20%. After some iterations of working on the problems they had significantly faster as well as much more stable tests. So, for his team it was well worth the effort.

In the afternoon, I attended Selena Delesie‘s workshop “The Best Agile Managers Thrive When Teams Do”. An introductory exercise showed how stressful it can be for both the manager and the team, if the manager tries to control the progress, instead of allowing the team to solve the problem at hand.

Often it’s better to make the goal visible to (and understood by) everyone, and then let the team work out the solution. One thing I found particularly interesting was this: In a more controlled environment people sometimes have to wait (or at least feel they have to wait) for the next task given to them by the manager. This waiting is not always necessary, but happens anyway. In a more team oriented environment the waiting is more often caused by the work itself, for example when one can only continue testing after some serious bug is fixed. To me this ‘work constrain’ related waiting is a lot easier, because one understands the reason for waiting. The ‘management constrain’ related waiting often seems to be unnecessary and therefore can be more annoying.

At the end of the workshop we, the participants, were asked to answer the question: “What does senior management value?”. For the answers, see the photo below.

The Answers to "What does senior managemet value?"

 

I believe that our (the workshop participants) overall model of senior management is far too simple (or simplistic).

The last keynote was Alan “The Evil Tester” Richardson’s “Helping Testers Add Value to Agile Projects“. His story was full of insights and entertaining and I like how he explained that he doesn’t want to be called a ‘QA’:

Don't call me a QA

 

 

As a final note: I had a lot of fun talking to some of the other contributors to Lisa & Janet’s new book “More Agile Testing“. I wholeheartedly recommend this book — but may be I’m biased, since I’m a contributor. 😉 As I had the book with me, I got some signatures, not only from Janet & Lisa, but also from other contributors I met at the conference.

Thank you everyone at the conference! I’m already looking forward to seeing you again next year.

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d