Category: Uncategorized

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!

Agile Testing Days 2021 – Part 2

If you haven’t read it yet, you may like to start with the first part of my Agile Testing Days 2021 summary.

Wednesday

I started Wednesday with a Lean Coffee. At the Agile Testing Days this is traditionally facilitated by Janet Gregory and Lisa Crispin.

We discussed a good number of topics, such as how to get folks to try new ways, ways to practice testing and the role of testing/testers. I like this way of quickly covering a broad field of topics, to give people input to work with. I recommend tying this format, if you haven’t done so yet.

Jutta Eckstein‘s keynote “Agile Comes with a Responsibility for Sustainability” covered the three main parts of sustainability:

  1. People, the social equity bottom line
  2. Planet, the environmental bottom line
  3. Profit, the economic bottom line

See for example the Wikipedia article about the ‘Triple Botton Line’ for more details. I find that these aspects are all incredibly important and also believe that we, the community of software people, have a shared responsibility to help achieve improvements in all three areas.

The second keynote on Wednesday was João Proença‘s “Limitless within our boundaries”. He explained nicely how limiting options can improve creative work. His example were his Band that got completely stuck, when they experienced the possibilities of a music studio for the first time. It’s the same in most other contexts, including software development. I very relaxed presentation style and body language. I found it super nice that he reminded me, that I recommended submitting a session to the Agile Testing Days – and I am really, really glad I did.

The session “Resistance is futile” by Anne Colder & Jantien van der Meer, was about how to facilitate changing behaviour. The session was Star Trek themed and I am luck I survived in my red shirt. 🙂 Details about the model of “The Rider, the elephant and the path” are, for example, available at https://www.creativehuddle.co.uk/post/the-elephant-and-the-rider. I like the way they explained the model as well as the exercises to illustrate how it can be used.

For me Bruce Hughes‘ keynote “How to be an Ally to Non-binary Folk in Tech” was next. It was brilliant, hilarious, sad and helpful. The standing ovations she received were absolutely well deserved. The blog post appache attack helicopter wrote at https://undevelopedbruce.com/2020/07/06/non-binary-in-tech/ explains what was covered in xer keynote. I recommend reading it. To her ‘appache attack helicopter’ is an acceptable pronouns BTW. See: https://undevelopedbruce.com/about-me/ (read that as well, I may help further understanding the complexities of existence). Lisi Hocke tweeted a great summary of this keynote:

The last session I attended as Søren Wassard‘s “Digesting Poets Society”. A very nice, relaxing and emotional bonus session about another way to get creative: Poems. We mostly heard English poems, but also one from a Welsh author, recited in Welsh by a Welsh (and no other than Bruce).

Part 3 of the series is available now, too.

Agile Testing Days 2021 – Part 1

After a two year break, I could finally attend the Agile Testing Days in person. I was a bit worried about having to deal with the corona virus floating around and infection counts increasing significantly in Germany. However, the organisers handled this exceptionally well: Only vaccinated or recovered people were allowed to attend, every attendee received two test sets for self-testing and the certificates to prove vaccination/recovery were checked twice: During check-in at the hotel and the conference. During the conference it became obvious that many (likely most?) people tested every day. For me this meant I felt a lot better!

Additionally, they offered ‘colour coded’ masks: A blue masks indicated “I’m OK with getting near people, even hugging” and black ones which meant “I prefer some distance, please”. I took a black one and was pleased that people respected this. Thank you everyone!

What follows is a summary of some sessions and events.

Monday

Originally I had planned to give my workshop “Get a Lot Out of This Conference” (a teaser video is available on Vimeo), however it turned out that most first time attendees weren’t at the conference on Monday already, some would even only arrive on Wednesday. Since this workshop makes most sense when done before the conference, we decided to cancel it. And that’s OK since my ‘plan B’ was to attend the session to build a Tiny House. – Sadly this session also had to be cancelled, for reasons outside the control of any one at the conference. Thankfully the organisers allowed us non-builders to join on of the other sessions of this day and I could participate in “A Path to Holistic Testing” presented by Lisa Crispin and Janet Gregory. Alex Schladebeck also joined my table. It was super interesting to see how being a CEO can change focus, when it comes to sign-up forms for courses (this was the example we used in the exercises). Hint: The GDPA plays an important role.

I learned a lot in this super entertaining tutorial. This will be very useful in helping my team.

Tuesday

A session I looked forward to a lot was Maaike Brinkhof‘s “The Struggle with Learning How to Code”. I enjoyed the story telling about her experiences in learning to code immensely. She also offered great tips for how to prevent the barriers she ran into.

The second talk I attended was Alex Schladebeck who presented “Unit Testing and TDD from the tester perspective”. It was a great presentation and I am already looking forward to getting the slides which contain links to resources and further information.

Some insights of Alex' talk: TDD can be seen as exploratory programming.

The ‘traditional’ highlight of this day is the costume party including dinner and the award ceremony for the MIATPP (Most Influential Agile Testing Professional Person) award. This year I had the honour to be asked to announce the winner. As every year, first the dinner is served and then the award. I had a hard time keeping a straight face when the (future) winner asked if they may join my table. Introducing the winner and keeping the tension up to the very last moment was great fun, especially since apparently no-one had any clue who might be the MIATPP this year.

Again congratulations, Raj Subrameyer, MIATPP Award Winner of 2021!

Continue reading the second part at https://seasidetesting.com/2021/11/22/agile-testing-days-2021-part-2/

Contributing to Open Source – Getting Started

A sign in LegoLand saying "Adventure Land"

Recently, I started to contribute more to open source projects I use and like. When I started to contribute at all, I did so, with the most obvious thing for me: Bug reports. 🙂 This can be particularly useful, since the bug reports that I write for my projects, stay behind closed doors. – Like it or not, companies producing commercial software very often don’t fancy public bug reports. That’s a long story for another time…

Here are some tips:

  • Start small. Probably smaller than that.
    You can start on documentation. ➙ It can be unclear or contain typos.
    My smallest contribution so far, was fixing a typo in the Cucumber documentation.
    The steps to deliver it were large, compared to the fix itself:
    • Fork a repository
    • Create a branch on the fork
    • Fix the typo
    • Create a pull request
    • Get it accepted
      This seems like a lot, just to fix a typo.
      However, I think the learning experience was worth it.
  • Learn about the two most used models used in open source projects, the “Fork and Pull Model” and the “Shared Repository Model”.
    Both are explained in the GitHub docs about “collaborative development models“.
  • Check out Marko Denic on Twitter. He wrote “Make Your First Open Source Contribution” which explains to to get started on GitHub.
    You can contribute to his site https://tech-blogs.dev by adding you own blog, if you have one. The project is hosted on GitHub.
  • Start in a friendly & helpful community
    I find this really important: When you have a safe place to ask all the question you may have, and can expect a friendly answer, that will help actually asking those questions. It certainly helped me, asking about which development model is used, how big or small a pull request should be, etc.
  • Create your own project and make it open source
    Again: You can start really small. My smallest GitHub repository is probably https://github.com/s2k/seasidetestings-iterm-colours. It’s just only file that can be used as a colour preset in iTerm2 and some documentation how to load the file in iTerm.
  • If you find that something can be improved or isn’t working as expected, provide a bug report. These are important contributions to any software project: If the people writing the software don’t know that something’s wrong with it, they can’t fix it.
    For example I wrote https://github.com/fakefs/fakefs/issues/224, when I noticed that this Rubygem didn’t worked the way I expected.
    Since I knew how to write the RSpec to check this, I did – and it probably helped to get it fixed.

If you’re looking for much more information about how contributing to open source this book may be for you: “Forge Your Future with Open Source” by VM (Vicky) Brasseur.

Conveniently start a JavaScript shell (jsc) on macOS

For one of my projects I wanted an easy way to try JavaScript on a command line (similar to pry or irb in Ruby). Here’s how I found out where the program is located and how to set up my Mac to conveniently start it.

1. Find out where jsc is located on the machine:

$ find / -name jsc -type f 2>/dev/null
/System/iOSSupport/…/JavaScriptCore.framework/Versions/A/Helpers/jsc
/System/…/JavaScriptCore.framework/Versions/A/Helpers/jsc
/System/Volumes/Data/…/JavaScriptCore.framework/Versions/A/Helpers/jsc
/System/Volumes/Data/…/JavaScriptCore.framework/Versions/A/Helpers/jsc    

Searching from the root folder may be a bit excessive, though. You may consider a more limited search.

2. Look into the ‘system frameworks’ for versions

The path /System/Library/Frameworks/… was where I went to look what else is inside:

$ ll /System/Library/Frameworks/JavaScriptCore.framework/Versions
total 0
drwxr-xr-x  4 root  wheel  128 Jan  1  2020 .
drwxr-xr-x  4 root  wheel  128 Jan  1  2020 ..
drwxr-xr-x  5 root  wheel  160 Jan  1  2020 A
lrwxr-xr-x  1 root  wheel    1 Jan  1  2020 Current -> A

Aha, there’s a link named Current that (currently) points to A. I used this link in the next step. This way I can still use the same link, even if (when!) an OS update causes the file that’s linked to changes.

3. Link to the current version

I set a link somewhere in within $PATH. I have a bin folder in my home directory, so it put the link there:

ln -s /System/Library/Frameworks/JavaScriptCore.framework/Versions/Current/Helpers/jsc ~/bin/jsc

3. Set a variable ‘console’ for output

To output things, use this to define a variable console in a running JavaScript shell.

var console = {log : debug};

While jsc provides a print function, I find it convenient to stick to the more idiomatic console.log.

4. Use ‘jsc’

$ jsc
>>> var console = {log : debug};
undefined
>>> console.log(function(){})
--> function (){}
undefined
>>> 1 + 1
2 

Navigation

%d bloggers like this: