A Maze of Brick Walls

When talking to other testers, I love to hear where they come from and where they are heading to on their testing journeys. Listening to those personal stories I search for similarities I can related to, as well as contrasts I can learn from, getting to know the person better at the same time. In a couple of posts I want to share some milestones of my personal testing journey with you. See also the related previous post about My Roller Coaster Years.

---

When the final crisis hit my roller coaster company, our team had to be reduced once again and I had to leave. On my first day at home I received a phone call from a former colleague of a company where I had been working as a student. She told me that they noticed my professional network status change to "looking for job" and that they may have a perfect offer for me, now that I was into testing. I was stunned that the small network I was just building up already paid out!

But when I heard what the job would be about, I started to have misgivings: I should be the test manager for a customer's project, and start within the next few days.

1. They wanted to have me as consultant. I never wanted to be outsourced and work on-site at a customer's place but to work for my own company at our own location. Not to be on my own in a foreign environment but to have a team around me I could bond with.
2. It was about a project. I never strived for temporary projects, jumping from one to the other. I already experienced product development and loved the idea to improve a product for its lifetime. I looked for some sort of stability and consistency. (I'm still not really good with uncertainty but constantly learning how to embrace it.)
3. The project and environment were not agile. I never would have looked for that. You know, I was just coming from a young startup, totally excited about this new way of working I discovered for myself, eager to learn more.
4. The customer was a huge corporation. I never intended to work at a big company, I loved to take over responsibility and contribute to different areas and assumed this was rather feasible in small ones.

Nonetheless I decided to take the job, telling myself that this was too good a chance to lose. That it would be interesting to see a rather "traditional" way of software development, that I could surely share my agile experience, that it would be a challenge I just have to face. And it was a challenge.

• It was an environment totally different from what I experienced so far. It was difficult to gather knowledge about the product in development, its history and the business value it should serve. It took me even more time to get to know all the people, titles, departments, bureaucratic processes, products, tools, abbreviations and "etiquette" of such a big company.
• Suddenly I had to speak English in a multinational company. As you might have recognized I'm not a native speaker. Until then I read English texts at my university and wrote technical documentation in English in my first company, but the last time I spoke it was when I was in school.
• I was deliberately separated from developers. Though I tried to change that, I hardly got a chance to talk to them. Also, most programmers would not provide me any intermediate state of an item to test before they were "done". Testing was seen as a separate phase in the development cycle, with feedback being delivered mostly only once a week. I was fortunate that there was a freelancer programmer on the project sitting right beside me with whom I had great pairing sessions and could implement quick feedback cycles.
• I was asked when testing would be finished at a time when development was not even ready to provide a first version and nobody knew what lurked beneath the surface. What saved me was the great collaboration with another freelancer who was employed as project manager. Together we figured out a rough estimation to meet the demand.
• Collaboration with business people was a tough job in the beginning. Lucky me, a new business owner was appointed with whom I could share my agile experiences. We closely worked together to provide value to our users who complained that what had been developed so far did not meet their requirements.
• I managed several user acceptance tests. The invited power users came from all locations all over the world. Communication was hard due to varying English skills, cultural aspects, and heavily differing demands and intentions. At some points I ended up with about 100 (!) participants in virtual conference calls which made things even harder.
• In general, communication often turned out to take place in a highly political context. Formulating emails became a tricky thing if you wanted to avoid email ping pong having more and more people being copied in. I got the impression of a culture of fear with people striving to cover their back and shift blame. Status reports often showed items as 80% done. When some delivery item was behind time so its status would become "yellow", it happened that it was communicated as a sort of "yellowish green"; which is still green after all, right?

Please be aware that this is meant to show my very personal interpretation of how I experienced things and cannot be considered as objective truth. But to be honest: After the first weeks I knew I did not fit in and had to get out of there. Still, I decided to adapt and learn. In the end I stayed for one year until I finally found my way out. What I learned?

• People come from different backgrounds, experience different things to work or not and have different goals they want to achieve. This might seem quite obvious, but for me it was a real eye-opener. You can share experience, introduce new ideas, provide arguments, but you cannot change any minds without the people themselves. When you keep banging your head against a brick wall it might make more sense to step back and look for other ways.
• I learned that change starts within myself and only I can change my situation. So I told my boss that if I had to stay in this customer project, I had to quit my job. Telling her frankly really took some courage, but I just had to make things transparent. She was shocked! But understanding. And tried to see if there could be any other place in our company where I would be happier. Fortunately, we both learned that one of our internal teams was about to try Scrum and I was thrilled to join this team. Still, my boss heavily appreciated my openness and honesty. Staying authentic paid off for me ever since.
• By experiencing this totally different environment I learned that my original pain points listed above still apply today. This might change over time or not, we will see. (I'm actually not sure about the fourth point anymore as my current company is heavily growing but we still have a great deal of freedom and responsibility.)

Back then I made it a rule for myself to look ahead one year from now but not further. I can pretty much guess where I would stand then, but beyond I have no clue. If I don't see myself one year from now at my current company anymore, I know it's time to change my situation again.

My Roller Coaster Years

When talking to other testers, I love to hear where they come from and where they are heading to on their testing journeys. Listening to those personal stories I search for similarities I can related to, as well as contrasts I can learn from, getting to know the person better on the same time. In the next couple of posts I want to share some milestones of my personal testing journey with you.

---

When I suddenly became the tester on my first development team in 2010, I was a bit scared. We were a small startup company so there simply was no other tester anywhere around. No one who could tell me what I should do, or mentor me on my way. I started by checking any related book we had in our small team library. The few I found served at least as a starting point, but weren't as helpful as I wished for. So I proceeded to learn by doing. Started thinking about what I planned to test for the upcoming backlog item, noted my assumptions, compared them with the actual behavior, searched for answers to my open questions, listed other things I wanted to try, talked to the team, retested fixes, and so on. That worked out well enough for the beginning.

Still I felt there's something amiss: My boss advised me that a tester should be independent from the development team. Seated me in another room, separated from all the others. It was a strange situation and I felt left out. To make it even worse, his expectation of an agile workflow was that the dev team implements a release candidate during one sprint and I test it during the following, while the others (surprise, surprise) already work on the next backlog items. I thought this could not be the way to go and searched the internet for advice. And found lots of it!

So I triggered some changes. I quickly moved back to the development team room to work as closely as possible with our programmers. We all agreed to give it a try and have testing integrated within the same sprint. I planned my test cases during sprint planning and discussed them with my team mates upfront, helping us all to a shared understanding. My tasks were on the same board, and a story was not done until it was tested and issues were fixed. As it happened, I was not only responsible for testing, but also for our user documentation. Inspired by an article by Sarah Maddox how technical writing was done the agile way at Atlassian, we also added having updated user documentation to our definition of done.

All in all, we shortened the feedback cycle heavily. But still, I struggled with two points in particular.

First: I had a great team around me. Some colleagues patiently sat with me and explained technical stuff where needed so that I could test things easier. Other colleagues, however, kept telling me that I would not need to know about technical details, so why wasting time? As I saw that the shared knowledge helped me a lot with testing, I learned that I always have to check myself what I need and what not. The same applied for being invited to meetings. When I hear someone telling me today that I don't need X or don't need to do Y, or don't need to attend Z; it makes me sit up wide awake. Mostly this is exactly what I need to help my testing!

Second: Our regression tests were only manual at that time (besides some unit tests). So to have a potentially shippable product at the end of our two week sprints we reserved the last two days for regression testing, finalizing documentation, etc. Guess what happened: Our programmers got bored and continued working on new things which introduced a bottleneck in the next sprint as they were (again) going faster than the rest of the workflow. With the rest being me, taking care about both regression testing and finalizing our documentation. This was the time when I got hold of the well-known and invaluable classic "Agile Testing" book by Lisa Crispin and Janet Gregory. And they advised: Share the pain. Have the whole team feel responsible for quality. So I convinced the developers to share the manual regression tests with me. You probably heard people saying: You ask a developer to do the same thing twice and he will automate it? Yep, that's exactly what happened, heavily shortening our manual regression test duration.

As a team, we learned a lot more besides that. We learned to heavily inspect and adapt our collaboration. We got a first notion of what agile is all about. We also learned what financial safety means. In the end, our startup didn't make it; though our product had great potential, there was no market for us. But personally, I took a lot from these exciting roller coaster years with me, getting started on my testing journey.

How I Fell into Testing

Let me tell you the story of how I became a tester. To be honest: That I could do something like that never occurred to me until I actually did it.

If you had asked me as a child what I want to be when I've grown up, I would have told you something like robber's daughter, or artist, or that I simply could not imagine how it would be like as a grown-up.

If you had asked me as a teenager what I'm planning to do for a living, I would have told you that I really don't know. That we did some tests at school to identify our strengths and potentially fitting jobs; but they weren't quite helpful. That maybe teaching art might be awesome.

If you had asked me as a university student why I selected sinology as my major subject and what I wanted to do with it afterwards, I would have told you that I chose it purely out of interest. The point was that I always knew that I wanted to go to university, but I simply could not imagine which profession I wanted to pursue later. Side jobs only showed me what I did not want to do. As I was aiming for a liberal arts oriented degree, I would be a lateral recruit in any case so I would have to learn on the job.

Then the time came to select the topic for my master thesis. And I suddenly had a "crazy" idea: Let's combine it with a topic I love! I was quite surprised that my professor accepted when I told him that I want to write about computer games in China. But great, that worked out!

When I finally received my master's degree and I started searching for a job I thought: Why not take that further? When I could write about computer games, then what if I tried to get a job in the games industry? If not now, when then? Lucky me, I was hired by a small startup developing AI middleware for computer game developers. What a fascinating topic to work on! And no, I didn't apply as a tester. I did not yet think of that. Instead, I started as game designer. I honestly don't know how I got this chance without having any experience in this area, except for my passion for computer games, but it was one of those turning points in life. And my first contact with software development.

So how did I finally fall into testing, then? Well, the former tester quit his job one year after I started - and my boss offered me his position, telling me in the same breath that I wasn't so good as game designer after all; but that testing would fit me perfectly. I was shocked. My bubble had suddenly burst. And then I decided to give it a try and become the tester on the team.

It was one of the best decisions I've ever made. I quickly learned my boss was right - I finally could apply my strengths and much better contribute to the team. And I enjoyed it so much that I realized: This is it.

Recently I stumbled upon the article "Testers: The Origin Story" which nicely fit to what I wanted to write about. It seems I was not the only one who didn't consider "software tester" for their list of potential professions. And that I wasn't the only one starting in the games industry, either!

So if you would ask me today: What is it that you want to do? I'd tell you that I already do it. I want to test to develop great products to delight our users. I want to tell and show people how awesome it is to work if you love what you do. How happy you can be. Follow your passion.

Leap in the Dark

This is the story of how I joined the agile testing community.

It all started with Twitter. Beginning of 2011, I would have told you that I cannot see any reason why you would possibly have a Twitter account. I just couldn't see the value of such short messages.

Well, little did I know. Mid of 2011 my company at that time was in a severe crisis and desperately tried to acquire new customers to survive. One our our marketing attempts included creating personal Twitter accounts, so I started reading a lot about Twitter. Something which got stuck: One blogger compared reading and commenting blogs to having sophisticated discussions in a café where you spend time with a few people; and in contrast Twitter to having quick, nonbinding chats in a bar where you can quickly turn to the next one or simply leave. Unfortunately I cannot remember the source, but this comparison helped me a lot to better understanding.

During my first steps with Twitter I discovered that you can find a whole bunch of valuable information and insights on this platform. That you can directly follow subject matter experts. That it's a real gold mine if you follow interesting people. So I started following authors of books or blogs which had helped me learn more about agile development and software testing. And enjoyed their sharing of wisdom, experience and interesting resources.

And suddenly I realized the value of Twitter for me: I use it for learning. Just to get me right: I am not a regular Twitter user. I stop by when I got time and mood. Some months I don't even check my Twitter client once. Then there are weeks when I regularly follow the streams. From time to time I tweet my own thoughts or re-share the most inspiring pieces. But when I visit the Twitter bar, it's always about learning.

As one key learning, Twitter showed me that there is a very active agile testing community. That a lot more people are out there having the same questions, facing similar challenges, sharing the joy to learn, caring for each other. That the experts of this community are readily supporting with whatever problem you might have. That we are all humans trying to grow.

Last week I attended the Agile Testing Days for the second time. I learned about this conference on Twitter and knew I had to take any opportunity to get there. During my first short visit in 2015, I learned that the community I encountered on Twitter is not only a virtual one but also exists in the real world, with everybody welcoming newcomers and openly sharing their experience. It was simply awesome. This year I could stay for the full week which was even more awesome. I could fill pages about all the new insights, ideas and people I took with me, but let me just share one thing. I still hear the words of Abby Fichtner in her most inspiring opening keynote when she cited Eleanor Roosevelt: "Do one thing everyday that scares you."

So what scares me? I'm thinking about starting a blog for quite some time now, always hesitating, always fearing that I could not meet my expectation; that if I start a blog, it should provide value to the rest of the world. Asking other conference attendees for advice, I learned the following from Llewellyn Falco: If you blog, then blog for yourself to learn. If nobody cares, you have nothing to fear. If somebody cares, great. So don't overthink it. And by the way, if you give a talk, give the talk to you, one year ago.

On that note, to myself, one year ago: This is the story of how I finally started to blog. Be brave. Just do it.