TL;DR Tester sometimes needs to act very fast. And that action should be based on decision that is made based on information and his testing knowledge. In this blog post I will give example how I made a 30 second decision that was not related with software testing, but was related with somebody’s life circumstance.
Here is excellent example from James Bach what is context driven tester:
From the moment when I saw for the first time this video, I put it on my software testing craft training list. I reply it and try to approach to my testing issues in that way. Sometimes I apply that skill automatically.
Here is example from real life situation. I was heading home from grocery shopping and my hands were full of bags. I was in a hurry. Then on bus stop, one elderly lady asked me to give her 20 kunas (3 $). She was on the verge of tears. She needed it because she was visiting her husband in hospital and she wanted to buy him some juice.
I immediately started to process information:
she asked for specific amount
she was dressed as person that is going to hospital to visit somebody
the bus stop was on the way to hospital
I had never seen that lady asking her for money
I automatically processed that information in my had, a gave her 20 kunas. Based on that facts, my conclusion was that her story was truthful. I have never seen that lady ever again begging for the money, which also could prove that her situation was real and one time life event.
Time is important variable that must be taken into account during software testing. In this post I will provide two examples how time influenced my software testing.
First influence was basic time lapse. I wrote test automation script for forgot password process. Script accessed email provider through the api in order to get email. And it worked for some time. And then it stopped working. There was no any change in application code for that feature. If you raise statement: “But previously that worked!” know that time variable kicked in. As application had not changed, I started to investigate testing environment changes.
I got message that username or password is wrong. But I was able to login in to email provider using those credentials. Error message had error code, and by searching for that error code I found out that there could be several reasons for the error. And my reason was that I was checking email above the allowed frequency threshold. Email provider changed that threshold from the moment when I wrote the script for the first time.
I got information about browser time zone settings.
While you are investigating what could be cause of issue that you have found, do not forget time variable. You will definitely have fun during that investigation!
This blog post appeared first time on zagorskisoftwaretester blog.
In this post I will explain what black hole and RIMGEA acronym have in common.
dr.sc. Dario Hrupec is a speaker at following Testival tester’s event (free admission is here). I found Dario’s work interesting and connected with software testing when I read his article about black holes (croatian version is here and Google translate is here).
Every object in order to be able to “escape” from other object, needs to be accelerated to the escape velocity speed. Black hole is an object that has so strong gravitational field that even light speed is not enough for light to escape that object. So we see that object as black hole.
Luckily for us, in human context, black hole is rare event. In the RIMGEA acronym, G stands for generalize. In order to generalize issue, you need to uncorner your corner case. Which means find corner values that are not at extreme borders. Values that are more probable in user context.
Would you report black hole as an astronaut security risk on a trip from Earth to Moon? And on a trip from Earth to another galaxy? I would raise black hole as a security risk only in later case.
If you ask yourself: Am I a good tester? Try to revalidate your issue reports. Issue report is one of the crucial tester artifact, it is a written proof how good tester are you. Always generalize your issue report. Uncorner your corner cases. Do not report black hole as a security issue on your project. Unless you are preparing for intergalactic travel.
If you want to learn more about RIMGEA acronym, here are BBST free resources.
In this post I will explain how I prepared in order to film flight of the International Space Station over my neighborhood.
International Space Station is one of the most advanced systems created by human race. And as a software tester, I am very interested in those systems.
Nasa offers free service called spot the station. Register your email and you will receive notification when ISS is going to overflight over your town. Here is email content:
First advice, create alarm notification on your phone, 5 minutes before time noted in the email.
Second, as a tester you should investigate meaning of other attributes of ISS overflight. This picture will help you to better understand those attributes:
Time and visible are straightforward.
Unit are degrees. And now your high school trigonometry class should kick in. Those degrees represent the angle (elevation) where ISS will reach maximal height over your position. Angle is measured from horizon (in direction of ISS appearing) that represents 0 degrees. And software test goody: if you put your hand in horizon, than your fist approximately represents 10 degrees. Have you managed to measure those 10 degrees?
TL;DR In this post I will provide real life example that will explain how to do risk management while driving in order to avoid driving accident.
While I am driving, I have different levels of alert. Here is intersection that always has my special attention (welcome to my neighborhood).
credit: Google Maps
Problematic part is when you drive in direction to south (to down in this photo, in Croatia we drive on the right side). Do you see anything special in this intersection?
There are three lines, in leftmost you need to turn right, and in other two you need to go straight. But that straight is not straight, you have to go in sideling direction slightly to the right.
And the issue is that drivers in the leftmost line very often go straight through intersection in my line. Because they do not pay attention to arrows drawn on the road and it feels natural to them to go straight through the intersection.
And that is what makes this intersection special. Other thing is that the number of this type of intersections in Zagreb is low compared to “normal” intersections where you do not have to do sideling.
So when I am in second and third line where I have to do sideling I am always extra cautious. It feels like I am on a start of formula one race. If there is a car on my right side (obligated to turn right), I always let him to go first, because I do not know if he would go straight without sideling in my line.
And there was also one special case, when previous intersection (upper in this map) was closed because of roadworks, and drivers that are not used to this sideling intersection were forced to use it.
How to apply this on software testing? If you notice during testing that you have to do “sideling” in order to use product feature, this is place where you should be extra cautious. Sideling in product is something in that product that is unnecessary overcomplicated and that could be done in simpler way. With simpler feature there is less chance for product issue.
This post was first published at zagorski software tester blog.