Tag: Conference

Euruko 2022 in Helsinki

Conferences Ruby Uncategorized No Comments
The Euruko 2022 master of ceremony Antti on the stage

After a 10 year break I made it to an in-person Ruby conference again: Euruko 2022 in Helsinki. For travelling, I chose the Finnlines ferry from Travemünde to Helsinki. That’s travelling without a hurry, since each trip takes 30 hours. At the time of this writing, I’m sitting in the ship’s café looking out over the Baltic Sea into the sunshine, just south of Oland and slowly approaching and then passing Bornholm. There are worse places to write a post. 😁

A sunrise over the Baltic Sea: Near the horizon the sky is free of clouds, above is a thin layer of clouds. below the sea is watery and looks cold.
Sunrise over the Baltic Sea
Photo taken onboard the Finnmaid, while approaching the port of Vuosaari, Finland

Thankfully there’s a gym, a sauna (if a Finish line after all) and lots of nice places to take a seat watch the waves pass by. I even met the fist few other attendees on the ferry already!

Even before reaching Helsinki, Leo Kiisi one of the organisers, sent an invitation to join the sauna – including access to the open water. We met in the evening and had a great time as several attendees and a speaker joined. It was a fantastic way the end the first travel day, relaxing, refreshing and overall remarkable.

The opening Keynote was recorded and presented by Matz, and he busted several myths and claims that were made about Ruby. What surprised me most, is his take on type systems: He explained that (at least some) type systems are Turing compete. which means that the type system alone is already complex enough to encode any algorithm or program. 🤯 — Whether that’s desirable or not is another question. 😉

Wiktoria Dalach told us about how security aspects can be handled, by categorising the infinite space of possible issues into only thee categories:

  1. Confidentiality: How to keep secrets secret
  2. Integrity: How to be sure that we get what we expect
  3. Availability: Ability to access our information always

What we’d need do do ourselves: Select the aspects from these categories that are most important to us — and them work on them.

Adarsh Pandit told us about ‘The Technical and Organizational Infrastructure of the Ruby Community’ – and drew parallels to the transportation infrastructure differences he found between California (where he lives) and Finland. I understood that the difference is mainly that in the US transportation seems to optimise the number of cars the system can handle, while in Finland it’s more the number of people and how they can get from A to B. We also learned how individuals (and companies) can support the Ruby community:

  • Contributing to the language implementation(s) and its libraries: The code is still being optimised, bugs a fixed etc. All think work needs to be done by someone. Thank someone could be you.
  • Support Ruby Central/Ruby Together with money: In the end services such as Rubygems (and its website & repositories), Bundler etc. require hardware to run on and that costs money. These projects are also improved and that involves investing time and/or money as well.
    BTW, you can support RubyTogether at https://rubytogether.org.

An amusing point Adarsh made: He said that Finland seems to have the happiest people and at the same time the angriest music. (Note: Finland has the highest number of mates rock bands per capita worldwide).

Vesa Vänskä explained how to move ‘From massive pull requests to trunk-based development with Ruby’ – and reminded us of Dr. Eliyahu Goldratt’s observation:

I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory.

Dr. Eliyahu Goldratt

Be sure to check out the talks on the conference site; I believe, at least some talks were recorded and will be available in the next few days. As always, I thoroughly enjoyed the conference days, meeting many new people, the great food at the lovely location.

I’m already looking forward to the next Ruby conference I’ll attend. It may be the next EURUKO and the community voted for Vilnius, Lithuania.

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 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.

The Agile Testing Days 2014: Conference Day 1

Learning Testing 1 Comment

If you’ve read my previous post about the tutorial day, you may wonder why there’s another ‘Day 1’. — Well, the official conference program mentions the 11th of November as the 1st day, so I stick with that.

For me the day started with a Lean Coffee, a format where people meet, gather topics everyone can bring, vote on these topics and then discuss the topics based on that voting (see the link to the site for more information). I like this format, because it allows to get to introduce a topic and discuss it without spending much time. That way one can see whether at least some other people are interested in a particular topic.

Afterwards, Lisa Crispin & Janet Gregory gave the inspiring first keynote, titled “WELCOME TO THE FUTURE – Preparing For Your Agile Testing Journeys”. They presented their view of how software testing may be in the future and also shared the slides. I liked the Star Trek theme presentation, which also nicely matched the topic.

Next, I attended George Dinwiddie‘s talk “A Poet’s Guide To Automated Testing”. He demonstrated how important a good choice of words is, when writing automated tests. By questioning every single word in a rather typical test, he showed how the tests can be improved. For example a typical test often reads: “When I log in to the system…”.

Who is the ‘I’ mentioned in that line? A customer? A system administrator? The ‘I’ who wrote the test, whatever his or her role was? — After a while, sometimes a rather short while, this knowledge gets lost. So it’s usually better to make this knowledge explicit in the automated test.

The following presentation by Carlos Sanchez was titled “Continuous Delivery, the Next Frontier”. I found it very interesting to see him talking about Docker a lot. Also interesting was so see that, while many people know about Docker and also use it, not many people do use it in a production environment, at least none of the people attending the talk.

Also he provided a funny explanation about where Docker works:

In the the early afternoon I attended Jeff “Cheezy” Morgan‘s workshop “Patterns of Automation”. There was an enormous amount of interest in the workshop and the room filled up quickly. He gave a good number of patterns and even (successfully!) live coded his examples. Super interesting, entertaining and funny!

At the end of the conference part of the day Bob “The Flowchain Sensei” Marshall gave his keynote “The Antimatter Principle” (explained on his blog), a very inspiring, thought-provoking and slideless presentation.

The conference day ended with the now traditional Halloween and costume party, excellent food, super interesting conversations and Matt Heusser receiving the “Most Influential Agile Testing Professional Person” award. Congratulations!

Agile Testing Days 2012 — YAS (Yet Another Summary)

Feedback Learning Testing No Comments

Just like the years before I enjoyed the Agile Testing Days a lot. A fun theme throughout many of the talks were… unicorns and I think Gojko Adzic started it. This affected my brain so much, I said ‘Look, a unicorn!’ to my dog, when I took him for a walk for the first time after I came back from the conference. Actually, the animal crossing our path was a squirrel.

Here’s a short summary of my favourite parts. In order to stay in sync. with the printed & online conference program I’ll start counting the conference days at 0.

Day 0 – Tutorial “Software Testing Reloaded” with Matt Heusser & Pete Walen

Just as the full title “Software Testing Reloaded – So you wanna actually DO something? We’ve got just the workshop for you. Now with even less PowerPoint!” promised, there was only very little PowerPoint and a whole lot of testing & questioning.

I especially liked the way Pete & Matt presented the examples & exercises as well as the reasoning behind them.

Electronic Dice
Electronic Dice

There were a lot of games and actual testing. All was very hands on, well explained and debriefed at the end. To give just one example: We tested electronic dice, in order to give an estimation about how long testing would take and to come up with a recommendation whether these dice were ready to be used.

Questions like “Can we ship it now?”, “Is there a pattern/problem there?” and “What actually are the requirements?” were covered.

I also won a price, so my point of view might be biased. 😉

How to Reduce the Cost of Software Testing

Day 1

  • Get them in(volved) by Arie van Bennekum
    I found it super interesting to listen to one of the creators of the Agile Manifesto, especially since he pointed out that many of the principles and values have been around before the manifesto was written.
  • Myths About Agile Testing, De-Bunked by Janet Gregory & Lisa Crispin
    Lisa & Janet debunked myths as ‘Testing is dead’, ‘Testers must be able to code’ and ‘Agile = Faster’. Excellent story and fun presentation.
  • Consensus Talks – 7 10-minute-talks (including mine)
    The format of 10-minute talks, all back-to-back and no break included was the one I missed in the previous Agile Testing Days. This way a whole lot of ground is covered in a short time and it’s a great opportunity to explore new techniques in presenting without doing too much harm and/or presenting on conferences for the first time.
  • Self Coaching by Lasse Koskela
    Lasse explained how to coach yourself. After explaining how the human brain works he talked about how to step ‘out of the box’ (your personal point of view) in order to better understand what others actually say and to stay honest to yourself at the same time. Deep knowledge, very well explained indeed.
  • The MIATPP Award Night 2012
    Lisa Crispin won the MIATPP Award. Congratulations!

Day 2

  • Test Lab by James Lyndsay & Bart Knaack
    This year I went to the “Test Lab” and tested a small LEGO Mindstorm robot, that could move around on a coloured sheet of paper and react, depending which colour its camera would detect. The task: Find out what the specification of the robot is and find defects in its implementation.
    Very interesting: We had to come up with a hypothesis of how the robot was supposed to work as well as finding defects. I really enjoyed the way Bart & James gave feedback and asked the right questions.
  • “Reinventing software quality” – Gojko Adzic

    Breaking News: Unicorns Exist

    Gojko made the point that in agile testing we might (still) not focus on the right thing: To build the right software. Instead we concentrate on finding bugs and building the software in the right way. He illustrated this with one of his books:  He found a defect and then spent a while searching & listing more problems and ended up with a good number of them, definitely enough to make you worry about the quality of the book. However, the publisher explained that essentially all reviews were very positive! So: When people keep paying for your product or service, worrying about defects may not be that important.

Day 3

  • “Fast Feedback Teams” – Ola Ellnestam
    explained the importance and value of fast feedback. And he’s right: In many projects feedback could be gathered a lot earlier and be used to improve what features are built (as well as how they’re built). Other talks at least touched this topic as well. And while I wholeheartedly agree about this, I’m also a bit worried that we (as software creators) might forget about (or even ignore) slow changing aspects (for more about this see my previous post ‘Slow Feedback Cycles‘).
  • “Exceptions, Assumptions and Ambiguity: Finding the truth behind the Story” by David Evans

    UK Explained

    David explained how natural language is ambiguous, unclear and sometimes hard to understand. His examples included part of Jabberwocky (in several natural languages), music lyrics and last but not least programming. Also, I like his short introduction of the Cotswolds.

  • “It’s the Economy, Stupid! Learn the fundamentals about the one and only argument which will drag your management into agile practices” by Lucius Bobikiewicz
    Lucius talked about economic reasons of letting teams focus on 1 (one!) project/product, as opposed to working on multiple projects/products at the same time. It didn’t surprise me much, that letting teams finish one thing and then progress with the next is economically favourable. But  I was very surprised how much of a difference it made in the example he presented. These are the main advantages of the 1-project-only team Lucius presented:

    1. The time between the 1st project start and the first paid project (usually at the end of the project) is much smaller, meaning that significantly less money is needed to fund the upfront costs.
    2. Given the limited period of time in which a software can be sold, the product can likely be launched at the optimal time, whereas multi-product-teams may enter the market later and therefore always lag in selling.
    3. Since the overhead of context switching is minimised, the team can work on more projects/products per time unit. This advantage depends on the amount of time needed per context switch and the time the projects take .

    The economic point of view Lucius presented was a surprising and welcome detour form the other sessions which were much more focused about technology and/or ‘doing the right thing and doing it right’.

Every morning of the conference days 1-3 Lisa Crispin organised a Lean Coffee in one of the hotel bars. In small groups we discussed topics people were interested in. In order to cover some topics we limited the time for each topic to an initial 8 minutes and then added another 4 minutes depending on a quick vote. I find this is a very fun way to find and discuss topics. Thank you Lisa for organising them!

As a leaving thought: The chair persons were given (foldable) chairs as a present — ‘chairs for the chairs’. Super funny, if a tad bit unpractical to get home via train or airplane.

A big “Thank you!” to José, Uwe and Madelaine as well as the other organisers that made the Agile Testing Days such a great and enjoyable conference.

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d bloggers like this: