Category: Learning

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 2

Experiment Learning Testing No Comments

The first keynote of day 2 “Test First Saves The World”, was Joe Justice who talked about applying Scrum in non-software industries, including the automobile industry. He also presented a very exciting project which attempts to build a car: http://wikispeed.org/car/

In fact, he brought parts of a car and invited the conference attendees to join a Scrum team and build a car in the hotel lobby.

People building a car in the hotel lobby
Building a car at the Agile Testing Days 2014

Joe also pointed to another project he started: The MicroHouse, that aims to provide a clean bathroom, a clean bedroom, a lockable front door at less than 100 USD. It is this project that is linked to the “save the world” part of the presentation title.

In the second keynote Fanny Pittack and Alexander Schwartz presented “Insights from Happy Change Agents”. Both of them have presented at previous conferences, but this time they went for a pair presentation and a keynote — even though they have never worked together before. I found this one very inspiring, to say the least. They demonstrated how a coach can take on the perspective of a team, rather than using her (or his) point of view from the outside. In addition to that, there was also a pair exercise for the attendees to do. They also shared their slides:

To me, the talk was not only about changing your point of view, but also about trust in a team as well as a single person. When the question session started, I made an unusual (for me) move and asked whether someone from the audience was willing to prepare a pair presentation submission for next year’s Agile Testing Days. Then two things happened rather quickly: First José Díaz announced, that if I find a pairing partner, then the session is already accepted:

How awesome — and trusting! — is that? The second thing to happen: The first person I noticed to signal willingness to co-present with me was George Dinwiddie. We met in person for the first time at this conference, have never worked together before and we’re separated by the Atlantic Ocean. I expect to have great fun and learn a lot while working on our presentation. I am sure that we will figure out how a distributed team (of two) can work.

Even now as I write this — a week later — I’m amazed, impressed and honoured by the trust and friendliness of all this. Thank you all: Every single one in the audience in general and George & José in particular!

After this, I had a short break from the ‘regular talks’ and attended the Open Space session (there were six of them, throughout the conference!) facilitated by Alex Schladebeck and Meike Mertsch. Since there were not too many people attending the sessions, we changed the format to a Lean Coffee. I like it a lot when a format is changed ‘on the fly’ in order to match the circumstances, instead of sticking to a plan that doesn’t fit well anymore.

Among other things, we discussed the question “What makes a good session at this conference?”, brought in by George and me, since we wanted to know what it is that people like about a session. Thank you for voting on this topic to everyone who attended!

The third keynote of the day was David Evans’ “The Three Pillars of Testing”. He explained how testing and agile fit together and placed just the right amount of puns into his talk. He explained the classic order of capitals, what ‘Euthynteria’ is — and what is isn’t:

Do not confuse euthynteria with 'youth interior'
What ‘euthynteria’ is — and what it is not

This was the end of a very pleasant and entertaining second conference day.

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!

The Agile Testing Days 2014 – Day 1: The Tutorial

Learning Testing Tools for Testing 5 Comments

The 1st day of the Agile Testing Days for me was a full-day tutorial by Alan ‘The Evil Tester’ Richardson about technical testing. The tutorial was very hands on, and we actually tested something — a website.

I liked how we started with the website as such and focused on the relatively simple aspects of getting a user account and logging in. We did some testing and then reflected on what we were doing and how we did it. For example there were various ways of note-taking:

  • I mostly used pen & paper, and for some notes a text editor (e.g. when I knew that I would like to make a note of text I would enter more than once)
  • Some used their text editor of choice, Evernote or similar tools.

After interacting with the application ‘just’ using the basic browser feature of rendering HTML, we stepped down to a slightly deeper technical level and used ‘developer tools’. These allow interaction with the DOM and, for example, manipulate what an HTML form would submit back to the server — including, but not limited to, selected values of drop down lists. — While not every user will do that, some will. And it’s a good idea to test that your server can candle this unexpected input. We also looked into a number of tools to capture (and again manipulate) network traffic, such as HTTP proxies.

I liked how ‘technical testing’ was presented as something that is different from ‘test automation’. Many of the tools we use for testing enhance our possibilities as testers — and sometimes they also allow for some automation. The main point of technical testing though, is increasing the testers reach into the technical details of the system under test.

This is what I expected from the day and also what was delivered in the tutorial.

Thank you Alan, I liked it a lot!

Barcelona Ruby Conference 2014

Learning No Comments

After two very exciting and enjoyable days, the Barcelona Ruby Conference (2014 edition) is over, so here are a few things I’ve learned about and/or liked. I’ll mention these in no particular order as long as the memory is still fresh.

Barcelone Ruby Conference Poster
Barcelone Ruby Conference 2014

Over one of the lunches I discussed ways to improve coding skills online with some people at my table. For those interested in mathematical puzzles I suggested to have a look at Project Euler, at site that offers interesting and sometimes very hard to solved problems. Someone recommended rubeque, where you can “hone your Ruby skills by solving small Ruby problems while competing against other Rubyists.” Then there is Ruby Koans, where you can learn Ruby by making test cases pass.

One Tom Stuart presented some ways to avoid literals in Ruby in his (lightning) talk. Awesome, funny and probably not meant for production code.
The other Tom Stuart talked about his favourite algorithm, the Burrows–Wheeler transform, in his lightning talk.

Erik Michaels-Ober showed how to write fast Ruby. His examples showed that the faster code can also be the code that’s easier to understand. I hope that he’ll put his slides online sometime, because a) they contain all the examples he presented and b) they were very nicely illustrated.

Leon Gersing‘s presentation “Keep Software Weird” was inspiring, funny and, well, Zen. A quote from his talk: “Code is a living representation of who you are, right now.”

I also really enjoyed talking to the people form KeepFocus (including, but not Limited to Jakob, Palle and Jan).

Thank you to everyone involved in making this conference so enjoyable and exciting!

It’s Not Always A Commit That Breaks the Build

Learning Testing 4 Comments

In many cases a red build means, that some commit to the version control system broke it.

However, occasionally it can be something as simple as waiting that breaks it. Here’s what happened to me very recently when changing a Ruby project:

  1. I didn’t commit (& push) to one of my projects for a while.
  2. Then I made a pretty minor change.
  3. The local test run was fine.
  4. So I committed & pushed the change to GitHub.
  5. The builds on Travis-CI turned red.
  6. Oh?!?

What happened?

Travis-CI always sets up an entirely new environment, including this:

bundle install

Now, RSpec has been updated (to 3.0.0) since the last test execution on Travis, and I didn’t specify a version in the Gemfile (actually the gem spec file of the project), and I didn’t specify which RSpec version to use, and some RSpec methods have been changed in the meantime.

In particular, some of the specs used be_true, to check a number of predicate methods. However the new RSpec way is to use is_truthy (and its counterpart is_falsey). These methods check something slightly different compared to this line:

expect(value).to be true

In RSpec 3.0 only true is true, and everything that is interpreted as true (everything other than false and nil) is truthy. Also note the absent underscore in be_true (as used in earlier versions of RSpec). See this short example of RSpec:

describe 'RSpec 3.0 true vs. truthy' do
  it {expect(true).to be_truthy}
  it {expect(true).to be true}
  it {expect(1).to be_truthy}
  it {expect(1).not_to be true}
end

Notice here, that 1 is truthy, but not true.

Lesson learned

In order to avoid trouble like this, it seems to be a good idea to fix gem versions for a project in the Gemfile (or the gemspec).

This can avoid broken builds on your Continuous Integration Service (as in my case), but it can also prevent a new team member from struggling through dependency issues after running the bundle command to set up a new machine for development. See, for example “Ruby’s Pessimistic Operator” and “Ruby Gems Guides – Patterns” on how to use the ‘twiddle wakka’ operator for gem versions.

© 2012-2026 Stephan Kämper — Mastodon

MENU

Navigation