I still remember my first real test. The first time that I purposefully designed a vector on to the system to answer a specific question and hunt for specific information.
Do you?
Note: my first ‘real’ test. Not “the first time I found a bug”. For the purposes of this exercise I defined my first ‘real’ test as the first time I can remember purposefully thinking like a tester with regards to software and actively hunting out a bug.
You may choose a different definition - up to you. And you may have more effective recall of your formative years - bully for you. But - my blog, my story.
So… when I were but a lad, at University, we used green screen terminals hooked on to a Prime mini-mainframe. The library had a set of terminals all arranged close to the front of the library where we could go and search for books, reserve books, and other stuff which I can no longer remember but it all seemed terribly important at the time.
I do remember that the library search functionality would allow us to type in wildcards. And I went through 4 years of nicely typing in wild cards: “cobol*”, “*testing”, etc. All very studious and efficient.
In my last year I started to study testing, and I read every testing book in the library (not many) and I guess that helped me start thinking about ’testing’, helped me start identifying risks, helped me start thinking ‘what on earth might someone have done wrong when building this - that I can figure out’.
So I sat staring at the little green flashing VT52 cursor one day… Aha! And typed ‘*’ into the search.
But the system cleverly didn’t allow single character searches. After all, to return all results might prove detrimental to the shared computer system’s performance.
So I decided to explore the boundaries of this particular routine and the limits of the error trapping thought process of the developer.
So I duly typed in “**”. And I waited. And I waited. And the system didn’t give me any responses. I did however notice some verbal responses - the moans and complaints from the terminal users sitting beside me as their systems froze in front of them.
I uttered a few choice curse-words of my own and left the library in a hurry so as not to draw attention to myself from the angry mob.
A hang-up has stayed with me from that day. I do not particularly like testing in live, just in case I inconvenience people.
So when I do test live systems I try to go so far as to identify a weakness but not exploit it - unless of course the owners asked me to. This has ruined my chances of becoming an effective hacker. So I now have to submit to a self administered course of Evil Tester Provocative Therapy.
I find the change in my attitude interesting, and I hope this post will encourage you to engage in a similar memory exercise.
Back then…
- At that point I thought I had done something wrong.
- At that point I felt bad that I had brought the system down.
- At that point I slunk out, despite having found a showstopper.
But now!
- I no longer find anything wrong with testing - I try to get as much fun out of it as possible
- I don’t blame myself for bringing systems down - I reflect and learn from the thought processes I used
- I don’t feel bad if I find exploitable situations - heck, I feel proud
- I no longer slink - I report…carefully.
So why post this?
Our attitudes to testing. Our approaches to testing. Our beliefs about testing - all these things change over time. Thinking back, allows you to see how you have changed, to identify the good changes and the bad. To see growth in your approach. To identify stagnation. It allows you to analyse if anything you do counts as a ‘hang up’ rather than a ‘beneficial belief’.
And while you don’t have to go as far back as your first test, the early memory may entertain you.
