So, a few hours before January is over, I’ll transpose here an answer to Testing.StackExchange about the last decade on testing:

Question: What are the most important software testing developments of the decade?

My Answer:
The question asks about the most important developments… Not the best or the worst, the beneficial or the harmful.
I’ll try to answer here with considerations by me and others I found on the net. Not everybody will agree that all these are good — even I don’t agree with all — but my approach here is more of a reporter than a judge.

1. Blogs were the most important testing development, at least for me .
   It helps me grow my testing philosophy. It helps by being a quick and instrumental medium to quality discussions. Following the great authors as they write is a great experience (many authors started blogging only during the 2000′s, like James Bach and Michael Bolton).
   One great thing about blogs is that they allow us to understand the flow of ideas as they are being built upon — instead of simply receiving the ideas later, in book, as was the custom 10 years earlier.
   • Tweeting, forums, and other collaboration platforms of Web2.0 are cool too, but I believe their impact to be smaller.
   • Blogging also allows a simple guy like me to share his Testing Thoughts :).

Other points:

1. The Context-Driven School gathered momentum with this name, and became well known. I couldn’t find tracks on the full history of the context-driven school, but the earliest mentions I could find to it with this name are from the very late nineties. It is clear that Cem and James were publishing context-driven papers from the early 90′s (see here), maybe before — but the first places where I found the “context-driven” name where from 1999 (at the software-testing list. This seems corroborated by C2′s page).
   • Again, I don’t mean to say that it started on this decade. I believe the work of the context-driven people was context-driven for the last 50 years , and all had always sought excellency. It is not new from the 2000′s, but it looks like the movement got a name — and exposure as a movement — only in the last 10 years.
2. Certifications gathered momentum too. Without entering in the good/bad discussion, it is a movement that had a lot of action in the past 10 years and affected the way we discuss software testing today. It wouldn’t be fair to count what happened in the 2k’s without mentioning them.
   • The ISTQB was founded in 2002, and is a popular certification.
   • The ISEB was doing certifications before (so this too, isn’t entirely a new thing), but all got much more impetus.
3. Greater awareness and recognition of the benefits not only of Exploratory Testing, but of testing in general, and testing as a career too.
4. Michael Bolton started consulting in the testing arena, but moreover started writing and publishing. His essays about testing and checking are very cool, and Jon Bach considered it “one of the most (in)famous and important posts to come along in our industry in a long time“.

For the next 10 years…

1. The weekend testing meetings in India were highly praised by James, Michael and Pradeep on twitter. Seems like they believe it will make an impact on testing in the next years.
2. Testing.StackExchange appeared too late in 2009. But… will it appear in the 2020 list? I hope yes.

Demetri Martin

One best friend of mine introduced me to Mitch Hedberg and Demetri Martin, great one-liner comedians. They are/were two funny men!! Three, actually, if you count my friend which is also funny. 

After hearing the disks for over a year, not only the jokes aren’t any less funny, but I’ve started to find subliminal testing messages in them .
I’m writing down these “insights” because I find value in them. And even if they fail to teach you something… Hey! At least the jokes are pretty funny!
So here go some favorite quotes, and their parallel in testing: 

. 

1) “A drunk driver is very dangerous. So is a drunk backseat driver, if he’s persuasive!
'Dude, make a left.'
'But those are trees…!'
'Trust me...'“ 

We are testers. As such, most of the time we aren’t driving the company: Essential operational decisions are made by someone else (project manager, product owner, CEO, whatever you call him).
But if we are not the drivers, our position is certainly close to this of a backseat driver: we have our maps, good knowledge of the area and our experience; and we give advice that is used to take real decisions. So don’t be a drunken backseat driver, it’s dangerous! If you are inebriated by an obsessive desire to fix a bug, or by a personal quest against/for colleague, by a blind belief in a set of metrics or a unfounded trust in a fictitious “Best Practice”, you’ll be taking your company directly into the trees.
And, as with any drunk person… Whenever your judgment isn’t objective… At least recognize/admit that you may be drunk! Will make it easier for everyone else. 

. 

2) “I used to play sports... Then I realized you can buy trophies. Now I'm good at everything!“ 

A plaque, a crown, a card, a trophy… It is common to find people who treasure “victory symbols”, I know I do. They prove you’ve mastered a skill.
Trophies are nice and great, but only if they are accompanied by skills and real world practice. Trophies that can be attained without these traits are just empty cups*. 

One should beware when dealing with “achievement symbols”… At times, acquiring the symbol does not mean acquiring the achievement or skill too!
For example, just as buying the trophy doesn’t make Demetri good at tennis, getting a testing certification won’t make a tester good at testing… The certifications syllabi try to teach only specific lexicon and terms definition, but not the real practice of testing, because they don’t/can’t cover the interactions between persons and players.
For some people, the joke could be read as “I used to practice and study... Then I realized you can pass a certification. Now I can prove mastership - without the effort of gaining it!” Be sure to be from the ones who keep learning and carrying the skill. 

. 

3) “I am afraid of sharks, but only in a water situation. If I saw a shark on the street, I'd be like 'What? F#*k you!'
It's funny, that's like the opposite of how I am with lions!“ 

What’s the Best Practice for dealing with sharks? “Escaping” or “screaming”, right?
What if the shark’s on the sand? Or dead? Not hungry? Not dangerous? You have an anti-bite clothe? Anti-shark cage? Suddenly the ‘Best Practice’ looks more like a ‘so-so advice’, uh? 

The business of testing isn’t different. By looking at our surroundings and context, we can learn important details about our problems – and only then we can try to find an action path that solves it.
Without the context analysis, we may come with solutions that don’t address the real problem or does it badly. One size only seldom fits all. 

. 

4) “If I have to move up in a building, I choose the elevator over the escalator. Because one time I was riding the escalator and I tripped. I fell down the stairs... for an hour and a half.“

Automation is all nice and fine… Until you trip on it! Then it takes long time to recover from the fall (you could be long done by this time) and the fix to the system can be so crooked that it lets you prone to further tripping.
The elevator is a much more robust automation (not only it goes up and down, but it is much safer to trip in it ).
Anyway, who said you have to automate? An equally good way to go up and down is the stairs! You don’t need to wait for them to come, they are as quick as you need (or can make) them to be, you can stop to look around or change direction in the middle of the way, they don’t limit weight or number of users and they are never out-of-order.
Slipping, well, can hurt a bit . Just remember that manually doing things gives you many opportunities a machine cannot provide. 

. 

5) “I saw a sign on this door; it said, 'Exit Only'. So, I entered it and went up to the guy working there, and I was like, 'I have some good news. You have severely underestimated this door over here by, like, 100%, man!'“

Labeling is a natural instinct: The Bible depicts Adam naming animals as his first action in Eden, and Aristotle has been classifying everything since the 300 BC.
But the labels we use can limit ourselves or our tools.
“I'm a tester, I can't code“.
“I'm an engineer, I can't sell“.
“I'm a newbie, I can't help“.
Good news! You’ve underestimated yourself by at least 100%! 

. 

6) “I want to make a revolving door that says 'Pull' on it, just see how obedient people are.“ 

Meeting a Test Case that says “1) Reach to revolving door”, “2) Pull the door to open”. What do you do?
Maybe nothing is wrong. Maybe there are good reasons to make people walk backwards at the entrance.
Or maybe there isn’t, and then, who’s decides? The test case? The design? The developer? The tester?
What are your ways to discover about the door product and its users before deciding on obeying or not?

. 

7) “I was walking down the street, and this guy waved to me. Then he came up to me and said, 'I'm sorry, I thought you were someone else.' I said, 'I am.'“ 

Wow, that’s a funny joke!
Beginning a task with a very clear objective is usually a good thing – but failing to identify or even acknowledge alternative outcomes may not be.
A good friend was working in an academic project, trying to prove a theory about the nature of lasers. However, while progressing in the research, the calculations made clear that the theory wasn’t right. He was desolated – all this work and nothing to publish! He failed, momentarily, to notice that demonstrating a theory wrong has as much scientific value as proving it right, and the publication will advance science just as well.
Testing present us with many similar situations. We can start a test chasing a specific bug, and miss other bugs that may appear. Or we can keep our mind open for different outcomes, and grow your tests as we go from these outcomes. A different bug is hiding there, believe it . 

. 

8 ) “My plumbing is all screwed up. Because it turns out, I do not own a garbage disposal.“ 

How many times we rely on a garbage disposal when we don’t have one?
- Don’t worry, release it that way, we have a fantastic relationship with this customer. What if you don’t?
- It’s fine to release that way, the customer has a great quality assurance team and they’ll catch it if there’s a problem. What if they don’t?
- No problem, we can work Sundays — our testing department understands our needs and won’t care. What if they do care?
- This looks like a very nasty bug. But customers will always have the underlying framework, so it is fine. Will they always? 

. 

9) “I'm in a weird position, because I like rainbows, but I'm not gay. So whenever I go out wearing a rainbow shirt, I have to put 'Not gay'. But I'm not against gays, so under that I'll have to put '... but supportive'. It's weird how one group of people took refracted light. That's very greedy, gays.“ 

Once in a while a group of people will come, wrap common sense ideas in a new named package, and claim ownership, which is as reasonable as taking sole ownership of refracted light.
I could parallel this one to many things or groups, but I chose one where this happens with a lot of enthusiasm… The Agile movement.
Suddenly, you can’t focus on customer and organize a software project in a change-adapting way, without being called Agile. That group just took no-nonsense practices that had been used for decades and re-branded them as if they had invented it!
Don’t get me wrong – it is my opinion that what Agile preaches are often-good-practices-for-many-contexts and there are testimonies of companies, projects and souls being saved from a bureaucracy and poor quality hell by adopting Agile as a new approach. But this does not mean that anyone who is delivering quality in a “release early release often” way is Agile.
For example, even being a total newbie and never part of an Agile team until now, my personal testing approach focus on happy customers, working software, individual interactions and change — without me needing to be an Agilist.
More experienced great people had practiced all that, and test-first, and XP for decades. 

More than that, not only the practices’ refracted light was taken, but even the word “agile” itself was expropriated – see James Bach’s note at his ‘Who stole Agile’ post. 

——
Hope you enjoyed the article, or at least Demetri’s jokes.
If you have more insights and funny stuff to share, don’t hesitate to contact me – I promise to laugh.

I like books, better yet when they are good/useful books, and even more when they’re cheap — so I came to the fair prepared! I planned a budget (100 NIS) studied the catalog of discounted books and decided beforehand which books I wanted to buy:

- Book A: 43 NIS
- Book B: 30 NIS
- Book C: 12 NIS
- Book D: 12 NIS
- Book E:  9 NIS
        (106 NIS total)

Book A and B were books that I actually was interested in, and the other 3 I put on the list just because they were cheap , and were worth considering if they content looked cool.

When I got to the fair, I skimmed over the books and found out that books E and D weren’t that interesting, and that they would probably remain unread, so I dropped them from the list. Book C wasn’t that appealing too, but I left it on my cart meanwhile.

A few minutes later, I noticed that there was a very cool book on a subject that I am already studying — but that one cost 75 NIS!
My list was now over-budget:

- Book A: 43 NIS
- Book B: 30 NIS
- Book C: 12 NIS
- Book F: 75 NIS
  (160 NIS total)

As such, I called my wife, telling that I found other relevant books, but the whole list now exceeded the initial budget we agreed on. She gave me permission to double the budget and to spend up to 200 NIS. Yay!

Just before getting to the check-out teller, I discovered that there was a new volume from a set of books we have, and this was an opportunity to complete the series. Price of this book: 63 NIS.
Adding this one on top of the others would explode the budget again! I really wanted this book, and removing only book C wouldn’t help staying on plan — so I removed book B (a sacrifice for budget’s sake) and then C (not so interesting, anyway).

I went home with three books:

- Book A: 43 NIS
- Book F: 75 NIS
- Book G: 63 NIS
  (181 NIS)

I was happy with the books I took home, so was my wife, and plus: she was pleased that we stayed under the ‘second budget’.
And then it struck me…

So, this is my analogy for Exploratory Software Testing.
Many others are available:

• Michael Bolton has one here (charting unknown waters)
• James Bach has one here (and exploration and jigsaw solving)
• Ben Simo wrote one too (improvisational theater)
• Jonathan Kohl wrote his here (musical creation)
• … And now I present one of mine . I hope I am worthy of sitting with such eminent group.

But note: this analogy, as every other analogy, doesn’t have exact 1:1 similitude/parallelism!
It is intended as a line-of-thought, to help explaining the process and mindset… to clarify that exploratory testing isn’t a ‘quick, run and do whatever tests you can squeeze in an hour’.

– Hi, Nancy? (Name changed. And she wasn’t the testing manager, she was from the HR.)
– Yes.
– Hi, my name is Shmuel and I saw you’re offering a software testing position, the “QA engineer” opening…
– We have it, right.
– I saw that one of the requirements is to know the STD and STP methodologies, and I was wondering what are STD and STP.
– Well, if you have no experience on that, then the position is not relevant to you.
– No, no, I guess the experience is fine; it is just that the announcement made me curious. These acronyms can mean many things, you know? So I want to know how your company understands them.
– They mean specification documents.
– Does STD stand for Software Test Documentation? What does the STP mean?
– No, STD is for Software Test Design, and the P… Well, both mean specification documents.
– Why design? Is that the specification of the tests to run, of the testing system, or of the product?
– Why don’t you just look up the meanings on Google?
– I tried right before calling you. The acronyms are all over the web, but they have different meanings too (*).
– Listen, these are very important topics, if you don’t know them the position is not relevant. They’re very important, and very well known.
– I see. Thanks you Nancy!
– Thanks, bye bye.

Very important and well known. Well, I guess I’ll put them in my list of things to learn… As soon as I decide which meaning I want them to have…

Let’s see. I guess two of the best “methods” I use in testing are:

STD – Software Test Drawing: Scribbling in a whiteboard (pen+paper are good too, but my experience shows whiteboards are much better). This is especially useful when you’re working with someone else. With some squares and circles explanations become simple, concepts become clear, people can point when they talk, you can easily delete mistakes, and the best part is that usually there is always a joke at the end of the process. Whiteboard scribbling is a major testing tool for me.

STP – Software Test Peer (or Pal): If you are like me, your brain is constantly storming . Nothing beats thinking out loud or talking to peers and fellow testers/developers about the challenges you face — more often than not you’ll learn about a direction you hadn’t thought of or about a tool that can help. Works fantastically with STD .

I may start an “Alphabet of Really Useful Software Testing Things” — please contribute on the comments.

(*) In fact Google says D and P apparently can mean Design, Documentation, Development, Performance, Process, Plan, Programming…Pick your own definition. Most companies seem to accept STP as Software Test Plan, though.I still like that anyone can pick the definition that best suits his needs or business, though. So I’ll stick to mine .

Note to my employer: No, I am not looking for a job elsewhere yet .

Today morning I was greeted by an Email from SQE: The subject read “Are you certifiable?“.
My first reaction was to discuss the term. If I am certifiable? I? In my mind, I was arguing whether a person can be considered certifiable or maybe the topic of certification is the one certifiable.
As in “Software Testing is (or not) a certifiable topic” against “Johnny is a certifiable (or not) software tester”.

I was puzzled over the confusing choice of words:

A lot of good people (Rex Black, in a moderated way Lee Copeland, Michael Stahl (link to an unrelated article)…) support certification, and a huge lot of good people think that either the software testing arena is immature to certify, or the certifications out there are inadequate, or both (James Bach, Michael Bolton, James Whitaker, Cem Kaner…). For transparency’s sake (so you get the context of this rambling), while I admire and have learned a lot from the first ones, the last ones are personal heroes (ok, Michael Stahl is a hero+guru too ).

So we did not even come to an agreement if the craft itself is certifiable, and you are talking about certifiable persons? How does that work?

.

.
At this moment I stopped musing and went to the dictionary:

Ok, my guess on the meaning of the work was correct: “a certifiable fact“, “capable of being guaranteed“.
So was the other meaning, about certifiable persons: “endorsed authoritatively as having met certain requirements” (in our case, an exam with multiple choice memory questions ).
But wow. That one in the middle is a curious meaning! “fit to be certified as insane (and treated accordingly)”
Certifiable == Insane. And while I don’t see a problem with insane people being ISTQB certified and vice-versa, it made it even a weirder word choice.

I had to search more in the internet to see that this “are you certifiable” idiom is a bit common in english. Microsoft even has a game with this name here.

So it was a joke! Ah, all a joke, but they kept me thinking.
I guess that most of the non-native speakers of the SQE newsletters didn’t get the joke. And they were this close to being offended (depends on the culture one comes from).
SQE (and all), it was good as an excuse for me to post the links for certification articles, but pay attention to your publications’ audience! It takes a lot of time to get your jokes overseas .

Let’s recapitulate my 2008 blogging activity:

• This last year I did not do my self-goal of at least 12 posts, due to the account problem at the beginning of the year.
  From the new posts, one (Testers don’t think like Developers think like Computers) entered my list of ‘classic posts that new team members read’ :) together with A Bug with a Helmet and the “untestable things posts (1, 2, 3)”.
• This also means that, although the blog is kept unpublicized, I’ve got (compulsory) readers now .
• I had at least two very interesting to write BotT: BotT: Excel 2007 has algebra difficulties… and BotT: Linus’ bug, youtube no workee!.
• On the corporate blogs, I started a new series of post about Intel(R) AMT – not as popular as the ASF series, but I got good feedback. Read if you’re interested in the technology I work on.

Hope this next year comes with at least 12 posts, all of them useful.
Gotta start thinking on January’s post…

I am fond of quoting.
Not sure why, but I like to quote. I guess it gives some legitimating to what I am saying.

So, the quote collection is available at this address: http://testing.gershon.info/quote-collection/. It will grow slowly, please check it regularly.

But then the new year came and everything wreaked havoc.
I had hosting issues (of which I am to blame for most) and then had to make a new and different account and restore everything, from the WordPress system to the posts databases, including tweaking the code to look for everything in the new locations. Too much work, too little coffee.

So that’s the reason.
And new year is coming, this time, in April .

Happy New Testing Year, then!
Let’s see if I can continue with the post a month this time

Wait! Should not this section be called “Bug of the Month“, or “of the Week“? No, no. I do not want to limit myself to just one bug per period. Neither I want to commit to bring a bug every week… So it’s the “Bug of this Time“!

At “This Time”, instead of listing a bug found elsewhere, I’ll describe a ‘Privacy Bug’ I once found in the printer of a company I worked for.They had some Xerox printers that performed as Fax as well.

In some (most) of the machines, when you wanted to print a Transmission Report on a delivered fax, you had to drill-down on the printers’ menu, and press the “Transmission Report” option. Send your fax, and after success, a neat report, with a reduced image of the first page of the fax sent is printed out. Cool.

Other of the machines, had a very similar work flow, but to get the report you had to press the “Transmission Report” entry after you sent the fax.
A nice day, I was preparing to send my fax on this machine, and did all the “Report Flow” before sending the fax (just as I would do in the normal machines). Surprise!
The machine printed immediately the Acknowledgement Report of the last fax sent, some day ago. As the report comes with a nice reduced picture of the fax, I was presented with personal information of one of my co-workers .

Of course, I shredded the info right away, and warned my colleague of what happened.

My tester soul pushed me to send my fax and press the option a number of times, and every time the same report was printed. The printer machine did not deleted the info from its memory after being used. So if someone wanted, he could simply come once in a while and print out al the faxes sent by anybody.

This is a very high privacy concern in my opinion, as these info can as well be Credit Card numbers or delicate health matters.

Expected Behavior from a Fax machine like this one (one built to be used on a SoHo shared space):

1. The machine should save the report information (front-page picture) _only_ if the choice was made through the menu _before_ sending the Fax.
2. After printed once, the picture should be deleted.

That’s my Bug of this Time.
If anybody sends me his, I’ll feature it as well. It is not hard at all, there are bugs everywhere! Let me know your Testing Thoughts!

This time I could not miss it.
First day of the year – a very round date to start.
My ‘dieta’ can wait, in 2007 I am writting a blog on Software Testing!

“Why would you do this? Don’t you have enough things to do?“, you would ask, and I would understand then that you’ve been talking to my wife and/or my boss .
Well, I am doing it for you and the world, and for me. I want to clarify to myself what I think, and lapidate my philosophies. I also passion to teach and discourse, so this is a very good opportunity to be my own teacher of testing and of writing. If you or others can benefit from these as well, even better!
((Funny thing is, the posts are password protected, because I probably have to ask permission to my employer before publishing this. So I am writing to myself meanwhile… I will be able to measure my advance throughout the years, yuhuu!))

In the next few posts, I’ll present a bit of what I do, and of what I will cover on the journal.

Be my guest;
 - Let me know your Testing Thoughts!