Mirek Długosz personal website - personalhttps://mirekdlugosz.com/2023-11-04T13:39:01+01:0010 years in testing2023-11-04T13:39:01+01:002023-11-04T13:39:01+01:00Mirek Długosztag:mirekdlugosz.com,2023-11-04:/blog/2023/10-years-in-testing/<p>Exactly 10 years ago I started my first job as a software tester.</p>
<p>That doesn’t mean I started testing 10 years ago. Back when I was in high school and at university, I did spend some time doing testing and quality-related stuff for various open source projects - Debian, <span class="caps">KDE …</span></p><p>Exactly 10 years ago I started my first job as a software tester.</p>
<p>That doesn’t mean I started testing 10 years ago. Back when I was in high school and at university, I did spend some time doing testing and quality-related stuff for various open source projects - Debian, <span class="caps">KDE</span>, Kadu, LibreOffice, Cantata, and some more. I don’t remember any longer which was the first and when exactly that happened. I imagine my first contribution was pretty uneventful - perhaps a message on users forum, a response confirming this is a bug, and an encouragement to report it on bug tracking system or devs mailing list.</p>
<p>Nonetheless, “first job as software tester” is a good place to start counting. First, it’s easy - I have <em>papers</em> to prove the exact date. Second, from that day I have spent about eight hours a day, five days a week, every week, on testing-related things. That adds up to a lot of time, but it’s the consistency that sets it apart from any open source work I have done. Last but not least, the decision to start this specific job set me on a path to treat testing much more seriously, and which eventually led me to where I am today.</p>
<p>I’m not much of a job hopper. In these 10 years, I have only had two employers. But I did change teams and projects quite a lot - I’ve been on 4 projects in first company, and now I’m on my 5th project in second company. The longest time I’ve ever been in a single project is 2 years and 7 months. Details are on <a href="https://www.linkedin.com/in/mirekdlugosz/en">LinkedIn</a>.</p>
<p>I came into testing after getting a degree in sociology. In my time at university, I had an opportunity to get my feet wet in empirical social research. I approached testing the same way I approached empirical sociology, even if only because I didn’t really know anything else - I assumed there’s a number of things the team would like to know and my job is to learn about them and report my findings. The hard part is that we don’t have direct access to some of the things we would like to know more about, so we need to depend on a number of proxies of uncertain reliability. X can be caused by Y, and we observed X, but is this because of Y, or some other factor Z? How can we rule out Z? Today, I can confidently say this is not the worst way to approach testing.</p>
<p>When I started my first job, I have been using Linux as my main operating system for about 7 years. During that time I learned how to use shell, I got familiar with the idea that things change and move around, I faced various breakages after updates. Often trying to fix them was frustrating, but I did learn how to search for information, I picked up few tricks and I learned how various components can interact in complex system. That was another major source of experiences that influenced my approach to testing.</p>
<p>I guess I also have certain character traits that helped me to become a decent tester. I tend to be stubborn, I don’t give up easily, I self-identify as perfectionist and I strive to actually <em>understand</em> the thing I am dealing with.</p>
<p>After a year and a half I decided that I want to know more about testing, especially established testing techniques and solutions. My work was praised, but it was all based on intuition and past experiences from other fields. I felt I was missing fundamentals and I feared I might be missing some obvious and elementary testing techniques or skills. I tried to fill these gaps by attending an <span class="caps">ISTQB</span> preparation course, but it did not deliver what I was looking for.</p>
<p>My manager knew about my disappointment and at one point presented me with the opportunity to attend a testing conference in another city. One of the talks given there was called <a href="https://www.youtube.com/watch?v=RMaFZU2qhUA">“Context-Driven Testing: A New Hope”</a>. This is a funny title, as Context-Driven Testing was already 15 years old at that time and “schools of testing” debate has long left community conciousness. I don’t remember many details of the talk itself, but I did left the conference with a feeling that I should learn more about <span class="caps">CDT</span>, as they might have at least some of the answers I was looking for.</p>
<p>I think I started by reading <a href="https://www.goodreads.com/book/show/599997.Lessons_Learned_in_Software_Testing">“Lessons Learned in Software Testing”</a>, and what a book it was! It not only revolutionized the way I think about testing to this day, but also gave me much-needed confidence. I found I was already doing some of the things that book recommended, but now I knew <em>why</em> they were worth doing. This is the book that everyone who is serious about testing should read, and probably re-read thorough their career. I think I read it at very good moment, too - I had about three years of experience at the time. I feel I wouldn’t get that much from it if I read it earlier.</p>
<p>Later I have read <a href="https://leanpub.com/perfectsoftware">“Perfect Software”</a> by late Jerry Weinberg. I think this is a great book for people who just start in testing. It surely helped to establish some of my knowledge, but I don’t think it was as influential for me as “Lessons Learned”. It would have been if I read it earlier.</p>
<p>Finally, I have read the complete archives of <a href="https://www.satisfice.com/">James Bach</a> and <a href="https://developsense.com/">Michael Bolton</a> blogs. This is not something I can recommend to anyone, as both are very prolific writers - each authored few hundreds articles. I think it took me well over a year to get through them all. Nonetheless, this allowed me to fully immerse myself in their thinking and I can confidently say I understand where they are coming from and where they are going to. This also allowed me to stumble upon few very valuable articles and resources that I still refer to.</p>
<p>There’s a lot that I learned from all these resources, but I would like to point out two overarching principles that I often come back to. One, my role as a tester is to show possibilities and broaden the view of the team. My job is to go beyond simple and quick answers. Two, every single day I need to ask myself: what is the most important, most impactful thing I can do right now? And then do this exact thing, even if it means putting aside earlier plans and ideas. Change is something to embrace, not to be afraid of.</p>
<p>About five years into my career, I began to slowly move into more software development-heavy role. To some extent, that was out of necessity - I saw many tasks that could be rectified with a tiny bit of programming. At the same time, I was in the environment where development was considered higher on organizational totem pole than “manual testing”, and showing programming skills was a clear way for more respectable assignments and higher salary. Similar to my testing journey, that was not the moment I started to learn programming - I have written my first shell scripts and perl programs back in high school. While I did struggle, I felt confident enough in my programming prowess to do some simple things.</p>
<p>The event that really helped me to take off to the next level happened about a year after I joined Red Hat. We had a <span class="caps">UI</span> test automation framework, which was recently rewritten by a couple of contractors. They worked in a silo and as a result most of the team was not familiar with that code. My job was to learn it, contribute to it and become one of the maintainers.</p>
<p>I think contractors felt threatened by my presence and thought their job security depended on them being the only people capable of working with the framework. As a result, they made code review a nightmare. They threw it all - passive-aggressive comments, unhelpful comments, misleading comments, requests to change code that was already approved in earlier review cycle, demands to explain almost every single line of code, replying anytime between a day and a week. That was all on top of working with unfamiliar, complex and barely documented libraries.</p>
<p>I don’t look back at that time with fondness, but I have to admit it was an effective learning exercise. I was forced to understand things above my capabilities, and eventually I did understand them. This was very much the moment programming finally clicked for me. Also, I learned precisely what to avoid during code reviews and when teaching others.</p>
<p>Since then, my interests started to move more in direction of software design and architecture. I know I can write good enough code that works. But I also want to write code that is maintainable in the long term and allows for adjustments in response to changing environment or requirements.</p>
<p>In these 10 years, I have primarily been an individual contributor. This is the role I feel comfortable in and which I think suits me well. However, I did act as a kind of team lead in two separate occasions. Both times I was not formally a manager for other people and I didn’t feel I have all the tools necessary to make them do the required work. The first time I was completely unprepared for a challenge in front of me. The second time went a little bit better, as I knew more about ways to informally influence people.</p>
<p>These would be the rough summary and most important highlights of my 10 years in testing. There’s no narrative closure, as I am still here and intend to stay for a while longer. I’m happy to talk about testing, open source, software engineering and related topics, so feel free to <a href="https://mirekdlugosz.com/contact.html">get in touch with me</a> if this is something you find interesting, or if you would like to draw from my experience.</p>So IBM is acquiring Red Hat2018-10-29T12:37:20+01:002018-10-29T12:37:20+01:00Mirek Długosztag:mirekdlugosz.com,2018-10-29:/blog/2018/so-ibm-is-acquiring-red-hat/<p><a href="https://www.redhat.com/en/about/press-releases/ibm-acquire-red-hat-completely-changing-cloud-landscape-and-becoming-world%E2%80%99s-1-hybrid-cloud-provider?intcmp=701f2000000RWK2AAO">Big news</a> hit yesterday evening.</p>
<p><a href="https://www.redhat.com/en/about/press-releases/ibm-acquire-red-hat-completely-changing-cloud-landscape-and-becoming-world%E2%80%99s-1-hybrid-cloud-provider?intcmp=701f2000000RWK2AAO">Big news</a> hit yesterday evening.</p>
<p>It’s way too early to tell what this means for open source communities or bigger technology landscape. Or me personally, for that matter.</p>
<p>But one thing I wanted to point out is impact on open source economics. While open source software became backbone of Internet and allowed a lot of companies to exist and grow, it has been ridiculously hard to monetize. Red Hat, the biggest open source company in terms of revenue and number of employees, growing like crazy from quarter to quarter, shows that it is possible to create successful and viable business around open source software, principles and values. It is both poster child and role model for many people who dream about earning a living by creating open source software.</p>
<p>For me, acquisition of Red Hat is testament that it was not viable long-term business strategy after all.</p>
<p>It’s interesting to see what paths discussion about economics of open source software will take now. I believe we need solutions more than ever before.</p>createPokémon.team retrospective2018-07-12T21:42:49+02:002018-07-12T21:42:49+02:00Mirek Długosztag:mirekdlugosz.com,2018-07-12:/blog/2018/createpokemon-team-retrospective/<p>Last week I announced release of <a href="https://createpokemon.team/">createPokémon.team</a>. It took about three months of my free time, out of which one was “full-time”. During that time, I had some ideas and observations that I wanted to share in this blog post. It crosses into rant territory at times.</p>
<p>Last week I announced release of <a href="https://createpokemon.team/">createPokémon.team</a>. It took about three months of my free time, out of which one was “full-time”. During that time, I had some ideas and observations that I wanted to share in this blog post. It crosses into rant territory at times.</p>
<h2 id="three-times-a-charm"><a class="toclink" href="#three-times-a-charm">Three time’s a charm</a></h2>
<p>The version I have released is the third iteration of the basic idea for the tool. Each subsequent revision had more features and took more time to create. It also happened that each was rewritten from scratch, as they were all using different programming languages.</p>
<p>Overall, I am happy that I took this approach. It allowed me to have <em>something</em> early in the process - something that I could play with to see what is working, what might not be working and what might be missing. It allowed me to refine my ideas how this tool should look like and behave. And it solved my immediate problem, even if it could have solved it better.</p>
<p>I remember that long time ago, I read on some programmer blog that you need to create your project three times to get it right. I wouldn’t hang on to number three too much, but I believe that gist of that advice is true - you are unlikely to get everything right on your first try, so it’s better to create something quickly, learn from it, discover problems that lie ahead and prepare for them.</p>
<p>(The question what does it mean to “get it right” remains unanswered.)</p>
<h2 id="perils-of-modern-frontend-development"><a class="toclink" href="#perils-of-modern-frontend-development">Perils of modern frontend development</a></h2>
<p>I created my first website in early 2006. Back then it was very important for thought-leaders to teach newcomers about separation of concerns - that <span class="caps">HTML</span> is for basic structure, that <span class="caps">CSS</span> is for looks and JavaScript is for dynamic behavior, and that you should never mix them up. Simple website could consist of two or three files (depending on whether it was static or dynamic) and it could be created in dead simple editor like Windows Notepad. If you wanted to change something, you just changed file on disk and pressed Refresh in browser. When I started, it was relatively easy to grasp everything that is going on and how different pieces fit together.</p>
<p>That is no longer the case.</p>
<p>Today, you need to choose <span class="caps">CSS</span> pre-processor and language flavour that will be compiled to JavaScript. There are different package and module managers operating at different levels. There are <span class="caps">CSS</span> and <span class="caps">JS</span> minifiers. If you are serious about your website, you need to choose unit checking framework - and some of them have generic, pluggable architecture with different solutions for assertions, check running, result gathering and reporting. Everything is tied up by one of at least three different task runners. And these are only things that I cared to recognize - I’m sure that there are more tools in pipeline.</p>
<p>If that’s too much for you, you can choose to use one of so-called “opinionated” frameworks that made most of decisions for you. One of them is Angular. Canonical way to get you started is running <code>ng new myproject</code> in command line. It creates 30 files and pulls in <strong>1100</strong> packages that take over <strong>350 <span class="caps">MB</span></strong> of disk space combined. To see anything in your browser, you have to compile the project (!) and wait for about 10 seconds.</p>
<p>Compare that to AngularJS, where all you needed was additional library in <span class="caps">HTML</span> header and some simple controller in separate file.</p>
<p>Mental and computing resources required to start frontend development exploded in last couple of years. I feel bad for people starting today, as they will either feel overwhelmed and discouraged, or will learn to ignore fundamentals they build upon and just go with what everyone else seems to be doing - a very dangerous trait for developer.</p>
<h2 id="angular"><a class="toclink" href="#angular">Angular</a></h2>
<p>As mentioned above, AngularJS was easy to grasp at basic level. You would expect newer and improved version to be similar, right? You would be wrong.</p>
<p>Angular is all about enterprise-ready, platform-independent architecture. There are modules, components, directives, pipes and services - all having their own place in the grand scheme of things and all working with the rest in pre-specified ways. You can’t just put together few methods from basic library and have <em>something</em> - you have to design it carefully first. Which is not necessarily wrong, but definitely overwhelming and time-consuming. It must have taken me few evenings of reading about Angular before I could write single useful line of code.</p>
<p>It took me some time to realize, that Angular has <strong>constant complexity</strong>. It’s hard to create simple application in Angular, but creating complex system is not that much harder. This is curse for small projects and god-send for large ones. And I can’t bring myself to <em>like</em> this approach - I much prefer Python, where simple things are simple and complex things are possible.</p>
<h2 id="test-driven-development"><a class="toclink" href="#test-driven-development">Test-driven development</a></h2>
<p>Angular is created with testability in mind. Its tooling tries very hard to make it easy for developer to write checks, even generating some basic ones by default. This was one of the reasons why I decided to stick with Angular, despite being repeatedly bitten by its complexity. One of the goals of my tool was to show that I am capable of creating automatic checks.</p>
<p>Test-driven development is very popular these days. The basic idea is that you write automatic checks first, and then develop program that would pass these checks. Much has been said about benefits of this approach and some people introduce the concept to beginner programmers.</p>
<p>I wanted to share some impressions about <span class="caps">TDD</span>, but I can’t for very simple reason - it’s nigh impossible to implement when you are not familiar with the language in which checks are written. <span class="caps">TDD</span> might work when you are able to sit and write a couple dozen of checks, but there is no way it is going to work if you constantly question whether basic language constructs actually do what you think they are doing. And since TypeScript was new for me (and JavaScript has some unpredictable behaviors here and there), that was exactly the case. I never wrote these automated checks.</p>
<h2 id="builder-and-tester-mindset"><a class="toclink" href="#builder-and-tester-mindset">Builder and tester mindset</a></h2>
<p>I self-identify as a tester. It is my job and my duty to seek better understanding of product, question what is obvious, provide valuable information, identify risks and areas of uncertainty and suggest improvements. For the tester, every bug discovered, every trail of a bug that might be hiding somewhere close, gives a feeling of excitement and engagement; the more complex the problem, the more intense the feeling.</p>
<p>When I was creating the tool, I had to constantly switch builder and tester hats. This showed me that things that I value as a builder are different from things that I value as a tester; my priorities and my emotional reactions are different as well.</p>
<p>As a builder, I care about clean, simple and maintainable code. I want to introduce changes that fit nicely into existing architecture and in a way that follows established conventions. I know which part of the code I am intimately familiar with and which are more vague. I know where I had to push myself to the limits and where it was easy for me to keep going.</p>
<p>As a builder, I was afraid and paralyzed by some of the bugs that I have discovered as a tester. I was reluctant to dig into more complex parts of the code. In my angst that I will discover something that will require me to tear down most of what I have build so far, I wished I <strong>don’t test anymore</strong>.</p>
<p>Differences in mindset of tester and builder seem interesting and important. I feel they deserve further exploration. I will probably pick it up in future blog post.</p>Why I love Pokémon2018-07-01T20:39:49+02:002018-07-01T20:39:49+02:00Mirek Długosztag:mirekdlugosz.com,2018-07-01:/blog/2018/why-i-love-pokemon/<p>This is software release announcement disguised as impressions on pop culture phenomena.</p>
<p>This is software release announcement disguised as impressions on pop culture phenomena.</p>
<p>I discovered Pokémon when I was a kid, back around year 2000. I watched every episode of anime that was on <span class="caps">TV</span> with almost religious commitment. I bought a lot of cards and I played with my friends and neighbours. I read every single article in kids magazine I could find. I saved my pocket money for months to buy Game Boy and Pokémon game (I wanted Red or Blue, but they only had Silver in the store). I vividly remember in-game clock going over 99 hours mark.</p>
<p>I think it’s fair to say that I was a huge fan. But eventually Pokémon craze died out and I moved on to other things.</p>
<p>I re-discovered Pokémon in 2015. I was on strong medicines then and I needed something that would keep me occupied without requiring my full attention. After some discussions with my girlfriend, we decided to buy <span class="caps">3DS</span> with Pokémon Y. </p>
<p>That game was great. Beautiful 3D graphics. Few hundred unknown creatures (remember, I was familiar only with first 150 Pokémon and some from generation <span class="caps">II</span>). Unique Pokémon catch list in almost every route, giving impression of almost real-life ecosystem. Pokémon Amie that allowed us to create real, even if extremely shallow, relationships with our Pokémon. Surprisingly deep and complex battle and team building mechanics. Global Trade System, where I could trade Pokemon for the first time in my life. What was supposed to be innocent distraction at harder times turned out to be extremely engaging and fun experience that took embarrassingly huge amount of my time.</p>
<p>Around mid-2015 I started toying with idea of Pokémon team builder application. I wanted to have one team that could defeat any trainer. Back then I still wanted to enter data science market and was using R extensively, so I decided to try and code something in that language. I chose Shiny for <span class="caps">UI</span> - not because I wanted to publish my work, but because it was easy way of creating graphical UIs in R.</p>
<p>That version was extremely simple - you could choose six Pokémon and <strong>type</strong> (not actual name) of four attacks for each of them. Below the form, there was bare-bones table filled with cryptic numbers. There was no data validation (you could choose type of move that given Pokémon couldn’t use at all). There was no way of mapping type with particular move that Pokémon knew. Moves that didn’t do any damage had to be omitted. There was no way to preserve team across sessions - form had to be filled after each restart of app. It was low-quality software that provided huge value.</p>
<div class="gallery">
<figure>
<a href="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/shiny_1.png">
<img src="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/shiny_1-min.png" title="R Shiny app - team builder form" alt="R Shiny app - team builder form" loading="lazy">
</a>
</figure>
<figure>
<a href="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/shiny_2.png">
<img src="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/shiny_2-min.png" title="R Shiny app - team details" alt="R Shiny app - team details" loading="lazy">
</a>
</figure>
<figure>
<a href="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/shiny_3.png">
<img src="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/shiny_3-min.png" title="R Shiny app - team overview" alt="R Shiny app - team overview" loading="lazy">
</a>
</figure></div>
<p>Fast forward to December 2016, I was expecting to switch teams inside my company and become responsible for writing automated tests in Protractor (pardon my French, that was before I discovered Bach and Bolton who taught me that testing can’t be automated). I didn’t have any experience with Protractor and was eager to get some fast. Pokémon Moon was still fresh on my mind, so I added pieces together again and decided it’s time to rewrite my old Pokémon team builder Shiny app in AngularJS.</p>
<p>After few weeks I had <em>something</em>. The basic idea was the same - you select six Pokémon and their moves (by name or type!) and get table with cryptic numbers in return. But non-damaging moves were ignored, team definition was stored in <span class="caps">URL</span> (as base64-encoded <span class="caps">JSON</span> object…) and it run in real browser! Sure, it was readable only on computers, entire frontend was unmaintainable mess in single JavaScript file and I never wrote these Protractor checks, but it was so much better.</p>
<div class="gallery">
<figure>
<a href="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/angular_1.png">
<img src="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/angular_1-min.png" title="AngularJS app - team builder form" alt="AngularJS app - team builder form" loading="lazy">
</a>
</figure>
<figure>
<a href="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/angular_2.png">
<img src="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/angular_2-min.png" title="AngularJS app - team details" alt="AngularJS app - team details" loading="lazy">
</a>
</figure>
<figure>
<a href="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/angular_3.png">
<img src="https://mirekdlugosz.com/blog/2018/why-i-love-pokemon/why-i-love-pokemon/angular_3-min.png" title="AngularJS app - team overview" alt="AngularJS app - team overview" loading="lazy">
</a>
</figure></div>
<p>This project and potential of what it could become was lingering on my mind more or less constantly since then. I had so many ideas on how it could be improved. Support all core Pokémon games. Work on mobile devices. <em>Look nice</em>. Keep team definition in <span class="caps">URL</span> in readable format. Use Angular (not to be confused with AngularJS). I wanted to finish it before job hunting. I wanted to finish it before Ultra Sun and Ultra Moon release. I wanted to finish it before returning to Poland.</p>
<p>And I finally did finish it today.</p>
<p>Head on to <a href="https://createpokemon.team/">createPokémon.team</a> to see the results of couple of months of my work. There are still some things that could be implemented or improved, but overall I feel happy and proud of what I have achieved. You can find source code on <a href="https://github.com/mirekdlugosz/create-pokemon-team/">Github</a>; there is also ever-growing <a href="https://github.com/mirekdlugosz/create-pokemon-team/issues">list of known issues and improvement ideas</a>. Feel free to poke around the code, comment on issues and send a <span class="caps">PR</span> or two!</p>
<p>And that’s why I love Pokémon. They inspire me to learn, create and share with others.</p>