Category Archives: Articles & Publications

Its been a while

Haven’t done a blog post for awhile

And it has not been because of lack of interest. Mostly i think its being because, well it can be bloody over-whelming sometimes,  to be a tester (lets not even consider been a GOOD tester).

And this is why this particular article has drawn me back into my own blog (my own mind dump which i think still has 0 readers / watchers)

Firstly, a clarification on where i stand. I don’t think testing is harder than dev. Think both of them have their own challenges and dramas


James Willett is correct. Testers DO need a lot of skill sets.

We are not here to prove something doesn’t work.

A Testers World Is:

  1. We have to think like every player involved (think PM, enduser, fellow team, stakeholder, actual behaviour)
  2. We do test, write docs, sometimes code, throw in a bit of BA and product management in there as well
  3. Tell a bunch of hopeful faces bad news (sorry guys i know the go live date is x but y still does not work)
  4. Training – urh sorry what ?? How do you write a test case? Well you look at requirements and then write things down. Oh set of guidelines that we follow all the time, there isn’t one
  5. Expectations. Everyone’s expectations is now my problem. And will always be regardless of how well things go or how badly. And each expectation is just as important as the next persons
  6. Shit goes sideways and the question will always be why wasn’t this picked up during testing but if things do go well, the devs are doing a great job!
  7. And if you are lucky (like i currently am) you have a bunch of devs who do litsen to your input. But usually, we testers need to have loud voices if we want to be heard

All this + knowledge of every db, system, architecture, language, program, app, tool in order to be marketable. This can be weighty, especially when you want to survive

How do you survive?

Well i will let you know when i have answers

Until then from this tester to another, laters


7 practical software testing tips-from testbash.

Great article with some very useful tips on Software testing.

My personal favorite is Mind Maps – mostly because I seem to be using it more and more. It is very important to note that people all work differently and different tools will apply.

I am more a visual person (the kind that likes to draw to explain things) – so Mind Maps are a great choice

Testbash – Article

Types of Testers

I really like the blurb from Jon as below. Its a simple explanation of testing approaches. Currently i am a Tester and i want to develop into an Omega Tester

Taken from blog post from Jon Bach

What kinds of testers are there?

  • Automated? Manual? There is no such thing as manual or automated testing. It’s all just testing. Testing is often supported by tools that attempt to simulate user interaction with the system. This is what people call “test automation” even though it is only automating a crude approximation of one aspect of testing. If you have the ambition to be a one-man test team, it is extremely valuable to learn how to make your own tools.
  • Exploratory? Scripted? There is no such thing as an exploratory or scripted tester. All good testing is exploratory to some degree and scripted to some degree.
  • Tester. This is a testing generalist who can contribute to any test team. Sometimes called a QA analyst, QA engineer, or test engineer. I prefer the simplicity of “tester.”
  • Omega Tester. The omega tester (which I sometimes call a test jumper, after the analogy of a paratrooper) is one who can do anything. An omega tester is equipped to be the only tester in a project team, if necessary. Omega testers can lead testing, or work with a team of other testers. I am an omega tester. I aspire to be a good one.
  • Performance Tester. The performance tester understands the mathematics and dynamics of the performance of large-scale systems. They use tools that create high loads and measure the performance envelope of systems as they scale up. Performance testers often don’t think of themselves as testers.
  • Usability Tester. The usability tester is a bit mythical. I have met only two dedicated usability testers in my entire career, but I have seen more of them from a distance. A usability tester specializes in studying how users feel about using and learning a product.
  • Security Tester. Security testers also often don’t think of themselves as testers. Security is an exciting, specialized form of testing that requires the mastery of a great many facts about a great many technologies.
  • Testing Toolsmith. A testing toolsmith is a programmer dedicated to writing and maintaining tools that help testers. This is what a lot of people would call an “automated tester” but you better not use that term around me.
  • “SDET” Software Development Engineer in Test. This means a full on programmer who does testing using his programming skills.

Autonomy At work

Article “10 Ways in which software testers can win autonomy and earn respect by Jennifer deJong Lent in TechBacon taken from

Autonomy has always been important to me. Mostly because i do not enjoy been micro-managed and also because to me, it shows that i am trusted enough to make decisions on my own and do the job. I was lucky enough to have this at my last job, and a lot of the autonomy came from my 1st managers approach to effective team management. My second manager, however, it took a bit more work to get to a stage where it was evident that micro-management was causing disengagement.

So how to get to autonomy?

According to this article and from test guru Jon Bach – “He interacts with his tech and business peers in a thoughtful way. He asks questions. He listens carefully to the answers, welcoming unexpected outcomes. He’s willing to be wrong. He’s keenly aware of how behaviour influences the way he’s received by the people he works with. Self-awareness, he says, is essential when telling developers about potential problems you’ve uncovered in their code. “Your job as a software tester is to reveal problems and vulnerabilities in the application under test,” says Bach, author of the blog Tested: Highlighting the humanity in software testing. “You have to behave in ways that improve the situation.

1. Assume respect from others

There’s only one place to start, says Bach. “Let’s assume we do get respect.” If you’re willing to be bold, rejecting the status quo can result in positive changes. For example, instead of grousing that you weren’t invited to the software requirements meeting, show up and take your place at the table. Bach has done just that and was well received. “Whatever you feared isn’t likely to happen,” he said.

I have gone into meeting as a TA and have always been welcomed as a resource, someone there who is able to answer testing, resourcing, timelines, and workload decisions immediately.

2. Behave in ways that improve the situation

A software tester’s job often requires walking a fine line to not offend while making sure no concern goes unaddressed. “I don’t want to waste anyone’s time. Nor do I want them to not consider my issue,” Bach says. One way to be effective is to approach each issue as a fact-finding mission and remain open to the outcome. 

Instead of saying something doesn’t work, provide data that shows the difference.

3. Aspire to excellence

Establishing and adhering to broader principles that guide your work provides a helpful framework for dealing with difficult conversations. As a software tester, “I am vigilant about improving the culture, improving the process,” Bach says. He recommends that all software testers define their own standards of excellence and act accordingly. “What makes you excellent? What does excellence mean?” This doesn’t happen overnight, but it’s useful to understand the answers to these questions, he adds.

Do the best that you can and keep trying to be better at it

4. Ask the dumb question

Here’s a scenario common to all professions, not just software testing. You’re in a meeting. A question or comment occurs to you, but you keep silent. “Nine out of 10 people don’t speak up,” Bach says. But hiding what you don’t know—or failing to weigh in with a concern—is a mistake. Bach once asked: “What’s a bug?” Some peers may have given him funny looks at first, but a meaningful conversation followed. “It was almost Zen-like,” he says. “I don’t mind being the one who asks the dumb question.” How does Bach define a bug? “Every bug is a story. I wanted something to happen and I got this instead.”

There is seriously no such thing as a dumb question, Ask away at anything, you will be surprised.

5. Provoke a conversation that has to happen

Software testers can earn respect by taking the lead when problems arise. “I go to the whiteboard and draw my understanding [of the issue under discussion],” says Bach. Participants weigh in with their feedback: “Yes, ‘that’s the model,’ or ‘do we need this piece?'” they might say. “A good software tester doesn’t mind playing agent provocateur. It’s about provoking a conversation that has to happen.”

6. Go meta

Another leadership tactic Bach employs is to focus on the big picture—beyond the project and the company. “A good software tester can go meta,” he says. As a way of determining acceptable page load times, Bach once asked: ” ‘How does Amazon do it?’ It was a way of seeing how our own product was doing.”

What is the big picture? What are you hoping to achieve? How does a bug affect the whole thing?

7. Expect scrutiny, and be prepared

Software testers who do their homework get respect. “When you go in with a bug, expect questions, and make sure you know the answers,” Bach says. For example, if the bug occurred in the Chrome browser, a developer is likely to ask, “Does it happen in Safari? Did you clear your cookies?” There’s going to be scrutiny, Bach says. “You want to be able to say, ‘Yes, I checked that.’ “

Sure you found a bug. But what else. Where else? How? Check, check and recheck

8. Save face by using safety language

The most effective way to describe a problem found in testing is to use what Bach calls “safety language.” Phrases like “It seems as if” or “It could be” or “according to what I saw on my machine, at this time, under these conditions” show respect for others. What’s more, they let you save face when, for example, a developer tells you, “You didn’t configure your environment correctly. You didn’t set the flag,” Bach says, recounting a situation that actually happened to him.

Don’t assume its broken because you found something.  Check

9. Just say “Got it”

Software testers are vigilant about finding and fixing vulnerabilities in code. But you have to know when to stop. A developer once told Bach: “Jon, relax, this is a just a beta. It went to three customers.” When that happens, stop talking, and don’t explain. Just say, “Got it!”

There has to be an end point. As a tester testing never stops, you should know when to stop

10. Prepare to be tested

To maintain the respect of others, software testers should be ready to work in a hostile environment. That way, you won’t lose your cool when things get tough. “Keep your center; don’t get excited; don’t get defensive,” even when people speak harshly, Bach says. “Prepare to be tested yourself. Be prepared to be wrong. Keep an even keel.”

Keep your heard screwed on, and prepare to be asked the hard questions

What drives Bach’s approach as a software tester is simple common sense, and yet his tips for succeeding—and being received with respect—are notoriously difficult to implement. But they work for him: focus on your humanity. Be honest, do your homework, stay self aware, be open to all outcomes, define and follow your own code of excellence, know when to stop, and be willing to be wrong. “It is simplistic,” he says, “but not simple.”

It Works!

Taken from blog post by Michael Bolton It Works on March 31st, 2014

What does it mean it works? I have heard this terminology used in the work space, and then heard someone else come back and pretty much reduced it to nothing. IT says it works, Care or Sales etc. will have a very different view point..

According to Michael, “To me, when people say “it works”, they really mean

Some aspect
of some feature
or some function
to meet some requirement
to some degree
based on some theory
and based on some observation
that some agent made
under some conditions
or maybe more.”

Just because someone says it works, a tester does still need to “question the statement “it works”, to investigate the claim, and to elaborate on it such that important people in the product know what it really means.”