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.

Attending a Code Retreat

Learning 1 Comment

The “Softwerkskammer” regional group of Düsseldorf, Germany organised its first Code Retreat this weekend (1. Sept. 2012), which I attended. The facilitator, Patrick Cornelißen (of orchit), has posted a summary of the Code Retreat, so I won’t repeat him, except for stating that the task was “Conway’s Game of Life” and we wrote code in 6 time slots (45 minutes each) each one followed by a 15 minute retrospective. Here are my observations and notes:

About the programming and pairing

First of all I found it super exciting to get pairing with programmers. Although not every one else was a programmer, I was the only tester attending and I found pairing up with programmers very exciting (Would my coding skills be sufficient?), productive and fascinating.

One pairing partner made me write the tests in much smaller steps, than I would have ever done. After struggling with the approach of implementing the desired functionality in the test (without defining any method or class), I finally realised just how small steps are possible. Those were really tiny steps. It occurred to me rather late in the slot, that what we created was a rather functional way to solve the problem. In a later slot I asked Sergey Shishkin to pair program using Clojure.

One (kind of) surprising constraint we were offered, was to avoid if-then-else and case constructs by using polymorphic dispatch. Apparently this approach was a challenge for nearly every one, see Partick’s tweet about it:

Verwunderte Gesichter bei der Vorstellung des “No-If” Constraints 🙂 #coderetreat

General remarks, tips and an observation

  1. When pair programming using a notebook, especially a relatively small notebook, I recommend using an external keyboard. If you’re limited to the internal keyboard either the ‘driver’ can’t easily type on the keyboard or the ‘co-pilot’ can’t easily watch what’s happening on the screen.
  2. If you want to learn more about your favourite programming language, editor and/or IDE, attend a Code Retreat.
  3. Pairing for the first time and/or pairing with people you didn’t meet before will give you new ways of thinking and programming.
  4. I was the only tester and the only one who used fork and knife at lunch time when eating pizza. 🙂 However, I used my hands like everyone else in my second serving. 😉

I very much enjoyed the day. Thank you to everyone involved!

A Week of “Rapid Testing Intensive”

Learning Testing 2 Comments

I signed up for the Rapid Testing Intensive event starting next week and am looking forward to a week of learning new things about software testing.

I’ll attend online and if anyone would like to talk about it or team up with me, leave me a note in the comments below or contact me via @S_2K on Twitter. In case you like to follow the tweets about the event, the Twitter hash tag is #RTI1.

Edit: Since that hash tag is already in use, make that #RTI2012.

An Anti Pattern when using Continuous Integration & Automated Tests

Anti-Pattern Testing 2 Comments

The Setting

Once in a while I meet teams who are using a Continuous Integration (CI) system, for their builds and executing the unit tests (yes, there are still teams using a CI for building the software, but not executing automated tests [or checks]). So this is the setting:

  • There is a CI system.
  • There may be unit tests being automatically executed either after check ins into the version control system or at least nightly.
  • In some cases there are failing tests (or checks).
  • Broken builds are displayed on the start page of the CI system in the (intra) net, but not ‘radiated’ so everyone can and will see them.
In this post I focus especially on the cases where the last two points are true.

The Observation

I think this is problematic at least, likely also dangerous, because when there are failing tests and/or broken builds  for some time the team will very likely develop features base on broken software. Getting back to a clean and working system gets harder and harder as time goes on.

The Aftermath

A change in the behavior of the automated check can go unnoticed: Since no one watches the first test fail, it’s unlikely that someone will realize that other checks start failing, too. Furthermore new features might depend on the brokenness somewhere else.

Now What?

Do not live with ‘broken windows‘ & apply a ‘Stop the Line‘ (or check out what Google says about Stop the Line) policy: As soon (read: right after it’s discovered) as a problem becomes known, solve it and then continue with other work. Like everything else, this is supposed to be done by the whole team. When everyone helps, things get solved quickly.

A leaving thought

In my opinion, introducing a Continuous Integration System and then ignoring the results is certainly a major anti pattern, that can do more harm than good for the development process. The effort of setting it up and keep running and then ignoring the information it provides is a form of waste. Is it possible that in such a case you’re better off not having a CI system? Honestly, I’m not sure.

Note however, that I am in strong favour of…

  • having a CI system,
  • actually using it to build the systems and execute automated checks against it,
  • radiating the results to the team and
  • acting upon those results.

Ways & Places to Learn: Hackdays

Uncategorized No Comments

There will be a hack day tomorrow, just before the Euruko 2012 and I think events like this are a great opportunity to learn no matter whether you’re a programmer, tester or (visual) designer. I find it fascinating to see how other people approach tasks, be it programming, testing or something unrelated to software development.

Here are a few ideas I have, about what to do…

  • Work on something that bugs (sic) me for a while now… could be a Sinatra or Rails app — or maybe something entirely different.
  • Offer a testers point of view to whoever asks about it. Just ask me (@S_2K on Twitter).
  • Work on some entirely new (to me) topic.

What would your choice be? Do you make plans about events like this? What are your expectations?

Sources of Learning

Learning Testing 1 Comment

Over at Jeroen Mengerink’s blog (and there’s the 1st of the sources to learn from) he talks about learning (and the lack thereof) of people in testing. Given the topic list of this blog “On Testing, Patterns and Learning”, this topic is very interesting to me, too.

I recently attended a Scrum Training and one of the group exercises was to suggest ways to implement certain practices we were given. One of the topics was “focus on both, technical excellence and good design, fosters agility” (my translation, the training was held in German). I started filling the spot for possible immediate actions on the board: Conferences, user group meetings, books, blogs, podcasts… at which point a colleague stopped me, so others could add to it. However they didn’t.

So, if you’re looking for information about testing here are some recommendations I have, for today let’s cover the letter ‘B’ 😉

Jeroen also mentioned conferences and especially a presentation by Alan Richardson (@EvilTester on Twitter): Please go to Jeroen’s post and read it, then watch Alan’s presentation, both are really recommended stuff.

For now, I’d love to hear what book(s) and/or blog(s) you recommend that helped you learning about testing or improving your testing.

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d bloggers like this: