Tag: Feedback

Reviewing Submissions for the Agile Testing Days

Conferences Feedback Uncategorized 2 Comments

Other reviewers have also blogged about this topic:

The other day a discussion about the review process of the Agile Testing Days developed:

Since I contributed to this thread and was a reviewer for this years programme, here’s my take. It’s my personal view and other reviewers may well have other aspects they focus on.

  1. On the conference page there are blog posts covering how to write a good proposal. I suggest to read them. This blog contains some tips as well:
  2. The conference offers a list of ‘hot topics’ which changes each year. If a proposal fits to this list it’s a plus, since this is a step towards a consistent conference programme.
  3. I prefer proposals that catch my interest, without telling too much about the topic. – If a proposal already expels everything well, time may be better spent in another session.
  4. A well written abstract text, that is easy to understand (for me) is a plus, too. This includes avoiding typos and grammatical mistakes. We all make them, and even the best spell checkers can’t catch all issues. But still, some proposals are really hard to understand due to language problems. Don’t let that get in your way of getting accepted. My tip: Get feedback by a native English speaker before (!) submitting. Many well known testers and speakers offer help and it is worthwhile accepting this help.
  5. Understand what the fields in the proposal form are meant for. Fill them to provided the information that is asked for,
    Avoid repeating the same text in different parts for the form. Change the wording at least a bit. In some cases the title, sub headline, main statement and key learning(s) contained exactly the same or very similar text. To me as the reviewer this is a little bit boring, and doesn’t help me understand what the session is about.
  6. Sometimes, repeating is worthwhile: It helps to understand what is important. Use this tool carefully.

Some questions may guide to writing a good proposal:

  • Will this help the reviewer to give me a high rating?
  • Am I giving enough information to inform a potential attendees decision to come to my session?
  • Am I giving too much information?
  • Is this a good fit for the conference this year?

A leaving personal note: It took me years to get accepted at the Agile Testing Days, even for what was then called a ‘consensus talk’. In the very early years the proposals weren’t very well written, in some years I failed to match the overall conference theme. And then it clicked, I asked for help, gave workshops, a tutorial and, in 2019 even a keynote. For me it was worth the effort.

Good luck and may your proposals be accepted!

Expressing Expectations

Experiment Feedback Learning Pattern Testing No Comments

Long long ago, while preparing experiments for my diploma thesis in physics, my tutor taught me to express my expectation of the outcome of experiments before actually running them. I was to not only to express them in my head, but speak them out loudly, may be even make a note.

This helped a lot, when figuring out where my thinking didn’t match the experimental evidence. There was no denying when my expectation differed from the empirical result. Typically, there were two sources for the differences:

  1. My mental model wasn’t good enough to match the result of an experiment.
  2. The experimental setup wasn’t designed well enough to show the effect I was trying to measure.

I find that this is still working well in software development (both the coding part as well as testing). A related article about this is Peter Naurs seminal paper ‘Programming as Theory Building’.

When doing TDD (test driven development), explicitly expressing the outcome before running a test may not always lead to a surprise. In the very beginning, when a test tries to create an object, without having a class definition, it will cause an error message that is easy to predict.

However, when work has progressed a bit, I regularly run into situation where I expect the next new test to fail in a certain way, but when running the test, the actual error message is a surprise to me. These are situations where learning can happen, by figuring out why the actual behaviour does occur, instead of what I predicted.

Near the end, the surprise is caused differently: I’ll write a new test and expect it to fail. – It doesn’t. Again, this is a good reason to explore why exactly I thought the test would fail.

Particularly in a pair (or ensemble) programming setup, the inability to come up with a new failing test is a sign, that the implementation is good enough … for now.

Recently, I did a programming exercise as part of a technical interview, and expressing my thoughts and expectations while working on the code helped me to find a solution. Additionally, the interviewer didn’t only see what I was typing, but could follow my way of thinking. This relates to Naur’s paper mentioned above: The testing and tested code I wrote isn’t everything there is to my mental model of the given problem or its solution. The way of thinking is important too. This is why I find vocally expressing my expectations & thinking while actually doing the work.

What are your preferred way to actually do the work you’re doing? I’d love to hear about it.

Announcement: Workshop & ebook: “Fast Feedback Using Ruby”

book Feedback Learning Ruby Testing Tools for Testing No Comments

At the “London Tester Gathering Workshops 2015” (also see #LTGWorkshops on Twitter) I offer a workshop “Fast Feedback Loops & Fun with Ruby”. For this, I wanted to give attendees a handout, to make applying the stuff covered easier and it was planned to be a list of brief recipes.
Suffice to say that the handout grew (and it’s entirely possible that this is ‘feature creep’ in action). In fact, it grew to the point that I decided to turn it into an ebook. The book is not done yet, there’s some copy editing to do.

Fast Feedback Using Ruby

In any case: There will be an ebook, and it will be available on LeanPub at https://leanpub.com/fastfeedbackusingruby/. If you’re interested, please leave a note on the book’s pages.

London Tester Gathering Workshops 2015: “Fast Feedback Loops & Fun with Ruby”

Feedback Learning Testing Uncategorized 2 Comments

My workshop at the London Tester Gathering Workshops 2015 is announced now! They’re offering an early bird rate until the 18th February, by the way. Find the abstract on the conference page or just read ahead. 🙂

Fast Feedback Loops & Fun with Ruby

Ruby is “a Programmer’s best friend”. Let’s use Ruby to get feedback – including getting feedback automatically – when working on projects. Whether it’s about transforming source code into test results (a.k.a. running automated tests) or generating image files from raw data, Ruby can be used to automate these tasks. Furthermore, it can also be used to automate actually running these tasks, e.g. upon saving a file to disk. Does that sound like a good idea? This session is for you.

I regularly bump into tasks that are…

  1. tedious, if done manually
  2. not done often enough, unless automated
  3. still not done often enough, unless running them is automated, too.

In the workshop we’ll combine some Ruby tools to remedy this situation. In particular the workshop will cover:

  1. Writing a simple Ruby program that does something useful, e.g. turn a markdown file into HTML
  2. Wrapping that in a Rake task
  3. Automate running the task

Knowing how to do this is useful, not only for projects using Ruby as their primary language, but can be handy in all projects.

What is expected:

  • Some Ruby knowledge; you don’t have to be an expert or anything like that.
  • A notebook (or tablet) with an internet connection & Ruby installed.
    Cool if you’re using RVM, rbenv, chruby or similar
  • Mac OS X, BSD; Linux & friends are fine, Windows may be a bit problematic.

 

London Tester Gathering Workshops 2015: Early News

Feedback Learning Testing Tools for Testing No Comments

There’s news about the London Tester Gathering Workshops 2015: I’ll offer one of the workshops!

I’m sure we’ll have a couple of exiting days talking about software testing. And not only talking but also some hands-on stuff using Ruby for fun and (fast) feedback.

Before I publish more information about my workshop, I’d like it to…

look right

Stay tuned!

Slow Feedback Cycles

Feedback Learning 6 Comments

In his keynote ‘Fast Feedback Teams’ Ola Ellnestam (at the Agile Testing Days 2012) talked about the importance of fast feedback and how to shorten the cycle durations. To me, there seems to be a trend in focussing on getting feedback in shorter and shorter cycles.

While I completely agree that in many cases it takes too long to notice the effect of a change made earlier, I am also a little bit worried that we (as software developing teams and companies) might forget about  slow feedback cycles. Let me explain.

Feedback loops

Let’s look at aspects of feedback loops. There is an actor to change the system operation as well as a sensor that reads some information. In order to actually be a feedback loop, the sensor is driving the actor.

Note that most systems allow data to be read at any time and (essentially) any frequency. However systems usually also do not immediately respond to changed input. Here’s an example: You could read a thermometer in your room as often as you like. And you can also turn the control of the heater up or down pretty often and yet the room temperature will not change immediately.

Usually there is no point in acting a whole lot faster than the system can react. If it takes ½ an hour for the room temperature to adapt to a newly set value, reading the thermometer and changing the control every minute doesn’t make much sense.

Some waste and some risk

Now, with the focus on short time scales and a high frequency of the measurements (no matter wether they are qualitative or quantitative), I can imagine two undesirable outcomes:

  1. In a situation where the system reacts slowly to changing parameters, measuring often is waste. This is because the system couldn’t possibly yield another outcome (yet).
  2. If we only measure with a rather coarse-grained way (e.g. only the values red, yellow, green), we might miss a slow trend. (I guess this is the reason we often suddenly must buy winter tires, even though we clearly noticed that the temperatures decreased over the past weeks and we’re wearing our long sleeved shirts and anoraks too.)

That said, if the system reacts fast on a change and we can get the feedback quickly, it’s very likely a good idea to actually get that feedback. A good example for this case: Having fast unit tests in programming. 🙂

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d