Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the category “tools”

Set Achievable Goals

In almost every agile training or consulting sooner or later we talk about slicing user stories. Over the years I had many interesting discussions and I hope I could help my clients to find their way. But I always had a feeling that I am missing something. That feeling guided me until last autumn when I changed the way how I track my daily steps and learned a lesson myself.

2019 I set a target to improve my physical condition. I bought step tracker, I rolled in into fitness class and … nothing happened! yeah… steps I had to do myself and that is where I failed. My fitness tracker as daily target set 10 000 steps. Some days I achieved that target, but mostly my week overview looked like this:

November 2019 I had an idea to try out with less. To set the bar lower. I decided to set the target to 8000 steps per day. That was good decision and it changed everything! I achieved the day target 6-7 days/ week, to compare 2-3 days/week before.

I kept observing this for few weeks to be sure it is not some kind of coincidence (I had one or two good weeks with 10 000 as well). Of course it is just a target, I do not stop if I achieve 8000 steps. By setting bar lower it helped me to overcome low activity days and motivated to get up from a sofa and walk around the block. It is SO simple! In days when I got only 5500 I will get up if my target is 8000, but if it is 10000 I give up and even do not try. So at the end I move more (my goal for the year) and in total I achieve more, even if the day target is lower!

That is the secret behind thin user stories and committed story points per sprint:

Set achievable goals!

Notes On Effective Meetings

This is guest post by Daniel Carral 

Goal

You’ve probably experienced unnecessary, boring or ineffective meetings. Me too. We don’t want, not anymore. Therefore, why don’t we gather some thoughts which might help increasing the effectiveness of our meetings?

Set the Frame

Description of the event in Google Calendar is important. We might wanna include there:

  • Goal: What we are here for (e.g. decide which CMS to use)
  • Location: Be specific (e.g. URL, Tool, Bibliothek, Restaurant, Park…)
  • Motivation / context: Why are we doing this meeting? Background info.
  • Agenda: Structure to be followed during the meeting (e.g. intro, discussion, voting)
  • Previous preparation: Does something needs to be done before attending? (e.g. reading a document)

Remember

We want our meetings to be:

Necessary

Meetings cost money, a lot. Let’s use them wisely.

Small

Do we need to mention the 2 pizza rule, again? :)

Punctual

  • Respect to everyone and their plannings for the day.
  • Examples: set alarms @ Google Calendar, plan your day before starting the work.

Moderated / facilitated

  • Psychologically safe spaces (not afraid to ask or to say what you want to).
  • Ideally with a time-keeper and/or minute-keeper (could be a rotating role, enabling “train the trainers” sessions).
  • Examples: Scrum ceremonies (Scrum Masters), coding dojos / coderetreats (facilitators).

Documented

  • No everyone needs to attend to know what went on / what has been decided.
  • Excellent mechanism / opportunity to keep track of agreed action items.
  • Examples: “Meeting Minutes” space @ Nuclino.

Scheduled in advance

As mentioned in “punctual”, planning days / weeks takes a lot of effort. Why not being respectful with the time of our colleagues and don’t call for “spontaneous” meetings (same / next day), unless necessary?

Challenged

Gathering feedback (ideas/comments/suggestions) from participants, so we can keep improving.

Examples:

  • UX Chances #1 @ Google Docs (Forms)
  • 1:1s Continuous learning @ trendig

Note: Activity Feedback Template (easy to create with Google Forms, as an example), help you to evaluate the quality of your meetings. Additionally, they are easily reusable by duplicating it for whatever meeting you organise.

Tips & tricks

  • Schedule buffer time (at least 5/10 minutes) between meetings or workshops.
  • Schedule enough pauses/breaks during longer meetings or workshops.
  • Use a template when filling descriptions @ Google Calendar (or whatever you use) or adapt previous descriptions for new events.

Summary

80% of the meetings could (and probably should) be framed as workshops instead, Liberating Structures are extremely powerful, everyone hates meetings so much that they are willing to give a try to whatever could make them better, Notion is better knowledge base than Nuclino, and last but not least: Mondays suck; try not to schedule meetings on Mondays :)

 

Afterword by Kris

I used to work for a company where people liked to measure their productivity by the number of meetings they participated. So there was a meeting for everything… We had many useless meetings, many lost hours of life. Then I worked for a company where people treated meetings like a status symbol. Important people went to the meetings and never shared what was discussed there. If you asked them about meeting results, the answer was, that you are not allowed to know. Based on how company evolved over the years, I guess there was no outcome nor results of those meetings. Then I worked for company who never have meetings. At first I was so happy, but later I realised that something was terribly missing. Over the years I also participated meetings which where started by moderators question: “so why we are here?” or “what do we need to discuss today?” Those I hate the most. You know that no one is prepared and you know that everyone will start to improvise and it will take hours…

I used to initiate weekly meetings, to block the time to talk about important topics. Now I don’t do that anymore, because the reality showed that those meetings fail on all main topics of a meeting: goal, motivation and agenda.

Gmail And Dots

This week I was on the phone with my insurer. It was Saturday and I had to say my name, my address, my birthday and my bank account to identify me as me. I asked insurer in future to contact me via e-mail because during workday I mostly cannot answer the phone, because I work as a trainer with full class of students.

  • she: please spell your email address
  • me: kristine dot <rest of my gmail address>
  • she: your phone number
  • me: we are on the phone right now, you know my phone number
  • she: sorry, I have to register this kind of information. this is for Saturday calls only.
  • me: ….. +49 <numbers>
  • she: do you have a dot in your email address? is there any capitals?
  • me: (i spelled it and you did not listen) it is gmail address, it does not matter. And email addresses are not case sensitive.
  • she: no, you are wrong, it matters!

I almost forgot about this conversation, but today got reminded by Netflix scam story. I wrote a year ago how handy it is that Gmail finally decided to ignore the dot and sell it as a feature. I was thinking as a tester, not as a user. But James is right, Google never informed me that I have infinite set of email addresses. If users does not know, and services, who collect my email address does not know it, then we are back to: it’s a bug not a feature! again.

As a tester I will keep using Gmail dot ignorance feature, but as a user I will pay more attention and write a mental note to myself about possible misuse.

 

 

Selenium Toys

My very good ex-colleague Klaus has a hobby: a creation of Selenium libraries. Currently, he is working on a new one and would love to have a feedback. The main idea is GUI regression testing, based on a layout.

Testing Personas

James wrote a nice post about test data and inspired me to write my approach to this topic.

In Germany “Max (Maximillian) Mustermann” is a tipical placeholder for a name. You can find examples of passports, bank cards, driving licences, CV and many other with this name.

Fun fact – person with name Max Mustermann really exists.

When I see tests from developers, it usually consist of: test test, teststraße 1, Teststadt 12345. Nothing wrong with that, but I cannot work like this,  after 2 weeks I will not be able to remember what did I test with this test user. So I came up with test personas, inspired from my family and colleagues. Here few of them mostly for bondary, layout and data mapping testing.

Names

Anna Jautrīte Broņislava Pilz

My 90 years old greataunt is German, but born in Latvia in times when it was typical to give three given names for a child. Since WWII she lives in Germany and uses only her first name on daily basis. I was next to her as her hand bag was stolen in Berlin during our round trip. I guided her to the police office and experienced the situation with her full name. Police officers had trouble to squeeze it into the form. The field was simply too small for it.

María Dolores Martínez Ruiz and Juan Pablo Fernández de Calderón García-Iglesias

Several years ago I worked in a small company, whos 50 employees spoke 14 different native languages and none of them was English. We worked on products which main functionaly was based on data mapping. One of my colleagues came from Columbia and had trouble with his name. The system mixed up his last name with one of his given names. Here some information about traditional spanish names.

Calligenia Ioánnou Papadopoúlou

If I want to test bondaries, but not overact, than I use Greek names, which typicaly are long.

Jörg-Christian Müller

Given name with hypen. One of my developers had a name with hypen and in one of his tests he uses his own name and found a bug. Since then name with hypen is on my list.

Addresses

Similar to names I use long, hypened and typical street names. In case I test something for abroad and not sure about address layout there, I search for restaurants in the specific country and use their addresses as a test address.

If I test something for ecommerce, especially for B2B customers, than I check if they have defined areas for sale representatives and use edge cases on daily bases. People tend to forget about special implementations – my test personas saved developer time already several times.

E-Mail Addresses

As I started my test career one of project colleagues showed me www.mailinator.com – free tool with free access inbox. “Isn’t it great?!Everyone uses it.” he added. I was not so big fan of it, I saw security issues everywhere. If you test an emails, than there is some information in it. For example, link to your test system. Are you sure you want it to be exposed?

Instead of that I have variety of registered email addresses, but I also use following two workarounds.

GMail Address with a dots

For example, if you have gmail address: gracehooper@gmail.com than you also can use: grace.hooper@gmail.com, gr.ace.hooper@gmail.com or grace.h.o.o.p.e.r@gmail.com – because GMail simply ignores dots.

Plus sign “+” in every e-mail address you have

For example, my email address is kristine@test.org. In this case I can use kristine+anna@test.org and kristine+calligenia@test.org to seperate my test cases by test persona.

What About Agile

I am big fan of Dilbert.

I like how in few pictures he captures the essence of software development, but in the same time I am ashamed, because I am part of it.

My trouble lately (several years to be specific) is agile. I have no trouble with methodology itself, but the way it is used. I struggled around till I saw this:

I did small research – talked to people and by the way asked about their info source on the subject. Some of business people really said that they have no idea what it is, but they learned that that’s the thing what sells. Agile is new sexy!

I start to think, how could I explain in small talk, how I understand agile and why it is worth to get to know more about it. Trade magazines often points out the speed as a key value, but never tells you how to get the speed. By pushing just accelerator you will not make very far on bend and bumpy road.

So let’s go back to the basics. First value on agile manifesto says:

Individuals and interactions over processes and tools

Fifth principle of agile manifesto:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Individuals, motivated individuals… and trust them! How about that?! The trust. Whom do you trust?

I did small survey (that’s the thing I always do if I am on something) and got shocking answers. My responders do not trust their colleagues and will not address the issue, no matter that they agreed that trust among the colleagues is very important.

As more as I think about the trust as much, I think that may be it is the source of my struggle. Current society are so focused on career and success that we forget about individuals and trust at a workspace. This project is just a step to next big thing.

As a tester I wonder quite a lot about things, what I thought is common sense, but turned out that it is just my sense and I have to explain it to others or write a bug report :) . I think that trust among colleagues is nothing agile-unique. And also satisfied customers and working software should not be something extraordinary – isn’t it something “by default”? Why we need manifesto for that? And if someone wrote manifesto for all that, why do we grade it by doing not properly?

Post Navigation