Software testing is… part 2 – rooted in social science

This is the second part of the series software testing is, based on the mind map I provided in the initial post, you can take a look here:

I bet that big part of the readers of this blog will be puzzled by the presence of the words software and social science in the same sentence and that’s OK. Here’s how it goes.

The current state of thinking about software testing.

When I was a newbie, not that I consider myself experienced now, I am just an old newbie, so when I was a newbie and first started studying the software testing craft I was presented with the following picture of software testing.

Software testing is a technical activity that relies on understanding of the technical side of the product, such as:

  • How the product is built – structure and frameworks
  • How specific functionalities are implemented?
  • What protocols are used for communication?
  • How does an application works – databases, interfaces, memory, processor usage?
  • How the internet operates – basic networking knowledge?
  • How is the application dependent on its environment – OS, hardware, 3-rd party libraries?
  • and many more

All of this is correct, but far from enough. It would be enough, if we only accept the definition that an application is just a series of instructions executed following a specific logic.

I like the example that Cem Kaner gives in the BBST foundation course, saying the above is like saying a house is just a bricks and materials ordered in a specific way, which is not true. A house is a place where someone can live and feel at comfortable, so there’s something more to a house than just the materials. Same with a software product – it’s not just the code, but it comes to partially replace a human interaction, but I will get into more depth in this a bit later.

The soft skills people.

Suddenly, when speaking of testing a person or two will show up saying that testing is not just technical, but incorporates some so-called “soft skills”. By “soft skills” they normally mean some part of negotiation skills, some part of team work abilities, some part of leadership, presentation skills, communication, etc. I say “some part”, because, so far, I didn’t hear or read any credible explanation what “are soft skills made of”, exactly, normally they are a small amount of this and that, etc.

I also agree, that this is important, too, but too general, in my opinion. It’s expected by a good professional in almost any area, interacting with clients/colleagues or any other human beings, to be a good communicator or a good negotiator and a good team player. So, I personally consider these – basic corporate survival skills, they are not something that’s strictly specific to software testing. So, what is it?

Software testing is rooted in social science.

Social science cloud

I mentioned earlier that a software product is not just a bunch of computer instructions ordered following specific logic. Software applications came to existence in order to replace, although partially, a human interaction, therefore, software applications are not only there to do what they are supposed to do, but they also have to bring us comfort and satisfaction. To understand how an application comforts our clients and how we can measure this in a reliable way, we need to understand the human nature and this is where social sciences come to help us. Or, if I have to use the house analogy Kaner made, it will be more useful to know how to evaluate a comfortable house, rather than just knowing how it’s built.

So, many times, under the influence of Kaner, Bach, Bolton and the CDT community in general, I have claimed that software testing is a science, or may be not a science, but uses many scientific methods and approaches and it corresponds with other sciences, not only but we can apply knowledge from other sciences in testing, so our testing can evolve and be more diverse. The aim of this topic is to give some perspective how testing corresponds with social science and which branches of it, I believe were useful for me until now. It’s important to mention that I am not considering myself an expert in any of the following, so all of the conclusions are made by my personal, non-expert, observations.


In fact psychology is a science that can help any aspect of life and it has so many branches and sub-branches, that it will be practically impossible to cover all the possible applications it can have on software testing.

Psychology is science about the mind and behavior and that’s something that we rely on very heavily in testing, in two aspects:


In order to satisfy our clients’ needs, producing specific software product, we want to make them happy, we want to influence their emotions. And in no way, we want to influence their emotions in a negative way. That’s why, psychological knowledge can be useful in software testing, specifically in areas like usability evaluation. If you want more information on this I recommend you the book “The Design of Everyday Things” by Don Norman where you can learn how design of some utensils we use in our daily life has actually the ability to call for specific action.


The second aspect in which psychology can be very useful to software testing is sort of reflection oriented. We are professionals in assessing quality and performing experiments, but how can we say if we make the right experiments, if we have the correct judgement or in other words – how do we test a tester ?

Well, there’s no guideline actually, how to be a better tester or how to have the proper judgement, but we can be aware of what our own weak sides are or what known “defects and features” (because most of them are actually features) our minds have. And this is where cognitive psychology can help a lot.  We need to know how our minds can trick us, how our perception might be distorted, absolutely naturally and how our judgement can become biased. Another interesting topic that cognitive psychology reviews is the heuristic method for solving complex problems. This is a topic that is often discussed in the CDT community and a popular approach of solving testing problems, even when people are unaware they are doing it and don’t call it a heuristic.

A book that might be of great help to those curious of you, which makes a great analysis of all of these is: “Thinking, Fast and Slow” by Daniel Kahneman

Quantitative and qualitative research

Again, without any ambition to be an expert – this is something that is widely used in other fields like statistics and marketing and believe it or not a problem that we solve in testing every day.

In testing we often have that argument on whether or not our testing process should be structured around trying to provide some specific metrics or focus on experiment that is profound and provides valuable contextual information.

Seems that in science this is a problem that existed for ages in the face of quantitative and qualitative scientific research methods. And we deal with it in testing as well. How many times have you heard the argument on whether or not we should use metrics to direct our testing and if yes what kind of metrics, how do we translate these metrics in the language of quality and risks? How are they meaningful for us and for our peers?

On the other hand, there’s this group of people saying that metrics are easily manipulatable and they give us a good statistical results, but bad human or contextual results. They advice us to more “qualitative”, human and contextual approach in testing, which is in its nature experimentation.

Another question arises on how we choose one or the other, or if we have to choose at all? Do we need to combine them? If yes, how do we combine them, which is first, which is more important.

Seems to me we have a lot to learn from the field of qualitative and quantitative scientific research, in fact while preparing this article I reviewed some materials that made me think of a separate post on this topic only, so expect a follow-up on this in the near future.


This might seem a little bit odd to you may be, but expressing ourselves in testing is actually a vital part of our job. I often see people having arguments on the words that we use in testing or what a specific testing term means, what is the purpose of using this term over that term, I also often see these distinctions being qualified as “just semantics”, but I don’t think people realize how vital are these semantics for the quality of our craft. And believe me, this comes from me – a person that normally communicates his thoughts in testing in a language that’s not his native, so I am used to saying something stupid or incorrect and having to deal with the result.

Here’s how proper use of the language can be crucial for testing:

Bug advocacy:

Bug reporting is not just a routine task that we do in our day-to-day activities, although it looks like one. Quality bug report is not “just a bug report”, it’s your evaluation of the quality of the product, sometimes it’s the only proof of your input to the product. So, preparing a high quality bug report is crucial for everyone in the team and the product itself.

The more you develop that skill, the more credibility you and your job gain in the eyes of development, analysts, management and so on. And believe me, no matter how much time and effort you’ve put into building it, you can ruin it within a day, by letting negligence crawl into your bug reporting language, so it is very important to be careful, professional and specific in what we report as a bug. Don’t forget there are people depending on our judgement.

Describe your strategy and tell it in a compelling way

I think I wrote about this for probably a thousand times and a thousand times more won’t be enough to put the accent on how important it is to be able to explain what you do in a compelling and professional way.

Turns out in my experience, that many testers, even experienced ones have no issues performing their job as testers, including all their routine tasks, all but one – being able to explain what do they do. In other words, in the words of Harry Collins in fact, they hold a lot of “tacit” knowledge and they have problems turning it into explicit, in fact sometimes we even fail to explain our explicit knowledge in a good way, without oversimplifications.

This is why linguistic knowledge and the rich vocabulary and the ability to be precise in what you do are so important. Yes, we do report bugs, but no one is looking for bug reporters, after all, they are looking for testing professionals.  In order to be professional tester you have to know testing, to be able to do it well and to be able to explain and defend the approach that you’ve chosen and sound like a professional while you do it.


Philosophy has so many branches and so many great thinkers involved in it, that I can only wish I can make a profound analysis how it is involved in testing. Also, I am probably not going to dive too deep in it, as I plan to write a separate blog post on how software testing is related to epistemology.

Here’s just some quick thoughts on how philosophy is related to testing. What does philosophy means? From ancient Greek, the literal translation is – “love to wisdom”. Well, that’s interesting, I think I’ve seen this somewhere in IT as well, remember these guys that are always ready to learn more and more about the product, that claim software testing is perpetual learning ?

And there’s actually more, but hey, I don’t want to spoil all of it all at once.

And I think this topic became waaay much longer than planned. I hope with the above I gave some more ideas to think on next time you speak with someone on how “technical” testing is and I hope you consider the big part of social science knowledge that we use, in order to be valuable testers.

Of course, I would love to read your thoughts on the topic, that’s what comments are for. Like, share and retweets are always appreciated. Good luck. 🙂

Software testing is.. part 1 – exploratory.

It’s been a while since my last blog post, I took a long break for the summer, but I am still not done with figuring out what software testing is.
Just as a quick overview of what happened until now, the basic idea behind all of that was that I am still seeing people being able to recognize what software testing is not, what doesn’t belong to software testing, but when it comes to define testing or describe what software testing is, they remain silent.
So, we made a quick run through what software testing is not, if you didn’t have the chance to take a look at the series I encourage you to start here: Software testing is not…

And again, I am not trying to redefine anything, I am not trying to make it into the software testing textbooks, although there isn’t any, my sole purpose is to try to make sense of these to myself. If it works for you too or you agree with me, it is just a bonus. So here’s what I figured out about software testing and what it is, for me:



So, here we go with #1:

Software testing is… exploratory by nature.

I must admit that, since I started working as a tester, I always encountered that concept of exploratory testing, mainly in the sense of “mingling around testing” or freestyle testing or non-reliable, but still useful sort of testing, sometimes. It was year ago or year and a half when I started to dig deeper in ET and found what its true nature is, in fact.

Unfortunately the misunderstanding of exploratory testing, being a technique, being unreliable, chaotic, not organized is still present.

The truth is, exploratory testing is not a technique or a method of testing, in fact, exploration is one of the core abilities that testing uses in order to achieve its goals.

All testing is exploratory.

And it’s true, in its nature all testing is exploratory. Testing happens whenever we want to know more about the product, whenever we want to unfold its secrets in front of us. The real moment of testing creation has nothing to do with executing scripted activities – it happens in the moment we ask ourselves and the product the question “What if I do this now…?”.

If you ask a random person in testing – “What is testing for?” or “What is the purpose of testing?” you will probably get a series of answers that are mostly part of the truth, like: to discover bugs, to assure quality, to expose problems, to assess risks, which is fine, but not completely, because above all of these we perform testing in order to gain information about the product. Information that is vital in order to assess risk, find bugs or any of the above. Such information could be obtained only by exploring the product and all the assets that come with it – documentation, user guides, requirements, design plans, etc.

Problems with exploratory testing being a technique.

In different resources and according to some testers, exploratory testing is a technique of testing, and testing could be either exploratory or scripted, which I think is wrong.

Let’s start with a logical question – if we claim that exploratory testing is a technique and it can be completely replaced by scripted testing, how are we gathering the information that we will use in our testing scripts if we have never explored the application in order to make ourselves aware of it, what parts does it have, what complexity, etc?

There can not be scripted testing without the existence of exploratory testing. The claim that there could be a test script or a test case that doesn’t contain information or insight gained with the help of exploration and experimentation could mean only one thing – that we have a script or a case that has nothing to do with the real behavior and the real application, but rather with a model that we built, based on something else, but not the real product.

Yes, I know how many will try to counter this – how about documentation, user guides, online help, etc? Well, here’s a thing – having your testing based on the docs or any other artifact supporting the product is testing only the artifact or what that artifact claims for the product, not the product itself. There’s many occasions and I believe everyone experienced this where documentation is outdated or doesn’t exist at all. How do you construct your testing then, if you only depend on documentation?

The bottom line of this point is – testing’s main purpose is to interact with the product, to dig deep in it, to experiment with it and to explore it and this could only happen with the help of interacting with it, happily there’s no other efficient way.


My opinion and based on what I learn and experienced so far, is that it works best if we approach testing a new product just as we would if we were conquering a new land. There’s no rules, there’s no limits, there’s no expectations – we get to know them on the fly, we adapt and figure out our strategy while we try to explore the possibilities this “new land” has to offer.

That’s it for now, see you next time. Don’t forget to share and retweet and as always I will be more than happy to read you thoughts in the comments. Good luck!


Organic testing

Note: Before I start this, I want to share the story how it came to my mind. I was working on the Lightning talk – “The hidden wisdom of the testing troll” and I actually made it as a joke, using all the public buzz that all organic food offer. When I thought about it, testing is organic in it’s nature. So, I decided it’s worth it to split that topic in a separate post.

It’s also worth it to mention I recently found out that James Bach once made a talk for Apple called “Organic QA”, I saw it in his archives, but I am not aware what he was talking about, since it was internal talk for Apple employees only. So, I am in no way adding anything to his point, yet I will be interested to know what he was talking about, if at some point he decides to share it.

How “organic” came as term in first place.

I mentioned a couple of times a talk about education by Sir Ken Robinson, where he compares the current state of education to a “fast food” model – it serves high demand of production, it aims to produce the same product, no matter which school or university the graduate is from and mostly it applies the “one size fits all” strategy, using formalized tests in order to measure and assess knowledge. What Sir Ken Robinson offers an alternative is a more “agricultural” or “organic” approach to education, where every student is given personal care, based on his needs and his “talents”, because human creativity and intelligence are diverse and unique and we can’t try to “equalize” it by applying same principles to different personalities. It is a very interesting talk and worth watching it, if you didn’t I strongly recommend it to you.

Seems we have a similar problem in testing, too…

While I was talking of education, do you felt we can relate some of these things to testing, too? Me, either.

In the large-scale. Testing is thought as a process that could be “mass produced” just as in a fast food restaurant, that testing skills are something that could be trained just as easy as making hamburgers.

People pretend testing is a skill that is easily transferred by repeating monotonous, meaningless actions that are meant to be based on some script or scenario, pretend testing is easy to learn, easy to master, as long as you follow the steps carefully.

Not long ago, I listened to this wonderful interview by Joe Colantonio with Gerald Weinberg. In it Jerry mentioned how testing appeared in first place, as a job that developers didn’t wanted to do themselves – testing, so management decided to give the task to a specific role, to someone they will pay less than a developer to do.

And like it or not, I still see signs of that attitude towards testing nowadays. Testing is always considered less technical, less creative than development, less experimental than development, if you like even less intelligent than development. Tester is commonly thought as a person that is just “looking for bugs”, “checking if it’s O.K.”, “playing with the product”, “responsible for quality”(keeping in mind nobody normally speaks what quality is, to whom the product is considered of high or low quality and why are we evaluating it in first place).

And that all “mythology” around testing is false, bad testing might be performed like this, lazy testing might be performed like this, but not what we aim for – expert testing. I spoke a lot about this in my series “Outdated testing concepts” and “Software testing is not…”, about the falsified mythology of testing. So, here we get to the bottom of it, what is testing? Well, I might for sure say that testing is organic.

The organic nature of testing.

And of course we are not talking about any testing – we are talking about testing performed by qualified, educated, self-driven and ready to develop person(big emphasis on the word person). Yes, we are looking for a personal approach – as it was mentioned above, intelligence is diverse, humanity is diverse, and this diversity is actually something we are looking for, something we are interested in. The way that one tester will look into a problem, the way one tester will perform testing is unique to him only, and  this kind of diversity is something we are interested in, not mass-producing testing minions that think alike, act-alike and test-alike.


Why is testing organic?

  • Diversity as opposition  to conformity – as mentioned above, organic as opposition to the “one size fits all model” is what we are looking for. We are looking for every tester’s personal view on the testing problem, we want variety of solutions, not just any solution, we want many paths in which we can obtain information about the product, the risks that it has, the needs that it will satisfy, not just one solution.
  • Testing is constantly evolving
    It’s a fact that  many people try to make us testers believe, that testing is the same as it was in the 70s or the 80s that nothing has changed, that it lies on the same principles. Well, news flash – if it was like this, if testing wasn’t evolving, it would have died, simple as that. This is another proof for the organic nature of testing, it is constantly evolving, and all of us involved in it, contributing to it in any matter – surveys, blogs, discussions, magazines, podcasts, webinars, workshops, courses, books, anything helps develop and refine testing as a craft or in other words, help it evolve as an organism.
  • It has its own life cycle.
    I know many of us were forced to think testing is part of another cycle – the Software development life cycle, but testing as a process has life cycle on its own. And we are supposed to be the ones who have to be aware of that life cycle – when is the early pre-mature period, when it is too early to start testing, when testing will lead to no results or such of low importance, when is the peak, when is the period when we are able to explore the full potential of the deliverable we are testing and when is it to late to do it. All these, again resemble to me, organic nature in the process of software testing.
  • It can not be  fully automated.
    And the reason, as mentioned above, is diversity. We are interested in the different things that human testers can do, not the repetitive ones that our scripts can perform over and over again. Because where there’s unpredictability, that’s where the interesting stuff happens. Of course, automation has its honorable place in the testing process, but it’s in the tool domain, not in the organic part. If you are interested in my more profound opinion on test automation, you might like to take a look at Test automation – the bitter truth.
  • It needs specialized, constant, adaptable care, in order to produce something meaningful.
    Just as any other organic thing, no matter if it’s a carrot or a dog, testing requires specialized care in any case where we approach something to test it. Yes, we might rely on same principles, but we have to adapt the specific contextual needs of the situation in order to produce satisfying results with our testing. That’s why we don’t rely on algorithms, golden, rules, best practices or any other magic formulas, that seem to offer solution, but are somehow not following that same principle.

That’s it for this post. I hope you don’t mind my metaphorical style in it, it was all meant to be  for fun and interesting, I said I will write about it, so it was an experiment I had to do. In case the topic was  interesting, as always I will appreciate your opinion in the comments, tweets and shares in the social medias. Thanks for reading and good luck. 🙂


Some kick ass blog posts from last week #12

And we are going back to some kick ass blog posts from the last week:

Another round-up posts:

Automate the planet’s Compelling Sunday by Anton Angelov.

That’s it for now, see you next week. 😉

Outdated testing concepts #2

Link to part one: Outdated testing concepts #1

This week’s outdated concept will be dedicated to the “quality guardian” or “The gatekeeper to our product’s success”.

Outdated concept # 2: The holy guardian of quality.

quality stamp
Source by:

The first stereotype that was branded in my brain, in the first months I started working as a tester was: “QA is the person responsible for product’s quality” and “Your job is to prevent bugs from being released in production” or “Your job is to test the product so it meets the functional requirements / acceptance criteria” and so on.

I can now recall that I wasn’t really happy with the job title “tester”, to me it used to sound like someone who’s about to get shot out of a cannon or perform crash tests on a car or something. In other words “tester” seemed to me like a bit of an insult, while Quality assurance … wow that was shiny, at least to me, at that not too distant point in my past, it was rock star title to me, I was responsible for the quality of the product and I was told, I am the man to give my final verdict on shall it live or we will have to fix bugs until it’s done. Seemed like a pretty bad ass job to me … and it was all lies.

How are we responsible for quality?

Now, enough rainbows and unicorns so far, we are back in the present and we put on our “investigation hat” and analyze our part in product’s quality, and if it is really the principal role that was described to us, or just another outdated concept.

Let’s start at the pretty basic level:

  • If the developers are writing crappy code, no unit tests, can we impact on that aspect of quality?
    No, of course we can discuss with them, brag, ask, threaten or whatever negotiation tactics we might use in order to make them do it, but we can’t actually force them to do it, therefore we are not responsible for that part of the quality, of the software product.
  • If the requirements for the new features in our product are vague and ambiguous, impossible for us or the devs to decipher, do we have the power to change that?
    In fact we can, but it doesn’t guarantee anything. Why is that? We can protest against bad written requirements, we can ask for revisions and meetings in order to “sort things out” and make them clear and understandable for the whole team, but let’s face the reality, we are in the 21st century, we are mostly being involved in Agile and Scrum projects, because development teams like changes and they like ’em in big portions and at really high-speed. These poor requirements are probably not going to be the same only in a week, and who says they are the only source of knowledge for the product? What about the emails, or instant messages, other documentation like design blueprints, how about meetings, phone calls, conference calls, hangouts, 1 on 1 meetings or managers who tend to sit next to a developer and tell him “how it is supposed to work”… Do you still think you have reach on all that ? I strongly doubt it.
  • If the management takes bad decisions for the vision of the product?
    No, after all we are there to help the product to succeed, but it’s not our job to manage it. Of course, we could be involved in management, but there’s certain management decisions that could not be argued. And this is the end of the belief that we have the right of “veto” over the release. And me personally, I am happy with that, I wouldn’t like to bear the responsibility for that decision on my own. This isn’t one man decision for a good reason – everyone makes mistakes and we don’t want to turn anyone, not just the tester, into a sacrificial lamb. It’s easier to have someone to blame and many companies might still do this, but it’s not the way to progress.
  • Can we assure the quality of testing in general and/or the quality of our own job?
    This is a really tricky question, but I would say no. Do we really have a way to track the work progress and quality of the other testers, can we guarantee that the job they perform, even if documented, follows our understanding of high quality testing? And what’s even more critical – can we guarantee the quality of our own job? I personally wouldn’t, because it will be easy to delude yourself, and after all we as testers must always be suspicious and even our own skills should be tested and analyzed, through our own senses as well as from the feedback that other members of the development team, Only this way, we can be sure, that the job we perform adds value to the project, not only to our expertise, or as Keith Klain mentioned in a talk I linked in this post, this is a way to make sure “we are performing our testing holistically”.

And the list goes on and on… So, as we see, the responsibility about product quality isn’t a single person responsibility, it’s a team responsibility. Not in the terms of  “shared responsibility is no one’s responsibility”, but in the terms of, everyone adds value with his own unique skills to the product and bears the responsibility for the consequences of his mistakes.

So, from the picture that I drew so far it seems a bit worrying what we can do, isn’t it? Don’t worry …

“There has been an awakening…”

We are no longer happy being called QA and we realize that our real profession is testing. And by testing I don’t mean just “play with the product”, as we often get thought to believe by non-tester individuals, but the process of analytical, conscious experiment with the product in order to explore it, evaluate it(J.Bach) and provide expert opinion what are the possibilities for it to succeed or the risks that can lead it to failure.

So, how could we promote our job, from all what I said, doesn’t it seems that we all have no chance to change anything? No. Here’s a good list of actions we can perform to promote the real value of the testing profession:

  • We have the most wonderful, interesting profession in the software business – the testing part, we can experiment with the product in order to expose its weak and strong sides.
  • We can construct our testing as complete scientific experiment and develop not only our testing, but as well our scientific skills and the way we learn.
  • We have the opportunity to put our hands on the product first, after the development team is done with it.
  • We have the opportunity to mediate between the marketing, business, management and the technical teams within a software project and in this way learn way more information than any of these departments’ representatives alone.
  • We can literally break stuff and no one is angry with us, sometimes we even get congratulated for breaking it. This is a joke of course, we all know “we didn’t break the software, it was already broken when it came”(Michael Bolton).

The list goes on and on. As you see, speaking of software testing as simply “someone being responsible for the products quality” is just naive and barely touches the surface of what software testing profession really is.

And last, but not least, I believe that the main way in which we can drive our profession to progress is:

I believe James Bach once mentioned these..

  1. Learn the testing vocabulary and terminology.
  2. Learn the testing methodology and techniques e.g. learn how to be experts in our craft and how to provide high quality service as testers.
  3. Learn to explain our craft in a manner to promote our profession.

And I believe the last one is really important, we need to make ourself heard and seen, we need to learn to give a compelling story on what testing is and what is its true value.

That’s for this week, I hope it was interesting and useful, stay around for the next part. I will be happy to see your feedback, as always. Good luck 😉



Outdated testing concepts #1

End of the previous year and the beginning of the current one are normally the time we are determined to make new year’s resolutions, which most of the times turn to be big, fat lies, but anyway. I am not writing this to make resolutions, but to set goals. And we as a testing community have a lot of work to do in order to progress, since our craft was, as James Bach called it, “in perpetual childhood” for more than couple of decades. I believe the reason for this is there’s still a lot of misconceptions, myths or just outdated beliefs about testing that need to be declined, so we could progress in the right direction and leave the useless luggage of principles that never worked or were ineffective.

Stereo cassette
Image source:

So here is our list:

Outdated concept # 1: Testing is easy. Everyone can do it.

This concept was around for far too long and I believe every one of us had to explain at least thousand of times how our job isn’t simply “play with the product” or “break something” or “find the bugs” in it. Testing craft is profound and complex as it possibly gets, and no, testers are not failed programmers, they just don’t mix with programmers. Anyway, this is useless info, since many readers of this are testers, this isn’t helpful at all.

The thing that really surprises me is that companies accepted that concept for granted and even adapted their processes to it. All the outsourcing companies try to make new testers believe that it’s isn’t up to tester’s specific skills and knowledge of the product, nor the experience he has, but the documentation of the processes itself. They will make you believe that testing could be performed by mindless morons and you should write your test plans and test cases as if they going to be read by mindless morons. This way, they assure once you are gone, next totally green and incompetent tester will take your spot doing just the same.

Their biggest fear is when you try to defend your value by explaining how complex a testing process is and that in fact IS scientific experiment with all it’s assets, therefore needs educated expert in order to be performed in the right way and effectively.

I had an interview once, the interviewer was only concerned if I could write test cases, just that. So, we had an argument, that testing shouldn’t be determined in a specific set of actions to be effective, that this is only one approach to do it, that testing documentation is not test cases in the best way and that testing process is far too complex and fluid to define it as a set of rules, it depends on observation, critical thinking, oracles, assumption, risk assessment, heuristics etc, etc … Poor guy was almost shocked. It was a cataclysm in his poor narrow view of what testing is, finally he got relieved by knowing I am able to write test cases, but I don’t like to, because it’s boring and doesn’t document the way that I perform testing. I finished with the statement that this is so-called “best practice” we tend to stay away from, because it’s not always relevant. The answer was: “Well, you see, these are best practices for a reason”.

So, how can we react against this and justify the importance of testing as an experimental process and not just scripted activity?

  • In first place you don’t have to be afraid to stand for your beliefs, make sure you are able to explain the work you do, not just do it.
  • On the opposite, make sure you could give clear examples “why” and actually apply what you believe in and not just brag about it. Demonstrated knowledge is one of the most valuable skills in any craft.
  • Don’t expect anyone to know the specifics of testing, it is our job, but give the details carefully and in understandable manner for a person that has no background in software testing, as they could cause a lot of confusion if served at once.
  • Knowing your craft and being able to answer the question “why” is vital for your development as a tester. As you see from the opponent’s view-point, in my interview, the answer to the question “Why follow best practices?”, varies from “Because we have to”, to “because everyone else does”. As you can see, it’s not an enormous effort to question such an explanation and we could definitely do better than that.

I wasn’t expecting this to get so long, but as it gets in testing, things are dynamic and we should adapt to them. I will write some more post on obsolete concepts later in my blog.

Important notice: Some important sources that provoked me to get to this point are the book “Lessons learned in software testing” by Kaner, Bach and Pettichord as well as the videos from Introduction to BBST by Cem Kaner.

Skill set of a software tester – pt1.

I decided to mind map the skills needed to be a let’s say “the best software tester” in a perfectly designed world. Of course, i don’t imply all of them are obligatory, and after all it’s all my subjective view.

Software tester’s skill set – mind map.

skill set of a tester mind map


Here I will explain (and I will try to be short, or more likely, struggle to be short) why I picked these specific skills and why are they essential, what did I meant by that specific phrasing.

 Hard skills:

If we keep up with the definition there’s hard and soft e.g. technical and human skills, the first (right) branch of our skill set is the technical skills. I don’t want to put any priority to eighter technical or soft skills, but to me personally it looks like the industry is lacking technical skills, rather than the soft skills. In fact, the soft skills are more general ones, they could be applied practically in any area of business or science and yet be useful. I will start with the more general tech skills and proceed with the more specific ones.

 Networking, protocols and services.

As I mentioned, I will move from more industry generic skills through domain specific, to profession specific skills. And mastering, or at least understanding the networking and services fundamentals, is something everyone should include in their personal development path.What I strongly recommend to get familiar with is: the OSI model, TCP/IP protocol (you might find Cisco’s book very usable here), REST, SOAP, oData. These are practically the building blocks of any device around you, some of them might be a little bit old, but all information will be useful to you as a source of basic IT knowledge, it’s almost impossible to be valuable testing expert if you don’t familiarize with these, at least at some high level.

General OS knowledge.

This again includes core IT skills, these are a must. And to be honest if you are just curious about technology, you will find it easy to explore and learn to use new operating systems. Good things to learn here are, of course Windows, Linux and Mac OS, just because you want to know what are the differences across desktop OSs, may be a couple of server versions of Windows and Linux, just to spot the difference. On the mobile side, since mobile is already a standard, not just a “nice to have” anymore – it will be good to be familiar with iOS and Android of course and since wearables are sneaking into the scene – Tizen and Android Wear OS.

Testing is all about context and preconditions, the operating systems you are using to test your application will be essential for the information you will learn during the process of testing.

Software development life cycle knowledge.

Just as much as any other craft, software development has its rules. Car industry has a process how to manufacture cars, architecture – how to create a building, same with software. There are rules and processes in making software and like it or not, you will have to follow them, or at least know them as good as you aren’t harming the process. So, couple of software development methodologies you may want to add to your knowledge base are:

And again I say, you don’t have to become fanatic, after all it’s a process, you learn it best by doing it, by actually being involved in it, but it will be valuable for you to add this to your skill set in order to prove yourself more valuable than the others.

 Testing terminology knowledge.

Another valuable asset to your skill set as a tester is knowing the language of testers. You shouldn’t be confused when someone uses terms like regression testing, system testing, usability testing, etc., all of these should become part of your dictionary. As James Bach says, one of the key things a testing expert should master is to express in words how he performed the process of testing. This is valuable in two ways – to justify your knowledge as a specialist and to prove the depth of the job that you’ve done, instead of writing shallow documentation that has no meaning. I will strongly recommend you to watch the videos of Foundations in Black Box Software Testing – by Cem Kaner, Bach and Bolton, which gives a lot of good explanations, examples and a lot of literature.

 Databases knowledge.

This asset to your skill set has a little bit more to do with the domain specific and profession specific part of it. Knowing DBs is essential to all testers, because in our practice we need to deal with a lot of them. So, may be some knowledge in the following areas will be beneficial for you:

  • Types of DBs – Oracle, MS Sql, MySql
  • Difference between relational and non-relational database.
  • What are primary and foreign keys.
  • Some basic commands – CRUD operations.
  • Creating a table, deleting a table.
  • Creating a back up, restoring from back up.
  • Joins – left, right and inner join – differences.

All of these will be useful, believe me.

Algorithmic thinking.

You will probably ask what is that and how you train it, isn’t it just a dev thing. Well, no it’s not. Algorithmic thinking is the ability to get a complex problem and split it into small enough chunks which are on their own simple problems, then by combining these and arranging them in the correct order, to progress in solving the complex problem. And yes, there is a way to train that skill. Testing is one way, searching for a way to expose a vulnerability in the security of a system is, for example. Another way to train your analytical thinking is by playing games and by this I mean even computer games. Video games nowadays are really challenging. Other ways of improving might be – word games, crosswords, Sudoku, simple logical games and of course – solving programmatic problems by writing them in pseudo code.

 Scripting language.

For sure it is always useful having this in your skill set – if you need to deal with the console in Linux or if you need to automate some simple dumb task in your operating system. It will be a good idea to take a look in shell scripting tutorials as well as couple of Powershell, incase you need to write scripts in Windows.

 Programming skills.

Yes, this one, too. Don’t start crying how you don’t want to be a dev or how non-technical you are, no one is listening to you. It is always good to know the inner workings of the application or system you are testing. It’s not obligatory to be too good, as long as you could understand the code at least at high level or at least anticipate how the code is written in order to predict presence of a mistake in it or a misconception that novice developers might have. As a helper I will recommend  EDX’s course CS 50 which cover pretty much all the basics of programming and web, and learning two essential languages – C and Python. First one, because it’s light weight and practically transparent for what’s happening even to the lowest levels, also almost all modern languages inherited it’s paradigms, I’m not saying it’s easy, I am saying it’s educational. Python, because it has easy syntax and is generally usable as programming and scripting language. Every language more than that is always welcome and will only broaden your horizons as a technologist.


Well, like it or not automation rules in software testing and it’s a valuable skill. There’s a huge variety of tools to automate trivial tasks in the UI, headless testing, component level testing, acceptance testing, penetration, load, performance, building CI with automated tests or any other testing related infrastructure – there are plenty of directions you may go if you are into automation. If you succeed to learn even a little bit of all of the above, I am pretty sure your transition will be smooth and you will be able to adopt any technology faster.

In the next post I will focus on the other branch of the tree – soft skills.

If you liked that post, don’t forget to share with your friends and comment. Thanks 😉

Testing is a mental process.

It has been a while since I last had the time to sit and write a post here, so I guess I am now a bit rusty and hard to start, I have all these crazy ideas fighting in my head and it’s really hard to make them sit in their spot until their turn comes, or just until I have a clear vision of what’s it all about that I want to write for.

I am already one year and a couple of months in the QA business and I can say I learned a lot of stuff and there’s certainly a lot more to learn coming. But I am not a shy guy, I don’t feel I should be for any reason and that’s why I chose to comment on a topic that I feel is going wrong in software testing.

Labels – are you on the manual side or on the automation side?

Well I guess the answer here is a Matrix like one: “There’s no spoon.” in first place. Why do people still label testers with automation and manual? I see this everywhere – “we are hiring people for manual testing only”. So what should that mean? They are hiring “clicking/tapping monkeys”, or that the job there would be boring and not catching up with the latest tendences in testing? And I see people going extreme when it comes to manual vs. automation testing. I’ve heard stuff like: “It’s a good automation framework but it won’t help you validate if user interface looks good or is usable”. Well, of course it wont, it was never meant to. I feel like many of the testers act like doing automation, they will never do manual testing again or believe that when start doing automation, somebody will probably rip their brains out of their bodies and put them into this Robocop-like suit, where they will never have human feelings ever again and will never be able to simply do exploratory testing or any other manual testing strategy. On the other hand, the “only manual” defenders fail to give a good reason on how you are testing performance with “only manual” testing methods, for example or security or just simple functional tests of the application. I believe that hiring a 1000 monkeys to tap on a button or perform a log in is a way, but let’s stay focused on reality.

The idea is…

What I am trying to say is – it’s not that simple. You know, dividing software testing in manual vs. automation testing isn’t as easy as determining what transmission does your car have. Yes, there is people who are more likely to understand code and complex tools and scripts, and there’s other people willing to touch things and explore them with their hands, but I really don’t think that’s the reason to treat both approaches as if they were something different. Why? Because after all, testing is a mental process, this is what you do in your head, trying to figure out complex scenarios how to expose a system’s weak spots or security issues or whatever. And it has nothing to do with tools, plans or test cases, in other words testing in general answers the questions “What am I doing here? What is my purpose in this team?”. And manual or automation approach is just a “tool” that you are going to use, to fulfill your plan. It really is as simple as that. In other words manual and automation are answering the “How am I going to do it?” question.


As we think of it, the reasonable way to approach testing as it is – as one whole and complete thing. Even if you are so called “automation tester” you will need to perform manual testing at some point – to check usability or any other non functional aspect of an application. And there’s nothing wrong with that, you won’t loose your reputation as a good “robocop” if you do some manual tests.

As for the manual testers, you shouldn’t be afraid to do automation at any point. And it really doesn’t matter if the title says manual or automation tester. Does it include coding/scripting skills? Not really, there is plenty of recorders and other tools with user interface that has nothing to do with coding. Does it mean to be technical? Yes, of course this is what QA means in genreal, you will have to know networking, you will have to know how services work, databases and probably some scripting skills, but it all depends on how deep you want to dive into it. And after all it’s all basic concepts, once you get them, the language, the tool, the project will be just a detail, because you will have all necessary knowledge to tackle the problem.

So how does our perfect QA looks like.

I have a picture, I can show you right now: 1robots-gal-terminator My believe and what I am trying to do as tester is try not to get caught into semantics of phrases like manual or automation tester. To me, testing is an abstraction, it has no form, no taste and no looks, and whatever I do is all up to my creative thinking and imagination. And I like to think of manual and automation testing as the top layer, the application layer of the whole thing, where the abstraction get it’s concrete realisation.

If I have to do some tough and time consuming task that consists of doing same action over and over again, I would love to write a script for it and automate it. Other wise I love to poke stuff on my own while getting to know the application, it just comes natural.

So that’s it, this is what I believe, this is what I recommend. Is it perfect? Hell no! Would it work? I don’t know, go ahead and test it, we are testers after all, so “Trust is good, test is better.” I would love to read your opinion on it.