Author: Stephan

About Stephan

I'm a self-employed software tester. I test and write software, listen to music and go hiking — sometimes simultaneously. Prior to this was a physicist and oceanographer, among other things.

Reviewing Submissions for the Agile Testing Days

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!

Two Ways of Solo Programming

Occasionally, especially in times between (paid) projects, I program solo. This morning, I realised that I operate in two ‘modes’ which slightly differ in the way I leave the project I’m working on in the evenings.

One way of working is when I program along while working through a book. Currently, I’m reading ‘Agile Web Development with Rails 7‘ (by Sam Ruby & Dave Thomas). I very much leave the ‘Depot’ app (the example application used in the book) with a completed section and passing tests. The Part of the next section is a fresh starting point in the following morning.

The other way is when I’m progressing in a project, i.e. a library or tool, I work on. In these cases, I prefer to leave a (read: one) failing test in the evening, so it’s easy to remember what I was planning to do in the morning: To fix/implement the code to make the tests pass. Note though, that I do not commit & push this failing tests to version control.

This is neither a new nor my idea. Nick Holden wrote about in 2018 already, in his blog post ‘Try ending today with a failing test for a great start tomorrow‘.

Have you noticed differences in developing software (whether it’s the coding, testing, UX, or any other aspect of it), between times of working alone versus working in a team? What are they? I would be seriously interested in hearing about this.

An Odd Behaviour When Creating A Rails App

I’m currently looking into Rails 7 and found an odd behaviour when creating a new Rails app. Before creating a Rails app a few other things need to be in place, most notably Ruby, and _a_ database. My set up is this:

Ruby
3.1.0
Rails
7.0.2
rbenv
1.2.0
SQLite3
3.37.0
PostgreSQL
14.2

The simplest way to create a new Rails app is this:

rails new app_name

You can also specify various options, including, for example --css=tailwind, to use Tailwind for CSS. Since that’s what is used in a book I’m reading (‘Agile Web Development with Rails 7’ by Sam Ruby & Dave Thomas), I ran this:

rails new app_name --css=tailwind

Now I got an exception logged in the output, while also the exit code of the command was 0. Interesting. Here’s the command and the output (lots of output omitted for brevity):

rails new a_new_app --css=tailwind
      create
  …
      create  Gemfile
         run  git init from "."
Initialized empty Git repository in /Users/stephan/dev/tmp/a_new_app/.git/
      create  app
…
      create  config/master.key
      append  .gitignore
      create  config/boot.rb
…
      remove  config/initializers/new_framework_defaults_7_0.rb
         run  bundle install
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies....
Using rake 13.0.6
Using minitest 5.15.0

…
Using rails 7.0.2
Bundle complete! 16 Gemfile dependencies, 75 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
         run  bundle binstubs bundler
       rails  importmap:install
…
Add Tailwindcss include tags and container element in application layout
      insert  app/views/layouts/application.html.erb
      insert  app/views/layouts/application.html.erb
      insert  app/views/layouts/application.html.erb
…
Add default Procfile.dev
      create  Procfile.dev
Ensure foreman is installed
         run  gem install foreman from "."
Successfully installed foreman-0.87.2
/Users/stephan/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0/gems/yard-0.9.27/lib/yard/rubygems/hook.rb:88:in `require': cannot load such file -- yard (LoadError)
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:88:in `load_yard'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:163:in `setup'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:152:in `generate'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:63:in `block in generation_hook'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:52:in `each'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:52:in `generation_hook'
  from ….rbenv/…/ruby/…/request_set.rb:311:in `block in install_hooks'
  from ….rbenv/…/ruby/…/request_set.rb:310:in `each'
  from ….rbenv/…/ruby/…/request_set.rb:310:in `install_hooks'
  from ….rbenv/…/ruby/…/request_set.rb:209:in `install'
  from ….rbenv/…/ruby/…/commands/install_command.rb:210:in `install_gem'
  from ….rbenv/…/ruby/…/commands/install_command.rb:226:in `block in install_gems'
  from ….rbenv/…/ruby/…/commands/install_command.rb:219:in `each'
  from ….rbenv/…/ruby/…/commands/install_command.rb:219:in `install_gems'
  from ….rbenv/…/ruby/…/commands/install_command.rb:167:in `execute'
  from ….rbenv/…/ruby/…/command.rb:323:in `invoke_with_build_args'
  from ….rbenv/…/ruby/…/command_manager.rb:180:in `process_args'
  from ….rbenv/…/ruby/…/command_manager.rb:149:in `run'
  from ….rbenv/…/ruby/…/gem_runner.rb:53:in `run'
  from ….rbenv/versions/3.1.0/bin/gem:13:in `<main>'
Add bin/dev to start foreman
      create  bin/dev
Compile initial Tailwind build
         run  rails tailwindcss:build from "."
+ /Users/stephan/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0/gems/tailwindcss-rails-2.0.5-x86_64-darwin/exe/x86_64-darwin/tailwindcss -i /Users/stephan/dev/tmp/a_new_app/app/assets/stylesheets/application.tailwind.css -o /Users/stephan/dev/tmp/a_new_app/app/assets/builds/tailwind.css -c /Users/stephan/dev/tmp/a_new_app/config/tailwind.config.js

Done in 228ms.

This is … interesting, since yard is found, when listing matching gems:

> gem list yard

*** LOCAL GEMS ***

yard (0.9.27)

However, the command that is running at this time is (apparently) executed in the context of Bundler. Since yard isn’t listed in the Gemfile, Bundler won’t find or use it:

bundle info yard
Could not find gem 'yard'.

After uninstalling yard, creating a new Rails app works fine and doesn’t log an exception.

While this solves the issue of getting the exception, it was still unclear why this happened in the first place.

Now, what is yard?

YARD is a documentation generation tool for the Ruby programming language.

https://github.com/lsegal/yard

Aha, looking into my .gemrc (which is used to configure Rubygems), I found these two lines (Yes, I like to have the documentation generated 🙂):

install: --rdoc --ri --document=yri
update: --rdoc --ri --document=yri

After removing the --document=yri, creating a new Rails app worked fine even with yard being installed.

I still don’t completely understand, why this is an issue when specifying a CSS processor, but not otherwise. This may be topic for another post.
If you have an idea about why this happens, please let me know.

Expressing Expectations

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.

Agile Testing Days 2021 – Part 3

If you haven’t you might be interested to read the previous part of this series as well.

This day impressed me most by the three key notes and discussing the effects of corona and working from home with Anne Colder.

Thursday

The first keynote of the day was Ard Kramer’s “How to nudge your way through agile testing”. Ard presented six ways to nudge people to make a decision in a certain way – probably a way that we want them to go. In a very consistent way he made the distinction between doing something (the nudging) and the ethics of doing it.

It’s so important to aware of these techniques, because then we can more consciously decide whether or not to follow the nudging.

These are the six kinds of nudging he explained:

  • Default options
  • Commitment through consistency
  • Anchoring
  • Decoy effect
  • Zeigarnik effect
  • Activate unconscious behaviour

The name Zeigarnik effect was new to me, although I read about the way it works somewhere on the net. Basically it states that one can remember an activity that has been interrupted (not not completed) more easily at a later point in time.

The Tester’s Learning Toolkit” was the second keynote, presented by Vera Baum. Supported by incredibly great graphics Vera explained the various levels of experience people may have.

  1. Novice
  2. Apprentice
  3. Crafter
  4. Expert

She explained how we can develop from level to level, and why it may not be the best approach to let experts teach novices.

The last keynote of the day – and the conference – was Vernon Richards‘ “What does the ‘Coach’ in ‘Quality Coach’ mean?”. He introduced 6 styles of leadership and how they can be applied in the context of software quality. I loved his way of giving examples his experiences in applying them.

With this highly interesting and super entertaining keynote ended the official program of the Agile Testing Days 2021.

In the evening, I discussed the effects of having to work from home with Anne Colder, leading to another contribution for the ebook “Software People … Work From Home“. Stay tuned. 🙂

This ended a truly brilliant experience of the Agile Testing Days. It was so great to finally meet real testers in real live, discuss software related topics during breakfast, lunch and dinner… as well as in between.

Thank you! Thank you to everyone I spoke to, especially the organisers who ran an incredible conference!

Navigation

%d bloggers like this: