The Surprising Diversity of Password Retrieval

In the last weeks of my pregnancy the “nesting” instinct kicked in. Since I was no longer working, I had the time to do important chores, such as trying out all the pens in our household to get rid of the ones that were empty. Once I was done with the physical world, I went for the virtual one. I uninstalled unused programs, deleted duplicated folders and my final gargantuan task, was to clean up my online presence.

I knew there was an obscene number of accounts I owned that I would never use again. This was due to the facts that I have lived in different countries, that my interests over the years have changed and that when I was younger I wouldn’t give it a second thought registering to any website. For many of these accounts I had no clue what my password was, so I had to go through the “Forgot your password?” process multiple times.

I have tested this action various times at work, so I thought I knew well what to expect. To my surprise, I encountered an abundance of different implementations varying from air tight secure ones to having the password sent in plain text to my email account. After going through the process at least a couple dozens of times I’ve noted down some factors that seemed to affect the diverse implementations.

Site’s inertia

There still exist sites that have not changed much over the last years. They have a fixed set of features loved by their customers, old and new, who are probably constantly logged in. Those sites had the tendency to have a process with whatever good practices were available at the time of implementation but never revisited since.

Size of the enterprise

Sites belonging to bigger organizations had the process generally in pretty good shape, since mishandling could lead to bad publicity or even lawsuits.

Site’s target audience

Sites that were addressed to technically savvy people seemed to handle the process better than the ones aiming at non IT-related industries.

Site’s location

The origin of the website also affected the implementation of the process. There were some German sites had me jumping through hoops to retrieve my password, including having it sent to me by post (the retro one, with the envelope).

In this competitive market, we always strive to release new features to make our software more appealing and useful to our users. But do we ever take the time to review if what we already have is in a state of the art condition? Should we have an active process of reviewing existing functionality? Or maybe act on demand, triggered by the feedback of our customers?

My impression is that revisiting existing and familiar functionality is a good exercise which can advance knowledge transfer and lead to better, up-to-date, code. The challenge is to find the time to do it in our day-to-day work, rather than wait for the slack of a parental leave.

How Being Lazy in School Helped Me in Testing

I was always a good student. Never excellent, but good enough not to get any complaints from home. Not to be misunderstood, it was not only my parents pushing me to have good grades. I liked being a good student, I would just never make any extra effort to become the best one.

My high school years are far behind me and after some time working as a software tester, I came to realize that I was approaching work the same way I was approaching school. I had a collection of techniques that, back then, I was applying unconsciously to minimize the amount of time I would need to spend studying. Here is a short overview of my arsenal of tricks and how I used them in a work context.

Names, Dates, Locations, Numbers

The first thing that any lazy student not wanting to make an extra effort would do, was to learn the “SOS”. The term “SOS” was used to denote anything that was considered important by everybody. Dates and locations of battles, names of generals, number of soldiers in each army. They were trivial, and even though they were too obvious questions for a quiz, it would be too risky not to learn them.

As soon as I started working as a software tester, I considered it to be a good idea to first go over anything that was too obvious to fail. It was quite improbable that somebody would develop a “log in” button that could not be clicked on, but I preferred clicking on it by mouse or keyboard just to be on the safe side.

Once the specifics where out of the way, I focused my attention on the people controlling the exams, the all-powerful teachers.

Each Word Matters

Every teacher had favourite topics. Even if they wouldn’t say so, it could be hinted by the tone of their voice or the amount of time they spent on a subject. My lazy self would pay attention to identify the material that was close to their hearts and focus on it for the exams while only skimming over the rest of the book.

At work, I replaced the teacher with the product owner or the customer, the studying with testing and the exam with a release. The outcome was to test thoroughly what was perceived important for the stakeholders before we delivered.

My next trick was the jewel on my crown of gimmicks.

Establishing Yourself

Early on I realized that once teachers believed that you were a good student, they stopped questioning you. My approach was to study a bit harder in the beginning of the year to get good grades and establish my good name among the teachers. The rest of the year they would just let me do things on my own pace and comfort.

I found myself doing the same thing when I started working on a testing project. Working hard in the beginning to prove that I was good, made it easy later to convince management of new processes and workflows. After all if our team was delivering a product in good quality, why change a running system?


Of course all good things come to an end. When the time came to take my university entry exam, I’ve realized that with my method I was good in getting good scores only within the confinements of my school environment. To get a passing grade in that exam, I had to study seriously and methodically the entire syllabus.

Nowadays, I try to keep up to date with all the latest developments in the testing world, including techniques and tools that could help me improve my work. There is an abundance of resources from books to online tutorials that can teach us almost anything technical that comes to mind. But I still wonder what other skills we need as testers to make us good at what we do? The incentive for the ones mentioned above was laziness but there must be others, prompted by more noble sentiments. And if there are, how and where do we learn and practice them?