Having a powerful computer in your pocket all the time is as much a curse as it is a blessing. Especially when the computer is constantly connected to multiple communication applications. (I won’t even mention entertainment.)
Most of my conversations recently start with: “After reading too much Cal Newport…” Of course it’s a joke. You can never read too much Cal Newport. Even if you’ve read all of his books. Then you preordered one that’s not published yet. While waiting for the preordered book to arrive, you listen to his podcast. Even if you’ve read his books on how to study long after you’ve finished school. My excuse is that I have kids that are still in school.
For years, I didn’t have much trouble keeping up with all the communications channels I used privately or for work. I’ve added them one by one, as needed. I have just assumed the increasing number of communication channels is the way things are.
Last year I went on parental leave for a few months. After I returned, I could not catch up. I went on long vacations before. (By long I mean a few weeks. Two or three weeks of vacation during summer is something I do almost every year.) I remember struggling to catch up with all the things after a few weeks of being away. This time, after a few months, I have realized it’s a lost battle. There’s more stuff coming in than you can process.
So, what’s all the things coming in? Good question. Let’s just list work related things.
I don’t install apps on my desktop. I only use the communication tools from a browser.
I don’t have tools that I don’t use opened. If I need email or slack, I’ll only have it open for the shortest possible time.
I don’t have almost any notifications enabled. Both on my desktop and phone. (There are a few exceptions. People that might need to reach me in an emergency know how to do that.)
Decreasing communication is not the goal. The goal is having enough uninterrupted time to do your job. My job is to write code. My job is not to communicate constantly. Twenty years ago, when I started my career, the problem was that it was hard to communicate. Today, the problem is that it’s too easy to communicate. The tricky part is finding the right balance. At the moment, I think we err on the side of communicating too much. I’ll see how my experiment with reducing communication channels works out.
]]>In early 2017 I collected some numbers from the previous years and wrote a blog post titled 2016. A blog post about numbers? How very exciting.
Well, I had fun. In fact, I had so much fun that in early 2024, when I was thinking about writing a blog post, I remembered how much fun it was. (Let me explain how rare that is. By that I mean - me remembering pretty much anything. I can barely remember what I did in the morning. Remembering something that happened in early 2017 is very close to a miracle.)
So, in early 2024, after receiving (one) (several) way too many “year in review” emails from various online services, I thought it could be fun to get some data and write a blog post about 2023.
Getting data for just one year doesn’t really tell a story, so I tried to collect as much historical data as I could, without spending a lot of time on it. 2016 blog post says:
There is a story behind the numbers, but I have spent the time for this blog post collecting the numbers, so the story will have to wait.
That post was one of my first experiments in internet archeology. I wanted to avoid that scenario this time. (By that scenario I mean spending all the time collecting the data, so there’s no time for a story.)
So, the plan:
I still had the data from 2017 in a spreadsheet that I could use for inspiration and reference. I created a new chart because I didn’t want to mess up that historical and priceles data.
Because of #1 (spending as little time collecting as much data) I decided to gather data only from services that would not fight me. Or at least, they would not fight hard.
I started using Audible in 2015. Trend is upward. Not in the 2016 post.
In 2016 I didn’t know how important audio books would become in my life. I listen to about an hour or two of audio books a day.
I’ve been publishing on this blog since 2005. Trend is downward. Also in 2016 post.
I publish a post or two a month. I have changed the software and hosting several times. I really enjoy it, but I have very limited time for it.
I started using Duolingo in 2020. Trend is upward. Not in the 2016 post.
I could not find data for 2022. Maybe I’ll find something if I dig deeper. I use it 5-7 minutes a day. My German has never been better. (I recently traveled to Germany and mostly used English there. That’s how good it really is.)
The data is from my blog, so since 2005. Trend is upward. Also in 2016 post.
I used to go to a lot of events. I used to speak at events and help organize them. I decided to decrease my attendance at events just before COVID. Then, COVID happened and there were no events to attend, so I didn’t have any trouble with that decision. I enjoy going to events, speaking at them and organizing them. It’s also a lot of time and work.
I started using Geocaching in 2019. Trend is downward. Not in the 2016 post.
I was introduced to geocaching at a conference. I struggled to find my first cache on my own, but somehow, eventually, I managed to find one. Since then I’ve found many caches and hidden a few.
I started using GitHub in 2008. Trend is upward. Also in 2016 post.
Little did I know in 2008 how important Git and GitHub will be in my life. I wrote a blog post about my first steps in early 2009. (I wish I could put life in version control. There are some things I would not hesitate to revert.)
I started using Goodreads in 2016. Trend is upward. Not in the 2016 post.
I have always read a lot of books. I have written a few reviews on this blog. I try to rate and write (usually a very short) review for every book I read.
I started using IMDb in 2017.Trend is upward. Not in the 2016 post.
I’m pretty sure I’m not watching TV or movies more than I used to. Mostly because I don’t have much free time. I rarely watch any TV over the week, and only an hour or two over the weekend. The rising numbers might be caused by me recently discovering I can separately rate each episode of a series.
I started using Strava in 2016. Trend is upward. Not in the 2016 post.
I track most of my activities, from swimming to walking and hiking. Mostly, I track running. I have been commuting to work by bike in the last few years, so those numbers increased significantly.
I started using X when it was still cool and called Twitter, in 2008. Trend is downward. Also in 2016 post.
Twitter. (I still refuse to call it X.) I had a lot of fun on Twitter. I can’t use it any more. For various reasons.
I’m using more online services than I did in 2017. Much more. I also care a lot about a few of those services. I think they are very useful.
I use some services more and more every year, some less and less. Some, like Twitter and Facebook, I stopped using. I have a feeling that is correlated with me reading a lot of Cal Newport.
I wish every service would tell you how many minutes a day (or hours a year) you use them. For some services I would really like to know. For some services I’m afraid to know.
For a few services I use (or I have used) regularly I couldn’t get the data. For example, Facebook is taking forever to create an export of my data. I have to check, but it has been weeks since I have requested it. Some services give you data that you can’t do anything with. Maybe you can get something, but I didn’t really try hard.
In any case, this was interesting. I’ll continue gathering more data. I’ll try to update the post as I gather more data.
]]>At work, I’m a member of the Quality and Test Engineering Team (QTE). My team is a part of a newly formed bigger team, Developer Experience (DevEx). The bigger team had an offsite in San Francisco, California, USA.
I work remotely. For decades. Before COVID, I would see my colleagues a few times a year. All travel stopped with COVID. The last time I saw people from QTE was in 2020.
QTE used to be a part of another bigger team, Engineering Productivity. That team had a couple of virtual offsites in 2020 (May, October).
I don’t like virtual offsites. They are better than nothing, but in essence it’s just more of what we do regularly. Video meetings. It’s hard to organize virtual offsites for various reasons. One big problem is time zones. The team is spread over many time zones. Some people are in the west of America, some people are in the east of Europe and Africa. That’s a lot of time zones. Nine if my calculations are correct. That means that I’m pretty much done with the day when Americans are just waking up.
In person offsites are hard to organize too. But they are worth it. It’s very hard to get people from several continents and countries to the same place at the same time. Visas make the problem even harder. As far as I know, at least one person could not join us because their visa was rejected.
It was great to see people from both the QTE team and the DevEx team.
It was great to see people from the DevEx team because I know most of them but I don’t work with them regularly. Hearing perspectives from people I don’t interact with usually is eye opening.
It was great spending more time with people I work with day to day. We had so many things to discuss that a day that was scheduled for our team was just not enough.
I wish we had a week of the DevEx offsite where we could talk with people from other teams. Additionally, I wish we had a separate QTE offsite where my team would have a week just for us.
I think the social time at offsites is probably the most important part. We are pretty good at working remotely. We are pretty bad at socializing remotely. It’s just very hard to do.
A few of us met a few times for a 6.30am run. It was part exercise, part socializing. I was hoping one or two people would join me for the run. We had from three to five people running. That exceeded all of my expectations.
I made up a fake saying:
The best conversations at offsites happen at 11pm over a beer or at 6am during a run.
I got into chess recently. I have organized a few informal chess workshops at various in person or online events. I was moderately happy with those workshops. This time I decided to run a one-on-one workshop as many times as there is either interest or time. I called it “zero to hero”. (I know. Amazing branding.) The participant would first play a quick game against a level 1 chess.com bot. I would just observe the game to get an idea of the approximate rating of the participant. In the second game, I would introduce the first opening rule (conquer the center). In the third game, I would introduce the second opening rule (activate pieces). In the fourth and final game, I would introduce the third and the final opening rule (king security). The point was to introduce people to opening principles without overwhelming them. It was a lot of fun. I have received positive feedback from the participants.
One day during the offsite, we had a Christmas party. Guests were allowed. I saw my first manager. (He no longer works there.) That was a blast from the past.
The final day of the offsite was no work, all fun. Most of us went to Muir Woods . It was great. I love walking in the woods. I wish the entire offsite was a series of long walks in the woods.
]]>Black Box Testing by Boris Beizer is one of the early books on software testing. It was published in 1995, so it’s almost 30 years old.
Beizer is a well known author. He has published several books on software and software testing. His most famous books are Software Testing Techniques and Software System Testing and Quality Assurance. There’s a reason this book is not one of the most famous ones. (Bret Pettichord in Four Schools of Software Testing by Petticord puts Beizer in Analytical School.)
It’s more than 300 pages of almost pure boredom. The book tries to make software testing as complicated as possible by insisting on using graphs. It has almost no practical application.
The book is not at all relevant to the way software is developed today. I doubt that it was ever relevant. That said, I am frequently wrong. I could be wrong about this book. But I’m pretty sure I’m not.
If I was about to write the worst book about software testing possible, and I did everything opposite from what I thought makes sense, I would probably end up with a similar book.
The book has both a synopsis at the beginning of the chapter and a summary at the end, for most chapters. I like that in a nonfiction book.
Every chapter has a vocabulary section.
It starts with a list of words with no explanations. If you read on a Kindle, you can quickly look up a word in a built-in dictionary, Wikipedia or translate it to another language. I’m not sure what people did when the book was published. They had a dictionary and an encyclopedia nearby?
The vocabulary ends with terms with explanations. Explanations are as relevant as the rest of the book.
I was mostly scanning the vocabulary section, trying to use as little of my brain as possible. But then, that’s how I read the book in general.
Every chapter has a self-evaluation quiz at the end. I do like that in a book. In this book, it is done in such a horrible way, it’s almost funny. Let me give you an example from the quiz from chapter one.
Define: analysis, behavioral testing, black-box testing, blind, bug, bug-free, case (…) unit testing, validation, validation criteria, white-box testing. (Introduction, page 55.)
I hope you get the picture. The quiz is just an alphabetical list of terms that you’re supposed to look up in the chapter and try to define. I would probably take you several times more time to do that than it took to read the chapter. In general, I don’t think that’s bad. I like challenging tasks. But, since reading this book is already only wasting your time, don’t waste even more time on looking up definitions.
To be fair, some chapters do have tasks in the quiz that are more than just defining the term. But, those tasks are also a waste of your time, so you should not do them.
There’s no reason for you to read this book. There are plenty of good books on software testing available.
My team’s book club has covered a few good books:
Read any of those books. Don’t read this one.
I’m not even sure where to start. Chapter 2 (Graphs and Relations) I agree that being able to create good graphs is important in software development and testing. But, I don’t see the point of so much theory and so little examples. Pretty much every statement in the book should have an example. There are a few examples, but an order of magnitude (if not two) too little. Chapter 8 (Syntax Testing) This chapter seems almost practical. Unlike the rest of the book. I could see myself testing a command line application. However, the way the material is presented makes it completely unusable.
While reading the chapter, I can almost understand the author. That’s not something I can say for the rest of the book. But, I kept thinking how I would rewrite the chapter to make it more practical and understandable.
In case I was not explicit enough so far, I really didn’t like the book.
This is a type of book that you read once, quickly, just to get an idea of what the book is about. Then, you read it the second time, very carefully, trying to actually understand the material. You might need to read some chapters, if not the whole book, the third time, to fully understand it. (Similar to An Introduction to General Systems Thinking by Gerald M. Weinberg.)
This is also a type of book that you read once and never want to read again.
The only reason you might have to read this book is if you have trouble sleeping. I have found that reading this book is a very good way to get sleepy.
I categorize nonfiction books into practical and non-practical. This book is marketing itself as a practical book. I find that as far from the truth as possible.
If I was new to testing and this was my first testing book, I would run away from testing screaming.
I can see how maybe in some context this book could be useful, but I’ve never needed anything like it in the last 20 years and it’s unlikely I’ll need it in the next 20.
I am not sure who could get anything useful from this book. I am surely not its target audience. There are not a lot of Goodreads reviews, but a few Amazon reviews that exist agree with me. Read the reviews. You be the judge.
I have read this book mostly on a Kindle. I prefer to read books there. I am disappointed in the Kindle version. I’m not sure what went wrong with it. Probably somebody just wanted to earn some money on it without putting a lot of effort into the conversion. A few graphs were missing. Some images were at a slight angle. Just enough to make it annoying.
Most of the Kindle version worked just fine, but the graphs were almost unreadable. I had to have the book open in a Kindle application on my computer, just to be able to read the graphs.
I like collecting quotes from books. This book had good quotes mostly only in the first and the last chapter. Maybe I was paying attention only in those chapters. In the first chapter because I didn’t yet get that this will be a horrible book, and in the last chapter I was excited that the suffering will be over soon. In the rest of the book I was probably in some low brainpower survival-only mode.
But if you want to learn behavioral test techniques with a minimum of hassle and prerequisites, then I hope this book won’t disappoint you (page 10.)
Do I even need to say (again) that this book did indeed disappoint me?
As in war and business, there are effective and ineffectual strategies (page 41).
Bugs are caused by complexity and the limited ability of humans to handle complexity (page 43).
Testing is potentially endless, both theoretically and pragmatically. Yet we must stop testing, knowing that bugs remain, because if we don’t stop, the effort is pointless (page 43).
Behavioral testing isn’t all the testing we should do. No single testing approach is enough (page 45).
“The wise navigator never relies solely on one technique” (page 45).
We’d all like a Mercedes for the price of a Yugo (page 45).
This was funny. When I was a kid, my family owned a Yugo. I think it was the first car I drove.
The most important things about a software development process are (1) there is a process, (2) it is understood, (3) it is followed (page 49).
Even chaos is a process of sorts (page 49).
If the process isn’t followed, it’s probably because it doesn’t work (page 50).
Question: What do you do when you see a graph? Answer: Cover it! (page 79).
I am not sure if this is a joke. To be fair, my jokes are usually worse than this one. If this was a joke.
Revealing bugs, not making people falsely confident, is what testing’s about (page 129).
Horrible loops come about when jumping out of the middle of a loop or jumping into the middle of the loop (page 150).
I need to investigate if this is possible to do in the programming languages I know.
About 30 percent of all bugs concern errors in requirements. (…) Approximately 5 percent of all bugs are caused by wrong domain definitions (page 275).
The biggest potential problem with syntax testing is psychological and mythological. (…) The mythological aspect is that there is great (undeserved) faith in the effectiveness of what I call keyboard-scrabbling or Rachmaninoff testing, also called monkey testing (page 338.)
One of the saddest sights to me has always been a human at a keyboard doing something by hand that could be automated. It’s sad but hilarious (page 388).
Manual testing doesn’t work. It never did work very well, it doesn’t work now, and it won’t work in the future. Manual testing is ill-contrived self-deception. It confuses sweat with accomplishment. And worst of all, it leads to false confidence (page 388).
What can be inferred, then, about software’s dependability from the kind of tests that can be executed manually? Nothing! Absolutely nothing! Nothing, nothing, nothing (page 390).
The purpose of structural coverage tools is to give us an objective and quantitative measure of how much of the software we actually have executed by testing. It should be, must be, 100 percent (page 349).
In most systems and software development environments, it is possible to automate test execution for 95 percent or more of all tests. One hundred percent execution automation probably is not desirable (page 397).
Everybody underestimated the time it would take to learn the tools and the underlying techniques and to achieve facility with it to the point that the tool and method were more productive than the old manual way (page 402).
As testers we must strive to put ourselves out of business by promoting bug prevention methods and early bug discovery methods such as thorough analysis, prototypes, analytical models, formal methods (where effective), and inspections (page 403).
I don’t see testing actually disappearing because the remaining bugs (after process improvement) are always subtler and nastier. So I expect testing to get more technical, subtler, and more effective as time goes on (page 403).
Here are my hopes for testing.
- That testing becomes a standard part of the software developer’s undergraduate education. Not just as a one-time, optional course but a mandatory part of the programmer’s education offered at at least three different levels in an undergraduate course of study: Introductory Testing (Black-Box Testing), Intermediate Testing (Integration and System Testing), Advanced Testing (Testing Theory and Algorithms).
- That it keeps pace with our ever-evolving software development process and apparently ever-increasing software complexity.
- That the test tools industry disappears in its present form and takes its rightful place as an essential component of the broader software development tools industry.
- That for most of us, testing ceases to be a profession but an inseparable aspect of what every conscientious developer routinely does. (page 406)
I’ve asked ChatGPT 3.5 for advice on how to write this post. To my big surprise, it was a very pleasant experience. It recommended sections for the post and what to cover in each of them. If you like this post, thank ChatGPT. If you don’t like it, blame me.
]]>Organizers should organize conferences this way. The famous living and evolving board with sessions. Everybody can vote and move sessions around the board.
This was the sixth time I had participated. We went to CITCON 2012 and then changed our Testival conference to an open-space/unconference format. I have even organized one of them (Zagreb 2014).
I have attended many conferences. Looking at the list of conferences, I can see that I’ve attended a lot of them just once, and some of them many times. CITCON is one of the rare conferences I return to.
In 2016 I even wrote a blog post Don’t Go to Conferences. To quote myself:
I have been to a lot of conferences. I have been a speaker at some of them. I have even helped organize a few. I like going to conferences. I also think that going to most of the conferences is a waste of time.
Going to CITCON is not a waste of time.
I contacted Christoph Jauera from Wikimedia Deutschland (WMDE) when I thought about going to the conference. WMDE has an office in Berlin. He decided to join me for the conference. He also organized a small informal hackathon on Friday before the conference in their office. One more person joined. We talked about a project we are working on, upgrading WebdriverIO to v8 (T324685). It was great to meet people in person. Some for the first time, and some after a few years of pause caused by the recent pandemic.
I love the CITCON conference. It’s a day-and-a-half event.
Day one is shorter, half a day. It’s always on Friday afternoon with a short introduction on how the conference works. Then, everybody sits in a big circle and shortly introduces themselves. After that, everybody can propose a session or multiple sessions. That’s followed by dinner during which everybody can vote on sessions and move them around the schedule. It sounds like chaos, but it works great. Friday itself is a lot of fun and the conference didn’t even start for real.
There were a lot of people at the conference interested in artificial intelligence (AI). I proposed four sessions. Three of them gathered enough votes to be scheduled.
Saturday, day two, is a longer, full day. It’s when the sessions happen.
I have started the day with Testing a full Linux distribution completely automated session. There were just the three of us in the session, but it was great. That’s how it often is at CITCON. Sometimes the smallest sessions are the most interesting.
The next session I joined was How to Learn from Frustration. (In case it was not obvious so far, not all sessions were about software development.) That was a great session. I’ll post a couple of my notes.
In the session, I learned about the Four Tendencies Framework. The framework includes Upholder, Questioner, Rebel, and Obliger.
On Friday I proposed a chess session during lunch on Saturday. When lunchtime came, I set up a couple of chess boards. There was no big plan, just to play some chess. We have spontaneously self-organized into two groups. It was a mix of lessons and playing.
After lunch, my session Healthy Coder was merged with Live Outside Work. We have talked about staying healthy while our jobs require us to sit for many hours, for many years and decades. A few books were recommended.
Then, it was time for another session I proposed Deep Work. I am a big fan of the book. I will use every excuse to talk about it.
The final session was Using ChatGPT to write anything. I have not used it before. It was a good introduction. We were collaboratively rewriting the conference homepage with the help of ChatGPT. A couple of other tools to help with writing were mentioned.
The conference closes with another session of everybody sitting in a big circle. (There’s an obvious lack of a fire in the middle of the circle.) Everybody shares one or more aha moments from the conference. I was very glad to hear that a few people liked the Deep Work session.
I enjoyed playing chess during lunch at the conference, so I started a chess club. This way, we can stay connected and continue playing. If you were at the conference and want to join the club, let me know on the conference Slack.
I was thinking a lot about the conference while writing this blog post, so I have posted this in the conference slack channel. After some thought, I think it would be good to make it public.
We had a short discussion about renaming/rebranding CITCON at dinner after the conference. I’m not sure if the organizers would seriously consider that.
First, I think CITCON is an established brand and I do not propose changing the name. However, I always believed CITCON means a conference about continuous integration and testing. But, when I read the website, I couldn’t find any mention of it. So, maybe the rebranding has already started.
According to Archive.org, my theory is confirmed. It was called a continuous integration and testing conference from 2006 to 2016. In 2017 the homepage stared talking about continuous improvement.
In my opinion, that is the direction the conference should move to and market itself. CITCON is a conference for software developers. It focuses on continuous improvement. Many people interested in testing and CI/CD attend. Testing and CI/CD were maybe more important in the first decade of the conference (but I have missed it) than they are now.
I’m not sure if organizers can share the numbers of registrations/attendees/sponsors over the years. Are the numbers stable/growing/declining? Do you have a short/medium/long-term plan for the conference? Are you happy with the current numbers? Would you like them to grow?
To move from theory to practice. I’m not sure when the time will be right, but in the next year or two I would like to bring CITCON back to my city. If we market it as a CI+testing conference, we are seriously limiting the amount of both attendees and sponsors. To get more people and sponsors, we can advertise it as a conference for software development and continuous improvement.
Organizers should organize conferences this way. People sitting in a circle, looking each other in the eyes, introducing themselves.
]]>I’m one of those people that thinks computer security can be best described as Swiss cheese. Nothing is absolutely secure. As with physical security, you can only make it harder for people to break in. That will deter enough people to make security good enough.
One thing that I’m particularly sensitive about is online banking. It’s really convenient that you can do the vast majority of banking online. It’s also very scary that somebody on the other side of the planet could take all of your money.
I feel very uncomfortable doing online banking on the same operating system where I install a lot of applications and development tools. What’s the worst that could happen? Pretty much the end of the world. Or at least an empty bank account.
For years, I had a dual boot setup, macOS and Ubuntu Linux. I mostly do software development. Most of it I would do on a macOS, some of it I would do on Ubuntu. I would set up a third operating system, a clean Ubuntu install. (I guess multi-boot would be a more correct term than dual boot.) I would install a minimal Ubuntu install, then remove everything I could, except the browser that I need for online banking.
That’s far from perfect. But it’s good enough. There’s a small chance that some malicious software might jump from one operating system to another. I’m willing to take that chance. For now.
I recently got a new Apple machine with an M1 chip. I guess it’s still possible to install Ubuntu on it, but I have failed so far. What I did manage to do is two macOS installations on a single machine. I use one macOS for banking. Then one day I stumbled upon Lockdown Mode. It pretty much makes your machine unusable, but I only needed a browser anyway. Perfect. The only drawback I have noticed so far is that some fonts and/or images are not loaded, so some pages look strange. But, that’s a small price to pay. A website (for example your bank) can be excluded from Lockdown Mode in Safari, but I didn’t need to do that so far. I learned that today while reading about Lockdown Mode. 😅 It might come handy in the future.
Having a dedicated machine for banking, with a minimal operating system, would be a better solution. I’m thinking about it. I do have a pretty old laptop that I still use when traveling. In a year or two it will probably be unusable for development. At that time it will probably become my dedicated banking machine.
I have used a dedicated banking machine for years with an even older laptop. Nowadays that machine takes forever to boot. It’s also really slow when booted, so I gradually used it less and less. Dual boot proved to be secure enough and convenient enough. I’m not so worried about security that I think buying a dedicated banking machine would be a good investment.
]]>I apparently really like writing x years of something blog posts. So, let’s write another one.
In October it will be 11 years since I started working for the Wikimedia Foundation. So, it’s the last responsible moment to write about the first decade.
I have a bad memory, so there’s no way I can remember things that happened over a decade. Luckily, I’ve been documenting things on this blog. With some Internet archaeology, I should have enough material for a blog post.
I was freelancing in 2012. I was looking for a new client and applied for a job at a Foundation. I didn’t think much about it. I didn’t expect to get the job. I didn’t expect the Foundation to become my only client soon. I didn’t expect it to become my employer eventually. I surely didn’t expect to work there for a decade.
In about a month I’ll be 46 years old. In about a month I’ll be at the Foundation for 11 years. That means I’ll be working for the same company for about a quarter of my life. In a world where the average tenure at a big tech company is about 4 years, why would I more than double that?
In no particular order.
I’m spending my life making the world a better place, instead of spending my life making somebody rich. I really like working for the Foundation because of its mission. Wikipedia is one of the best things that has happened to the Internet, and that’s just one of the Foundation’s projects (admittedly the most important).
I really like the people I work with. The people I worked with over the years range from great to amazing. I worked at places where I didn’t go along well with people. It makes a world of difference when you like your coworkers. It might help that we’re countries or even continents apart and see each other only a few times a year, at most. 😅I think I would like them even if we saw each other every day. 😉
I really like the projects I’m working on. The projects are interesting, challenging, meaningful and force me to learn new things all the time. I could not wish for more.
The benefits are pretty good. I’m paid well. I have plenty of vacation. Parental leave is amazing (4 months for fathers!). I really appreciated it when my last child was born.
It can’t be all unicorns 🦄and rainbows 🌈! What are the things that are frustrating? The Foundation is not perfect. The people working there are not perfect. I’m not perfect. For years I’ve had my own company and invoiced the Foundation monthly. A few years ago they insisted that all of us get hired by a third party, in my case Safeguard Global. They don’t have an office in my country so I’m actually hired by a local company. In short, it’s complicated. I’ll let you imagine how complicated it can get to get some things done (expenses, vacation, parental leave…) when (in some sense) I have 3 employers.
Let’s move to some statistics.
I try to keep my LinkedIn profile up to date. According to it, I had 4 job titles in the last 10 years:
I’m not sure what it says about job titles in general, or maybe only in software development. I’m doing pretty much the same thing all the time. Developing an end-to-end testing framework.
In 2012 I joined a very small Quality Assurance team that was formed just a few months before I joined. As far as I remember, it was just Chris McMahon and me.
In 2013 I joined the newly formed Release Engineering team. I have a lot of nice memories from those years. The only thing I didn’t like were deployments. Both train and backport. But, I have learned a lot from those.
In 2019 I joined the newly formed Quality and Test Engineering team. Because of COVID, I’m yet to meet most of the people from the team in person.
In retrospect, apparently I have a thing for newly formed teams.
Oh man, were there events. I sometimes describe working here as just enough travel. Well, before the pandemic. All travel stopped then.
Some of the cities and countries I have visited for conferences or offsites are:
One of the places I have visited the most is San Francisco, California, USA (2013, 2015, 2016, 2018, 2019, 2020). That’s where the office is, so we used to go there a lot.
I like internships. I was a mentor several times. Most of them happened during COVID-19. I guess I had time for mentoring since I was not traveling.
In 2012, I was hired to write Selenium tests. That’s what I have been doing since. We started with a framework in Ruby, but switched to JavaScript a few years ago.
The Ruby framework had decent documentation but the current JavaScript framework has even better documentation. I am a bit subjective on that topic because I wrote most of both Ruby and JavaScript documentation (T246425).
Over the last decade, I’ve been involved in several smaller projects. I’ll highlight a few of them.
Gerrit is a code hosting and code review tool.
When I started, we were using Bugzilla for tracking bugs and tasks. In 2014 we switched to Phabricator .
A big thank you to Tyler Cipriani for great advice on how to make this post better.
]]>I wrote a draft for this article in 2018. It has remained a draft since then. The last responsible moment to publish it is long gone. I have many notes about the topic, but I do not think I am ready to write a post about it yet. But, since a few people have asked me to share the notes, I will do my best.
I am very interested in career development. I have tried to talk about it at a [Testival meetup] in 2015 and Testival conference in 2016. (Tried means I’ve proposed the topic but it was not selected for the event.) I gave a five-minute lightning talk about it at a Testival meetup and the WebCamp conference in 2017. I led a session at the CITCON conference in 2018 and the Testival conference in 2022.
All three talks consisted of two parts. First, I would ask the audience what they think is a good way to develop a career. I would take notes. Only then, in the second part, would I share my thoughts. I did not want to influence the audience. Every time the result was different. The first two times I gave short five-minute lightning talks. They were short, but they helped me develop my thoughts. The last time was a one-hour open-space session. It was very different in many ways.
There was a few years between the CITCON conference in 2018 and the Testival conference in 2022. My thoughts about the topic are much more clear now. I might even finish and publish the article.
Some of my thoughts that were not mentioned by others at the events.
Not your company. Not your manager. You are responsible.
It’s too late to start when you lose a job. Prepare for the next job while you still have one. If you like the job you have, feel free to keep it for years or decades. Just, don’t assume you’ll be able to keep it for years or decades. Things change. You might be fired. The company might close. Today.
I’ve read somewhere that the average time an average person stays at a job is five years. Plan for that.
You should not get into a situation where your skills are obsolete, and you have to retire.
These things were mentioned at two events. I did not find anything that was mentioned at all three events.
At the Testival meetup, the audience were mostly testers.
At the WebCamp conference, the audience were mostly developers.
The CITCON session was much longer than the previous two, and completely different. The audience was mixed, developers and testers.
I have read a few very good books recently that go into much more detail about career development than this blog post could.
Fuzheado, CC BY-SA 4.0, via Wikimedia Commons
Last month I was in beautiful Athens, Greece for the Wikimedia Hackathon 2023. The last time I saw anybody from the Wikimedia Foundation in person was in San Francisco in 2020. The last time I saw anybody from the Wikimedia movement was in Atlanta in 2019. The last in person hackathon was in Prague in 2019. So, I didn’t see some people for 3 and some for 4 years. I have also seen some people for the first time, even if we collaborated for years.
It’s really hard to summarize a hackathon. It’s a crazy mixture of technical talks, coding, socializing, sightseeing and fun.
It started with project pitches. Everybody that wanted to, could get people interested in their project. But, since there were about 200 people there, everybody got only 30 seconds. Fun part was that if you went over your time, you were clapped off the stage.
One of the interesting sessions I went to was Using Pixel tool for visual regression by Elena Tonkovidova. Elena was very nervous before the session, but she did a great job. We had a great discussion during the session. Dom showed us how he set up Pixel for WikiLambda.
Another interesting session was how to Improve your technical writing by Kosta Harlan. At that session I learned about LanguageTool and Google’s Technical Writing Courses.
The last session I’m going to mention is the Patch demo by Bartosz Dziewoński. I’m very interested in development/testing environments, so I try to learn at least the basics of available ones.
My plan was to work on one of several projects at the hackathon. Either documentation, or a refactoring, or an upgrade. That didn’t happen. But that’s how hackathons sometimes go.
I applied for the hackathon months ago. In the meantime, I didn’t work for a couple of months because I was on parental leave. The hackathon was near the end of my leave, so I was pretty lost and confused at the event.
I managed to do some sightseeing. One day after the sessions a few of us walked to the Philopappos Monument. It’s on the top of a hill with a beautiful view of Athens. Another day I visited Acropolis.
A few of my teammates from the Quality and Test Engineering Team were at the hackathon, so one day we met for lunch. We didn’t see each other in person for at least 3 years. It was great to be able to socialize after such a long time.
I have also learned about a new saint, Saint Javelin.
I was disappointed that there was no organized sightseeing, considering we were in one of the most interesting cities in the world.
01tonythomas, CC BY-SA 4.0, via Wikimedia Commons
I forgot to bring a chess set, so I bought a cheap plastic set. I led a Chess Basics workshop during lunch one day and had a few games of chess during the hackathon. I was hoping for a few easy wins. I have played about 10 games. I think I managed to win just 2, and somehow draw 1 game. I lost the rest. I’m glad this was a hackathon and not a chess tournament. My rating would be seriously decreased. 😅
I would highly recommend reading this book if you need to learn more about testing, test automation, Selenium, WebdriverIO and JavaScript. The book is self published, so it is not as well edited, especially later in the book. The book is also a work in progress containing a lot of code, so expect some minor problems with the code here and there.
I have some experience, both with test automation and with writing a book about it.
I have been testing software since 2004 (reference in Croatian). Very early in my testing career I have started with test automation, at latest in 2005 (reference in Croatian). Back then my preferred tools were Ruby (programming language) and Watir (test automation library).
In 2009 I started working on a test automation book focused on Ruby and Watir. I have self published it at Leanpub. In 2014, after 800+ commits, I gave up on the book. Writing a book is a lot of work and I just didn’t have the time.
In 2012 I started working on test automation for MediaWiki. It used Ruby and Selenium. After a decade of Ruby, I have started with JavaScript in 2015. In 2016 MediaWiki started moving its Selenium tests from Ruby to JavaScript. In 2017 the first commit of JavaScript+WebdriverIO code was merged in MediaWiki. The same year, I wrote a blog post about the experience.
Although I have a few years of experience with WebdriverIO, I have learned a few interesting features of the tool while reading the book.
The book caused a couple of ideas on how to simplify and improve MediaWiki’s test code:
The first idea simplified package.json
in many repositories by deleting webdriverio
npm package as an explicit dependency. The second idea will improve and simplify the code by using a better assertion library (Expect from WebdriverIO) than the one we use at the moment (Assert from Node.js).
One of the great ideas in the book is to use a real world application. It’s a demo web application that has almost all features of a real world application a typical reader would test. In general, I prefer to run tests targeting a local testing environment, as opposed to a shared testing environment. One can control the local environment, and it is usually faster. It does need some setting up, but I find that a cheap price to pay. The shared environment doesn’t need any setup, it’s already there, but you don’t control it. It can be slow, not work properly, go away with no warning, and other people testing at the same time can break your tests. The app was working great for me locally for a while, but then one day it just refused to work. I never took the time to debug what went wrong. It was easier to just use a shared testing environment provided by the author.
When I started reading the book, it was using WebdriverIO sync API and WebdriverIO v7. The current default API is async and the current version is v8. While I was reading the book, it got updated from sync to async API, but I don’t think the editor took a good look at the new version. There is some broken code in the book, especially in the last few chapters.
It’s not a big deal that the book uses WebdriverIO v7. As far as I remember, there was just one piece of code that didn’t work on v8 in chapter 2.6.2 (Key Commands). I solved the problem by downgrading to v7.
I know it’s not easy to keep a technical book containing a lot of code up to date. I don’t see an alternative to having all code from the book under continuous integration. WebdriverIO project has an interesting way of solving the problem of code in documentation.
Up until chapter 2.9.2 there were just a few minor mistakes in the code that I was able to fix myself. From this chapter until the end of the book (well, only three chapters, 2.9.2 - 2.9.4) code is falling apart.
For example, Axios dependency is introduced into code, without mentioning that it should be installed. That is pretty obvious, but still confusing. Axios is first mentioned on page 185, but the book says we’re going to use the Got library. I guess the author later changed his mind, but forgot to say.
I was setting up a new machine and installed the most recent version of Node.js (v20) on the machine. None of the code I wrote while reading the book worked at all. Downgrading to v16 fixed the problem.
The book is self published at Leanpub. The landing page lists an editor, but I’m not sure how involved he is in the publishing process.
The author nicely says that using WebdriverIO in the book is an implementation detail. It’s a good tool, but the book would not need to change a lot if the author decided to rewrite it using a similar tool, like Microsoft’s Playwright, Google’s Puppeteer or Cypress (by the company of the same name). It would be interesting if somebody wrote a book that had code examples in each of the popular tools.
For comparison, here is cypress vs playwright vs puppeteer vs webdriverio package download counts from npm trends for the last 5 years (2018-2023). Puppeteer and Cypress are very popular, WebdriverIO and Playwright not so much.
All that said, the world needs more good books on test automation. I like the book, but I would like to get in touch with the author and see if he’s still working on it. I would be hesitant to read it again, or recommend it to others until some problems with the book are solved.
I usually share drafts of my blog posts with a few people. I usually receive some feedback. This time Karlo Šmid and Tyler Cipriani gave me so much good feedback, I didn’t have the time to implement it all. 😅 I will continue implementing their feedback and making this post better as I have the time.
]]>