All posts by Mindful tester

Speaking of Privilege Dynamics

The story is that a good proposal for a talk and some preparation is a sure way to speak on a conference. There are other factors involved.

Privilege dynamics

For this article I made up the term privilege dynamics. With privilege I am not writing about the honour to speak for a group of peers and their managers. It is about having enough resources to speak. According to me, dynamics is the way it forms the world.

Permission to speak

The first thing about privilege is asking for permission to go to the conference. My wife had mixed feeling about this. At the one hand she knows my love for speaking and at the other hand she wanted to know that I am in good hands.

The next in line for permission is my employer. My absence will lead to a drop in revenue. In some cases, I had to ask my customers to speak. This could have consequences for the results of the whole team.

There were employers who were really happy to send me as a speaker to a conference. In most cases they provide services and this benefits their companies. A lot of other companies are not eager to have a speaker at a conference. The benefits must be measurable in some way.

Confidential information

What is more appealing than to talk about than a real story? I can grab the attention of the public with a project or a sprint with some really insightful moments. There is a big chance that my employer or customer would not be pleased that some stories would be told afterwards.

For one talk I asked explicitly to use the graphs showing the results of a performance test. This added a lot of reality to my talk. For a workshop I created a website with an imaginary company based on real life experiences. This way no company or organisation was impacted by my stories.

Righteous owner

Copyrights are a difficult thing to handle for a beginning speaker. When I was a consultant, the rights of almost all my talks went to my employer. This applies for a lot of things. I read a story about someone who used a private laptop to retain the rights of a book.

An argument would be that the employer pays me, so this might be a fair trade. I can speak at a conference and my company will own the results. The drawback for me is, that I cannot use these talks after switching employer. This happened once.

To be extended

Minimal Viable Authentication: usability versus security

Trigger warning: stalking.

For the following stories I am using the imaginary VIP Cinema again instead of the real app. This way I can freely write about my experiences without naming the actual app.

Usability is king

The VIP Cinema app offered his clients a discount for parking. This service appealed to me. So, I contacted the customer service and got a power of attorney number. On request I had to mention the number to get my promised discount of 50 percent on parking.

After a while I wanted to reserve my parking without calling the customer service. There was a simple solution: a parking app. I installed the app and had to register. The first thing I did, was to have my power of attorney number ready.

The next step was to enter my email address and a password. Then I had to verify it by clicking on a link in an email. A dialog asked for my membership number of the Cinema VIP App. Then I opened the app and found the number.

I received an email to verify my email address for the parking app. After clicking a link, I had to enter my VIP Cinema membership number. The next moment I could reserve a parking place for my car without entering my power of attorney number.

The registration was smoothless and it saved me an extra step of entering another number. I really liked this experience.

Security is pauper

”I want to show something to you.”, I told another computer software professional.
“Here is my mobile. The Cinema VIP app is open and shows my membership number.”
I got a nod.

“Now I am going to the website to register a new user id and password for the parking website.”
Another nod followed.

This looks familiar

Then I entered a new email address and password. After clicking the link in the mail to verify my email address I asked him for my membership number. While he was citing the number, I entered it in the requested text field in the dialog,

 “Let us see what kind of information we can get based on this single number.
You can see where I live. This information is needed for billing.“

Worth noting

“Let’s have a look at my parking history. This is the parking I used every other week. This is an interesting pattern. Last week I parked there. So next Friday I will probably park the car there at 7 pm.”

Let me guess

“There is a high chance, that I visit a cinema close to this parking. The discount is offered by the Cinema VIP app. Notice that no power of attorney number was asked. This would improve the security.”

All that being said

“Even worse: I did not get an email that another account was coupled to my parking account. I refreshed my inbox: no mail was found about the double registration.

Certain social media apps inform me directly, if my account is accessed from an unknown device. But this was not the case for this app.”

This time I did not get a nod, but an astonished face.

Signals of poverty

When I phoned the customer service of the parking service, no power of attorney number was requested.

During this phone call there was a check of my birthday, my zip code, and my house number. These can be obtained using social engineering or extracting private information without getting attention.

This I Learned

Authentication is about making sure that the right person gets access. Some shortcuts can have severe drawbacks.

How to reduce the scope of testing during testing

It is common to reduce the scope of testing before the test. In my test charters I use things like feature to be tested or planned time. For me this is a way to prioritise my tests. Here are some stories about scoping testing in full testing mode.

Reported as usual

This story happened in real life. In order to share it with you, the reader, I used the VIP cinema appointed of the real app. The new feature of the app was that the clients could make tailor made purchases. Some custohhhmers like free parking or discounts for snacks. So, customers could make a package with the discount set to 50 percent.

Not in my backyard

One day I had to test a feature for a package. My steps were to make a package, add components, and use the package. I focused on the normal situation avoiding making typing errors and entering invalid values.

The start was quite promising: I made a new package and gave it a name. Then I added a decent number of components to the fresh package. When it was time to use the package, I noticed something strange. It was not usable. The package did not give the promised benefits to the user.

It took me a few seconds to realise that I found a bug. Now it was time to make a bug report. It should contain all steps that led to this strange situation. In my notes I found all the information I needed.

Not in my front yard

I made a new package, but after adding some components, something went wrong again. I carefully looked at the new situation and noticed a new bug. Now I needed to repeat all steps again for a new bug report.

So, the whole series of steps had to be repeated for a decent bug report. After a few times I could show the bug every time, so I added all the steps to the bug report.

Not in any of my yards

I tried to do the next few steps. Again, I noticed something wrong, so I had to make another bug report. Once again, the whole stuff repeated, I had to repeat all the steps until I could reproduce the bug and then write another bug report.

And this pattern repeated until I got to the 15 steps for initial bug. It was very difficult, because every 3 steps I got an error for which I had to make another bug report showing in the steps I took. I only wanted to make a package with some components.

It has my attention

A few weeks later a programmer told me: “You made those many bug reports?” I remembered the bug reports and was proud about my findings. Then he continued: “All the bug reports had the same issue.”
My spirit dropped after his remark.

I had reported a lot, but actually one single bug report was more than enough. Were the bug reports a useful way to report the bug to the  programmer? Sure, but it costed a lot of time. I spent at least one morning to write bug reports.

What I remember is that it took so long to get some feedback on my bug reports. If I just could get feedback after the first one, it would just save me so much time.

Interrupted as usual

During one test session in another company, I saw something strange. I tried to make eye contact with the programmer. But he was fully engaged in his programming, so I called his name and he looked up.

“I saw something strange. Would you have a look?”, I said. He came to my desk and looked how I reproduced all the steps.

Sometimes he asked questions to clarify the situation: “What did you do?” or “Why did you do this?”. Then he went silent, stood up, and went back to his laptop without saying a word.

Wait a minute

I just waited.

After a long silence I got my answer: “It is a bug.” Now I knew that everything in this place I had to avoid during testing. I needed to reduce my scope of testing that very moment. Everything using this specific function could have a strange side effect because of the found bug.

This way of reporting a bug was on the request of the programmer. He knew that I could find things he had not expected.

He also knew that if I would continue testing, that it was very hard for him to reconstruct what went wrong.