Tuesday, October 24, 2017

Testers and Developers - Thoughts about Collaboration

This post had been triggered by a survey conducted by Maaret Pyhäjärvi and Franzi Sauerwein about the collaboration between testers and developers. As I'm quite passionate about the topic I wanted to share my experience as well.
While taking the survey I felt the increasing desire to write about my thoughts. So I asked Maaret and Franzi whether they would agree with me posting my answers, as I didn't want to spoil the research or bias anyone. Fortunately they confirmed I could go ahead. So, whether you continue reading the following or not: if you haven't taken the survey yourself yet, please do so and support the research!

The Survey

The survey starts off with the question with which role you identify (developer, tester, both, neither). As I identify as a tester, I took the related option. Here are the questions and my answers.
  1. Tell us about a memorable moment of working together with a developer
    Not long ago, I detected a strange behavior in our product and wondered what caused it. It seems I expressed my astonishment loudly. A developer overheard it and instantly came over to see the strange behavior himself. Another developer joined in as well, we debugged the problem together and identified the root cause way quicker than I would have done it on my own. (I really like those situations of spontaneous collaboration and joining in myself in case I overhear a developer struggling. Another perspective often helps, no matter our "roles".)
  2. Has a developer told you your contribution is valuable?
    Yes
  3. What did you do?
    • Going through test ideas together early and asking questions to clarify behavior/risks which had not been addressed yet
    • Testing an early increment together
    • Going through test findings with the developer and instantly fix them together
    • Finding issues in places the developer did not expect at all
    • Constantly trying to improve the product/team/myself
  4. What frustrates you when working to developers?
    • "Them vs. us" mindset and behavior; "those evil testers"; testers seen as inferior monkeys clicking around and doing monkey stuff -> fortunately all those points are not the case in my current team
    • Communication via ticket comments instead of direct face-to-face communication
    • When the developer hands over a build but did not basically test it themselves yet; e.g. when an issue is identified on first interaction with the product
  5. What do you enjoy when working with developers?
    • Close collaboration in general; pairing and mobbing (mob programming and testing)
    • Complementing each other regarding skills and perspectives to build a great product together
    • Shared vision to deliver a quality product which helps our users

The Other Side

After submitting my answers I was curious which kind of questions I would have gotten if I had provided another answer on the initial question regarding my role/identity. I found that interestingly two questions for developers are framed slightly differently: "Have you worked with a tester that turned out to be invaluable to the team?" and "What did they do?" This made me think. Right now I have an awesome team around me who really appreciate how I contribute and see great value in me being on the team. But when talking to other persons in our company I received different perceptions of testers.
  • Testers being the evil ones breaking the software. I'm with Maaret here: "Testers don't break the code, they break your illusions about the code". It had been broken before.
  • "Manual testers" only clicking around the software, just following endless scripts, and doing their "monkey stuff". I had been told this to my face; I guess the other person did not realize what they were saying. In that moment I did not succeed in changing their view on things, so I'm still pondering how to address this perception issue: testers as people who are not valuable if they don't automate things. You know, everything should be automated.
  • Testers being inferior when compared to developers. Probably a consequence of the last point, but we're often still seen as the underdogs who are either not good enough to be developers themselves, or who are still on their way of finally becoming developers.
  • Developers being proud of not needing any testers. Well, if the testing expertise and experience exists in the team and the team shares responsibility for quality and testing, I don't see any problems with not having a dedicated tester. However, even if not having a dedicated one, I would say they still do have testers on the team. I really promote the whole-team approach to quality and testing. But when a team tells me that they don't need any tester, I would love to join them for some weeks and just observe to learn how they do things.

Collaboration

After taking the survey and having those kind of thoughts, it occurred to me that I had posted the following tweets in the last weeks about tester and developer collaboration.
This made me realize again how much I enjoy the close collaboration with my awesome teammates. When working together it does not matter who has which role or does which activity in the moment. And this finally confirms again what motivates me and keeps me going: building great products which deliver value together with great people.

Wednesday, October 11, 2017

TestBash Germany - My First But Certainly Not Last

Last Friday, TestBash Germany took place for the very first time, in my hometown Munich. It was my very first TestBash; I gave my second conference talk ever; and it was simply amazing.

Impressions

Let's give you an idea of the atmosphere first. Here's TestBash Germany in tweets!

The Meetup Before


The Conference Day


After-Conference Meetup 


Open Space 


Talking, Take Two

Just last week I gave my very first conference talk at SwanseaCon. Shortly afterwards I found myself walking a theater stage, giving my second conference talk. I felt excited to get this opportunity; nervous to get on stage in front of a bigger audience consisting of mostly testers; and a bit freaking out due to the big camera in front of me. Fortunately, according to first feedback the talk seemed to have gone down quite well. If you'd like to have a first glimpse, check out my slides: Next Stop: FlixBus! A Tester Exploring Developer Land. Later on you'll find the recording on the Ministry of Testing Dojo.
Of course, not everything went as planned and I think there are several things to improve on (like learning how to ignore cameras). However, all the feedback and tweets about my talk really made my day; especially the following from two of the most awesome testers and speakers I know of - still can't believe it!

My Personal Highlights

There were many awesome talks and sessions, but the following impressed me the most. 

Last But Not Least: The People

You already heard me say it several times, and I mean it: In the end, it's all about the people. The people make this great community. And the community makes events like TestBash great. Therefore: A big shout-out and thank you to everyone who is part of it. And if you're feeling you're not part of it yet - please don't hesitate to ping me on Twitter. And if you're not on Twitter yet, I'd really recommend you to create an account instantly! Twitter helped me enter the community! :-) 

Saturday, September 30, 2017

SwanseaCon and My First Conference Talk Ever

Let me share some of my adventures at and around SwanseaCon 2017 where I had the honor to give my first conference talk ever.

Before SwanseaCon, or: Off to Swansea!

February this year I was invited by Viv Richards to submit papers for SwanseaCon. SwanseaCon? To be honest, I've never heard of it before. During my research I found that it's an "Agile Development and Software Craftsmanship" conference in South Wales. I was honored to be asked to submit to a developer conference! Judging from the past years, it sounded really interesting - so I did submit. Only a few weeks later, Viv came back to me with the great news that I've been selected! That was the beginning of a great adventure to the north of Europe.

When planning my trip from Munich to Swansea, I decided to fly to Cardiff directly, which would mean to travel a few days earlier on Friday evening. This decision proved really valuable! First of all, I was excited enough already about the conference and my upcoming first talk without the
additional time pressure.
After arriving in Wales, the way from Cardiff airport to Swansea was not completely obvious for me, despite previous research on the internet. However, it was made easy for me as I met some great people on my way, traveling to Swansea together. The next day, I enjoyed a lovely sunny Saturday to discover not only Swansea's city center, but also the nice district Mumbles with Oystermouth Castle and some great ice cream at Joey's. Really recommended!
On Sunday my plan was to practice my talk again and maybe do some final adjustments, but well, the nature of plans is that things can easily go differently than we planned. In my case, I discovered that the travel adapter I brought with me did flawlessly charge my mobile phone, but didn't fit to my laptop cable! My bad. I had prepared well to avoid such incidents, but this one I had not tested out before. Lesson learned for the next travel to a country with a different socket type. So I asked at the hotel if they have any adapter available - and yay! They could provide one that fitted my cable. But: My laptop did not charge. :( So instead of practicing my talk or relaxing, I ran around Swansea to find any other travel adapter which might possibly fit my laptop cable. Lucky me - the fourth adapter finally fit AND charged my laptop. Phew! Well, I knew that Viv would have gladly supported me, but I was eager to try solve my self-induced problem myself before bothering him as I knew he had a lot to prepare for the conference.

On Sunday evening I had the chance to meet up with some early arrivals for the conference. That meant Viv himself (a pleasure to finally meet him!), Richard Bradshaw (whom I met in his tutorial at Agile Testing Days 2016 already), Carly Dyson (whom I only briefly knew from Twitter and had spoken at Nordic Testing Days) and Georgina McFadyen (whom I had not yet met and who was about to do her second conference talk at SwanseaCon). A lovely group to start with! As an introvert I was happy to get to know some friendly faces upfront to the conference, which instantly made me feel so much more relaxed. Ready for the conference to start!


During SwanseaCon

Conference Day 1 - Diving In

The conference took place at Liberty Stadium in Swansea. A nice venue! We were greeted with tea, coffee and cookies. The two session rooms were quite large and showed a friendly cabaret setup, having people group around round tables. All the sessions I attended were really great, each session in its own way. However, in the following I will only list my personal highlights of each day.
  • Let the conference begin! After a warm welcome and some introductory words by Viv, Sander Hoogendoorn kicked it off with his opening keynote "It's a small world after all". A great talk about how quickly time is changing and how everything is becoming smaller and faster. I especially loved the idea of "continuous culture".
  • In her talk "Don't Diss the Discipline", Georgina McFadyen shared her stories about how her company changed from waterfall to agile, and from being professional software developers who did their job, to software craftsmen who really cared about the product they were creating, about its quality and its value to the ones using it. Awesome experience report, I really loved her stories and presentation!
  • Seb Rose of Cucumber shared "10 things you need to know about BDD, Cucumber and SpecFlow". There were several misconceptions to be addressed and clarified! Though not everything was new to me, he did a well-rounded talk covering many essential topics around BDD and the core concepts or benefits of it. Great job!
The first day ended with some snacks and drinks, a nice socializing and networking opportunity to share and discuss our thoughts about what we heard with other people. Right afterwards several attendees decided to join a special meetup in town, where several of the conference speakers or attendees had the chance to give a lightning talk about any topic; prepared or unprepared. It was simply awesome! Many valuable insights given in short time. Nice way to close a conference day.

Conference Day 2 - My First Talk and Other Highlights

My talk was scheduled first in the morning, so I had the task to kick off the second day. In the beginning, not so many people had entered the room yet, but they grew more and more over time. And they were a lovely audience! In retrospect, when reviewing the received feedback and reflecting on what could be improved, I have to admit that it went really well, especially for my first conference talk ever. The dress rehearsals at my company and at local meetups really paid off (also regarding my level of nervousness). I forgot to mention some points (as always) and noticed some things I should work on (like me posture). But overall I cannot complain, it was a great experience! By the way, my slides are now publicly available.
The rest of the morning I attended further great sessions, but found myself not being able to focus on them as they would have deserved it. I got distracted by thoughts about this scary thing I've just done - public speaking, at a conference. I still catch myself wondering if this story really became true after all.

After a while, my focus was back; just in time to enjoy the following most awesome talks.
  • We had the honor to listen to professor Dave Snowden from Bangor University, the creator of the Cynefin framework. He gave his very insightful talk "Making Agile safe again: resisting the Borg" without any slides - just once using a whiteboard. Really impressive!
  • Afterwards, I heavily enjoyed columnist and author Kevlin Henney's talk about "Turning Development Outside–In". Such a great and entertaining presenter! He took us on a lively history of how development processes evolved and how we have to look closely for whom we are doing all the things we do and why.
  • Another talk I really enjoyed was "The Domain-Driven Coding Architect" by Nick Tune. Great storytelling of his lessons learned while finding out how to properly (!) read the DDD book written by Eric Evans! :D
  • The conference was concluded by Sallyann Freudenberg and her talk "The trouble with culture", talking about neurodiversity and how teams benefit from it. What an awesome closing keynote about a really important topic everyone should learn about! And definitely lots of food for thought.

After SwanseaCon Is Before SwanseaCon?

After the second day, most people went home directly. I took this chance to review the #SwanseaCon twitter stream, see what people shared about the talks I missed. So many great sessions! Even for a two-track conference it was really hard to choose between all those great speakers and topics. A pity that not all sessions had been recorded, but sometimes it's also the charm of a conference that you had to be there to experience them. Only there you can feel the whole atmosphere - and especially connect with people. You can't do that when watching a recording alone at home. I did connect with several people at this conference and am already curious what they will be up to next.

The trouble or sad news: This might have been the last SwanseaCon. Believe it or not, Viv does all that work on his own. The organization was awesome and his support outstanding, in any way. He engaged family and friends to help and everything went so smoothly and professionally. Still: There's lots of money included when you organize a community conference by your own. A conference which supports speakers with travel and accommodation costs, but still comes with very affordable prices for attendees. If no one buys a ticket - you basically lost a lot of money. As attendance on this third edition of SwanseaCon was worse than last years, and there's so much work and blood and sweat and money in it - he understandably considers not repeating it. Especially as this man volunteers with so many other great things for the local community already, while working a full-time job and having a family with soon to be five kids! All my respect goes to him.

What I loved about this special conference was the speaker and topic selection itself. Because in the end, it's all about the people. I you have a chance to come to Swansea, I really recommend this event. Would love to return to this wonderful conference where so many great people met to learn together.
"Having attended a fair few technical conferences, it felt refreshing and important to be part of something a little softer. Software development is about community, communication and culture, and SwanseaCon scored top marks on all three." - Thomas GuestSwanseaCon 2017

Monday, September 18, 2017

A Long Story Cut Short - The Importance of Pausing to Think

Today was the day. My team released a huge epic introducing major changes in our application. Normally, we release many changes during our daily release slot. However, this release was unusual in itself, and it taught us a bunch of important lessons.

We started working on the epic on July, 11. As we had discussed the topic several times before, the whole team felt that we had a shared understanding and were ready to go for it. During the first two weeks only one developer focused on the topic, and gained first insights on how complex it actually was. He raised the issues he was facing and called for support, especially as delivering this epic was our highest priority. We decided to have the whole team step in and share the work load. We still highly underestimated how far this would go - or rather, how far we would let this go.

The whole team, meaning five developers, our product owner, our agile coach, and me as tester delved into the topic. And together, we gave birth to a monster. With every little change the whole solution got more and more confusing. It was incredibly hard to figure out what was expected and what was unexpected behavior, and especially how we would ever be able to understand our implementation in the future again. And by "future" I mean half an hour later. Everybody was having a hard time. Nobody was happy with what we did. The amount of curses increased rapidly. We all felt we would soon go insane. One teammate even suffered from nightmares and sleepless nights. We are really not proud of this tragedy, but this should give you a pretty good idea of what was going on.

Desperately, we discussed again and again if there would not possibly be any other way to fulfill the business need but also enable ourselves to keep our application maintainable, extendable, and last but not least testable. However, our discussions turned in circles. So we pressed on with implementing the epic, eager to get to a minimum viable version for which our product owner would let our users access our test system to get their feedback.

The fun fact - or rather really sad truth: As soon as we were ready to start the user acceptance test, one developer took the time to create a completely new prototype, based on a totally different assumption. And after only half a day, on August 30, he was ready to share his new approach with the team, to have them challenge it and find flaws in his thinking. We were stunned by his simple approach. We raised some questions, but couldn't find any reason why not to go with it. By only doing one thing differently, everything else became a lot less complex. Comprehensible. Consistent. Doable. With way less effort and way less changes in our application. What he did? He threw a convention over board which everybody had considered as a fixed precondition. You know, as soon as you have to handle x, everybody strongly recommends to do y to avoid problems. We had never challenged this assumption we had in our heads, all of us had accepted it as a given. But in the middle of implementation, it turned out that this convention made everything really bad for us. Neglecting the convention instead was fitting way better in our context, from business perspective as well as technical point of view.

Shame on us that we had to go such a long and winding road of learning how not to do it. Nobody had put pressure on us but ourselves, not our product owner, not our agile coach, not our stakeholders. We ourselves were driven by the thought that we have to get this done and finished as soon as possible, making us pressing forward without taking time to actually think and experiment early. The team even "temporarily" discarded our rule to stop starting and start finishing, meaning that all developers continued to start working on new topics before former ones had been completed. Unsurprisingly, this created lots of bottlenecks and context switching, making the whole situation even worse. And as soon as one of us felt we have a bit of time to breathe again - he found the clean solution.

To cut a long story short: within a few minutes of discussion, we wholeheartedly threw away our first implementation on which we had worked for nearly two months by common consent, in favor of this new and easy approach which we in the end fully implemented within about one week. After going through all this, we couldn't but ask ourselves in retrospect how this could have happened and why by all means it took us so long to challenge our assumptions, learn, experiment, and see the solution. But in the end we did learn the following.

Conventions are recommendations but not carved in stone; they might not apply or be a good fit in your context. Think outside the box (that you might have created for yourselves) and experiment early with different approaches. Don't get so busy that you cannot pause, breathe, and think. And last but not least: Don't be afraid to kill your baby, especially if it turns out to be a monster.

Bonus read: By coincidence or not, when thinking about publishing this story I came across the post On Real Options and Speculative Investments by Liz Keogh which nicely reflects many facets of our story. Besides the fact that I really relate to the core messages, it's a highly recommended read.

Monday, August 14, 2017

Thoughts about Awesomeness

To be frank, I hesitated to write this post. I still wrote it because I think it is an important topic. I feel the need to document my current thoughts for my future self and to share them as a basis for discussion. The following reflects my non-expert, non-scientific impression of things. My personal thoughts of today will evolve as I learn more. This post got quite long, but please bear with me and read to the end.

At Agile Testing Days 2016 a Women in Agile Summit was hosted. To be honest, when I read about it, I was taken aback at first. Why would a women event be needed? Why excluding men and everyone who's not comfortable with this binary classification? I felt that making something gender-specific was not the right approach. I am not considering people for their gender first. We're all humans, right? We're having many different identities. In the end, we're all individuals. So I'd rather strive for equal chances than supporting women over others just because they're women; strive for diversity in all means, not only gender. It simply didn't feel right. It still doesn't feel right. But I might be thinking a bit too naive about the topic. Back then I finally decided: Well, I am a woman, I'm working in an agile environment, so I should attend this event and check out what it's all about.

At the summit, I joined a lean coffee session with several women coming from South Eastern Europe and Germany. We exchanged our experiences regarding gender issues at our work places. The German women saw things just about like me: well, there's no real problem anymore. If a few more women would join our teams, that would be great. To attract them, maybe we could advertise more that we're having an open and safe work environment. Right, and there's probably still a salary gap, but it appears to be closing more and more. Besides that, we didn't encounter discrimination due to our gender yet - well, at times some positive discrimination. But so far so good, we're getting there.

And then we heard the women coming from South Eastern Europe, telling us way different stories. Stories of women having to justify constantly why they are having a "man's job". Tales of women who learned that they had to show bossy behavior to get accepted by their male colleagues, and of others having to use their charms to survive in tech. Those women reported about struggles which never occurred to me. Naive me, to be sure. So, slowly but steady I realized that this topic is not at all out of date yet. For another view point I recommend reading Maaret's wonderful blog post about the summit. Personally, this event triggered me to be more aware of the topic.

The next thing that surprised me came early this year. I had submitted papers for Agile Testing Days 2017, so I followed their news about the submissions. When the call for papers statistics were published, I was really surprised.
29% of papers had been submitted by women speakers. One of my colleagues was positively surprised how high the percentage was. I, however, was rather disappointed; I would have expected that figure to be way higher. I mean, it was not about getting accepted at the conference, it was only about submitting. Why would less women submit? Does this only reflect that there really are way less women in tech overall? Or is there another reason?

Nowadays, again lots of discussions are going on regarding women in tech, minorities in tech, anyone in tech. Probably the most prominent example right now is the manifesto of a male engineer internally published at Google. I won't address the topic here, it has been discussed at length already.

Instead, I'd like to share another story with you. End of July, Ashley Hunsberger raised awareness of the following post.
It was quite commonly agreed that this kind of list rather served as marketing campaign than represented reality. On the one hand there were more women experts in test automation to be named and on the other hand same listed men seem to not match the profile at all. When people started to list further women, I found myself named as automation expert as well. Not my biggest strength, but people even started to follow me due to the mere fact I was added to the pool!
Shortly before that tweet, I had the honor to be invited to the Women in Testing Skype/Slack group, a group from and for women in the testing community (if you want to join, I can invite you, just send me a direct message via Twitter). As a reaction to above post, Anne-Marie Charrett came up with the idea to create our own list of awesomeness. The intention? Show the world that there are way more women in testing that could have been on a list. Way more that could get invited to speak at a tech conference. Way more to follow and get to know. And even way more who are not so publicly visible but worth being public.

Within very short time, we had a document with over 100 names on it. I could only contribute marginally myself; however, I was feeling so honored when realizing someone added me to the list as well. Even while creating this compilation of awesome testers, we felt how great it is to see who else is out there and which topics they're into so everybody could reach out to them more easily. We wanted to get this list out to the public. Agile Testing Days agreed to support and published the list on their blog.

The blog post leaked a few days before official publication date, and the reception was already overly positive and welcoming. I was even asked whether we also had a related Twitter list. Great idea! So we created it: https://twitter.com/lisihocke/lists/awesometesters Unfortunately not all women named have a Twitter account, but most of them do. The list is still growing as the Women in Testing working party is still adding to it. So look out for an updated version!
Side note: I would love to have gender, ethnic groups, educational backgrounds, or anything to be ignored and have a real diverse list of awesome testers compiled. The mere need of an all women list sticks in my craw. However, I found that sometimes support is needed to increase transparency and to point out issues. Also regarding my own biases. Just compiling this new Twitter list made me realize its difference to a personal Twitter list of awesome testers I created a while ago. Judging from the 70 testers I listed, I was aware of way more men (47) than women (23) in testing myself. I'll definitely have to add more women there as well. Well, every list is wrong in some way. Still, we can use them as a starting point and as a basis to trigger discussions.

In the end - there is no end to the topic yet. In my company, we have many awesome women. We also have many awesome men. We have colleagues from many different countries and cultures. I think (and hope) they had not been hired because of their gender or identity, but simply because they are awesome. Maybe we're still too similar when it comes to our education or work background in order to gain from actual diversity - worth finding out. Also, I'd like to further encourage hiring less for skills but rather for learning mindset and team spirit. Everyone deserves a chance to show that they are awesome in many different ways, and they deserve your support to grow their awesomeness.

Tuesday, July 25, 2017

How My Colleagues Made My Day(s)

Yesterday I returned from a one-week vacation and my colleagues already made my days.

The first thing I noticed was how well and naturally my team took over testing during my absence. All stories had been thoroughly reviewed and released. The board looked awesome, only a few topics were in progress. The only thing left for me was to thank my team and tell them how much this support was appreciated and how they helped me return to work without stress.

Then a colleague approached me, asking me how things were going, how the preparations for my upcoming conference talks were coming along. I shared that I was in the middle of it and that I was getting a bit nervous already, and then she gave me this:
I was really blown away! This was so unbelievably nice of her. My new unicorn found its place at my desk and will now always remind me of her belief that everything will work out well. Hopefully it will also trick my own brain into believing this myself.

My next highlight was that a teammate called a spontaneous mob to work on an especially tricky story and get through bumpy terrain. Not sure if he knows it, but I love it when we sit together with the whole team to find a great solution! I found that I always learn so much personally. I'm so happy that the team really accepted the idea of mobbing as a valid and productive development approach and that they call mobs themselves in case they see the need for support of the full brain power of the team, or the value in sharing knowledge. I initially triggered mobbing as experiment; nowadays they do it naturally, even if I'm not around (like last week when I was on vacation). We had a hilarious time hunting down a bug - until we finally realized that the implementation was working as expected, only our verification procedure was incorrect.

And last but not least, I had a very special insight today. Our last sprint ended and the next started. During the retrospective we did a temperature reading, asking all team members to rate the last sprint from one to ten, with ten being the most awesome sprint ever. Afterwards, we shared our thoughts why we didn't rate it a ten and what we would need to do that. Personally, I loved our collaboration, so I rated it a seven. The missing three? Well, I shared with my team that I was disappointed with my own performance during the sprint, or rather the last two sprints (not counting vacation time). I love my team for their support when it comes to stepping in and helping with testing. But the last weeks I had the impression I had to "use" their support too often as there were so many open topics to follow up on my desk. Many topics regarding my product team, many topics regarding our company's agile testing community, and also topics for the overall tech organization itself. Topics that I see as part of my tester role, topics I could not easily hand over to volunteers, topics that were important and some urgent as well. And, I admit, also a few topics where nobody took the initiative; which triggered me to take care that they are taken care of. So, having to ask my team several times for support left a bad impression in my head and triggered thoughts of "I'm not fulfilling my job," "My team will start to ask why I'm even here," and other self-destructive stuff. Rationally, I realized that I accomplished many things in the last weeks, but still those thoughts were starting to creep up and I just wanted to let them know about this. I assumed that I felt like that because so many things are going on in my life right now. The preparation for my conference talks is creating a lot of work in my free time as well, especially as the first test runs are coming up so that now I'm really feeling the pressure to deliver.

In response to my thoughts, the first teammate shared that he knows these issues himself. He wants to focus fully on his job and give his best there, so his strategy is to only do that and say no to everything else. And if some things are not taken care of - well, they're not taken care of. He said that this works for him and he can't tell if it would work for me as well. I really appreciated his feedback and effort to help me. My problem here: I feel I only do things that I see part of my job. I know that as a tester it's not unusual to have many topics on your desk. Normally I can cope with them well, but it's simply a lot these days.

And then another teammate spoke up and made my day, if not my year. She said she doesn't see any problem with my performance and everything is working so well. That I make a huge contribution to the team and she couldn't see how it would run so well without me. That she can come to me any time and ask me for support with any topic, whether product related, or company related, or anything, and that she knows that this takes time as well but that I'm always so friendly and helpful. That everything's fine and I should just take it easy. THANK YOU! This was the support and encouragement I needed so dearly at that moment. So much that I decided to share this story with the world; not because I want to brag about it, but to share it with those people out there having similar thoughts at times, to encourage them to open up so they can find support as well, and to ask all those who happen to be on the other side to provide this support themselves.

To my colleagues: Every one of you made my day(s). Thank you all.

Thursday, July 6, 2017

About Crazy Days and Rope Bridges

On some days I fully focus on discovering the unknowns of our product, in close collaboration with my teammates striving to deliver value to our users.
And on some days I mainly work on company-wide topics like workshops, recruiting, or organizing meetups.
Some days are extraordinary, like going on a two-day offsite and building a rope bridge over a gorge. We had a team of talents coming from very different backgrounds who never worked together before. Still, we had fun, did a great job and learned a lot for our everyday work.

On some days I have so many tiny tasks and topics to follow-up on my desk that it's hard not to feel overwhelmed. Time just flies by.

On some days my team forms a spontaneous mob and I find myself learning a lot, but also contributing my perspective. On other days I work a lot in pairs in different constellations. Love those highly collaborative times.

On some days I hop from meeting to meeting having hardly time to follow-up on agreements, and finding myself wishing to not have accepted so many meetings in the beginning. But mostly they were important and valuable; and if not, we realized we have to make them so.

And on some days I extend the day to have dinner with my team or go to local meetups, to have a good time with awesome people and great conversations.

To be honest: I like the kind of days where I can fully focus on the task at hand the most, when I don't have to switch between too many contexts. But even though I plan for those days, I learned that plans are just plans and reality might be different. But that this is totally fine as long as I work on topics that provide value. Even better if I work on those that provide the highest value first.

Within the last three weeks I encountered all kind of days described above. Some have been crazier than others, but none of them were wasted. I have the freedom to decide myself on what to work on. So for me, it's about finding the right balance of how to use my time to achieve the best overall outcome, trying to do less in order to focus on what actually provides value.

Sometimes I excel at the right balance. Sometimes I fail miserably. As long as I learn something every day so I can improve myself and my surroundings, I'm fine. Every day is different, but never boring.

Sunday, June 18, 2017

Our First Take On BDD

Most probably you came across behavior-driven development already. But what is behind this term? What is at its core? How does it benefit a team?

Years ago I read a lot of blog posts about BDD and was intrigued to experience it myself. When starting in my current team, I began to spread my thoughts about trying BDD to see if this approach would help us. It took quite a while, but finally the team agreed to give it a try.

So here we are. We started experimenting with BDD and had our first Three Amigo sessions to kick our stories off and create shared understanding before starting implementation. We had our product owner on board, the developer who pulled the story, and me as a tester. We talked about the scenarios we see and discussed concrete examples. We raised questions and discovered unknowns. We decided what's in scope and what might follow later or never. We captured our thoughts as conveniently as possible, be it using Gherkin's Given-When-Then syntax for scenarios or any suitable graphical visualization. We decided on which scenarios to automate, on which level to automate them (mocked, through API, or through UI), and which scenarios to leave for manual exploration only.

Right after our first Three Amigo session, the developer told me how much she loved it. Now that we clarified everything we could think of at that point, she felt confident to be able to focus on implementation, without having lots of question marks on product side. She even said she wanted to do this on all stories from now on. As for myself, I could not agree more. I felt that the biggest part of testing had already been done. As most of my questions were already clarified, I could focus on looking for further unknown risks when testing the actual product increment.

Our experiments triggered me to read about BDD again. I found several awesome blog posts, all emphasizing how important having those initial conversations are to create shared understanding by discussing examples and therefore to drive development. All of them stated that automation is nice to have, but that this is not the main point of BDD. Of course, when you automate the discussed core scenarios, you also have an executable specification, improved your regression safety net, and added living documentation. Still, Augusto “Gus” Evangelisti concludes for himself:
"BDD is about conversations and collaboration to generate software that matters"
 Liz Keogh even goes beyond software:
"I can’t even say that BDD’s about “writing software that matters” any more, because I’ve been using scenarios to explore life for a while now."
"BDD is the art of using examples in conversation to illustrate behaviour."
"If you’re not having conversations, you’re not doing BDD."
"BDD isn’t about the tools. It’s about the conversations you have, exploring examples (or scenarios) of an application’s behaviour, to see if everyone has the right understanding."
"Some people really focus on the tools and testing. Others focus on specification. Really, though, it’s exploration that we start with; those thought-experiments that are cheap to change, and not nearly as dangerous as the real thing. [...] It’s pretty easy to explore what they want using examples, then use the results of that conversation as specifications, then as tests."
Having conversations is more important than capturing conversations is more important than automating conversations
Having those quotes in mind, can we call our team's first steps with BDD actually BDD? I guess yes, but I think we have to gain more experience before I can truly answer this question for myself. However, I already know that having those conversations upfront to increase shared understanding, explore stories and clarify questions helped us a lot to deliver actual value to our users. It was worth investing the time and it will be worth asking again: "Can you give me an example?"

Thursday, June 1, 2017

Select Your Team

May 16, 2017 was a day to remember at my company. All the people of our FlixTech organization came together for a huge event. All our products were pitched by their owners. And then every single one was free to chose their product, their team, their role, and their location - from now on.

Beginning of the year, I have come across the following reports of such team self-design events.
After reading about this approach of giving the people the freedom to choose their own future and actively encouraging them to do so, I was both curious and excited to experience it myself. In order to learn how we facilitated our event in a nutshell, check out Day 0 by my colleague Alex. What I want to focus on in this post is my personal view on how people responded to the event announcement and on the days after.

Freedom and trust...?

As soon as our company signalled that we would redesign our domains and products, but also have all our people redesign our teams around those products, people began to raise questions and express worries.
  • "What if the team I want to work on is already full?"
  • "What if it's decided my team is now located in a different city than I live in, but I don't want to relocate?"
  • "What if the budget of my team is reduced so at least one former member has to leave the team?"
  • "I was just hired for this team a month ago, what happens to me?" 
  • "What about people on vacation, on sick leave, or stuck in a traffic jam on that day?"
  • "What about my salary if I change my role?"
  • "Oh this whole self-selection thing is just fake, management will maintain control, they won't put that much trust in people."
You can imagine how this list went on. In the end, I'm really happy that our concerns vanished into thin air. Our board and management actually did put a lot of trust in our people, our CIO ahead of everyone. And the people did take it as an opportunity. After three iterations of trying to find the right team setups, every team member was happy with their choice, just as management and the board. We identified only two teams for which we needed to hire people having the missing skills. The other teams could also use support, but were already able to deliver value. Overall, everything worked out way better than we even hoped for. We were exhausted - but enthusiastic about our new teams, ready to celebrate and kick it off.

What now?

That wasn't it. After the event was before our so-called ignition period. Several products had been re-designed or even freshly added. Some teams were starting from scratch. Some teams split into two. Previously existing teams ended up with different members. Some people changed their role. It was obvious that we needed to consider a certain transformation period and invest in team liftoffs, as Diana Larsen puts it (check out her Agile Testing Days 2017 keynote to learn more).

Personally, I decided to stay with my former team, just like most of my teammates. However, we lost one of us to another team and did not get any new member. Still, we changed. So we decide to take this opportunity to form our team from scratch, to "re-ignite" it.

Right after the event, it was pretty hard not to fall back into old habits and just continue with "business as usual". We knew each other already, had all skills covered in the team, and could simply pick up the next backlog items to work on. On the third day after the event, we finally forced ourselves to pause for a moment.
  • To learn more about our team and uncover what's hidden, we created a team canvas together. This workshop format helped a lot to share our thoughts, our values, our goals, what moves us, who we are - to find our own new team identity. We decided on what we want to achieve together as well as new working agreements.
  • We moved to another room and took this chance to change our seating layout. We wanted to make it obvious that the team actually changed. To try something new. To get rid of table islands, foster team spirit and hopefully ease communication and even closer collaboration.
  • We heavily brainstormed to select a new team name, logo, slogan, theme song, and more. This way, we learned a lot about us on a personal level which brought us a step closer together. We were surprised how hard it was to find something from popular culture that we all shared and loved, as we're quite diverse in any aspect.
It's been only two weeks since the redesign event. However, I feel we now laid the groundwork for our new identity. I have the impression our team feels revived and shows fresh energy. And I hope we can keep it up to achieve our common goals and continuously improve as a team.

Monday, May 22, 2017

Agile Testing Essentials LiveLessons - A Review

Do you like video courses? Maybe you prefer them over reading books? In my case, I enjoy all kinds of media for learning, with a mixed approach working best for me. When I heard that Lisa Crispin and Janet Gregory are working on a video course about the essentials of agile testing, I knew I had to check it out. Their books Agile Testing and More Agile Testing accompanied me on my personal learning journey and provided great advice in many situations. So I was curious how Lisa and Janet would convey the essentials using videos and what I still might learn from them.

Content

The video course contains the following six lessons on agile testing.
  1. Lesson 1: Introduction to the Whole Team Approach
  2. Lesson 2: Test Planning in Agile Contexts
  3. Lesson 3: Shared Understanding through Early Testing
  4. Lesson 4: Automation in Agile
  5. Lesson 5: Agile Exploration
  6. Lesson 6: Ingredients for Success
All these essential parts of agile testing are addressed in a condensed form. Of course there is way more you might be able to talk about, but it would have exceeded the scope of conveying the core messages. For more information, Lisa and Janet refer to their books and encourage you to dig deeper yourself. As a starting point, they added a great list of recommended further readings to the course.

Format

The video length ranges from a a few minutes to about ten minutes, which feels just right to be able to pause and resume any time. To get a first impression yourself, you can watch the introduction video for free. However, please be aware that this is the first video course Lisa and Janet did so far. As with every new experience, you learn as you go. In my personal opinion, the introduction video is not representative of how the two present their content throughout the course. With every lesson they get more used to the format and present way more naturally. To be honest, I love that this shows that we're all humans and constantly trying to improve.

Structure

In each lesson, Lisa and Janet first present the key concepts and then ask the viewer to do a few small exercises. This way you can instantly apply the theory. They have you pause the video and think how you would answer certain questions in your context, or which examples and cases you might think of to explore a sample application. I loved how they got me actively thinking and involved at any point. I just couldn't help comparing the presented ideas with my own situation, and found myself making lots of notes what I would love to try next with my team. Furthermore, they share their personal experience about many topics by telling stories from the teams they worked on. I especially enjoyed this part, as it combines the theory with "the real world", showing how they gained and applied knowledge. They also share how experiments might fail from time to time, making clear that failing is an essential part of learning.

Target Audience

In this video course, beginner testers find condensed essential knowledge, providing great guidance on their way to grow. However, I would still recommend them to read Lisa's and Janet's awesome books. In my point of view, the video course is not a replacement for them, but it is a great starting point.

More advanced testers probably know about most concepts (and most probably have read both books already). Still, the course is a great reminder of the basics and might trigger one thought or another. Although its content had not been new to me, the course got me thinking on how to better convey these essentials to my own team and company.

Which leads me to my most important point: This course is not only useful for people identifying as testers, especially as those most probably would not read the agile testing books. I warmly recommend it to everyone working in agile environments, as agile testing is in its core a whole team topic and everybody should know about its essentials.

Saturday, May 13, 2017

Thoughts about Testing in a Mob

This was not the first mobbing experience for our team, but the first one to complete a whole story using this approach. One key factor that the team agreed with mobbing at all, was that our mob size changed dynamically. Whoever wanted to join the mob was welcome any time, and whoever preferred to work on other tasks could do so as well. This way, our mob consisted of three to seven persons. The downside of this approach was that we did not always have all the knowledge at hand but had to ask asynchronously for feedback. Still, we had enough knowledge available to stay productive and make progress.

Personally I decided to always stay in the mob. As a team player, there was no other option for me. As the person who triggered that we give this approach a try, I was curious how it will work out and did not want to miss this learning experience. And as the only person identifying as tester on the team, I felt staying in the mob was just perfect to trigger tests, provide feedback, raise questions, and seek answers as soon as possible. This way, I felt another downside of the dynamic mob size: As some teammates decided to work on their "own" stories, I missed to provide feedback on those as early as I could (though of course others could have stepped in). Luckily the mob selected a story we needed to complete to achieve our sprint goal, which justified that I spent all my efforts there first.

After we finished our story, I was feeling proud. This was really a joint team effort and we all had our hands on the story, ensuring quality from different perspectives. But one thing made me think: Shortly before we decided that our changes are ready to be merged, one colleague challenged this by raising the question who does testing of the story. At first this puzzled me, as we had included testing all the way from start to finish. So I answered that the mob tested the story thoroughly. But this teammate was not convinced that you could possibly come up with all necessary tests in the mob.

As he could not tell what else to test, and the current mob agreed that we covered everything from quality perspective, we merged the story nonetheless. But his comment left me wondering. Did we forget something? Should we have something done differently? Should we have not allowed for dynamic mob sizes as particularly this colleague did not join all sessions? Which reasons did he have to think that testing cannot be done in a mob? Is there a trust issue?

Naturally, I don't have all the answers but I will keep an eye on this issue. To gain more insights, I decided to join Maaret Pyhäjärvi's tutorial at Agile Testing Days 2017 about Mob Testing. Still, my biggest hope is that my team continues working on actual stories as a mob to gather more experience ourselves and learn by doing.