Hello! I know some of you have seen me around, but I’d like to take the chance to introduce myself. I am a newer member of AST, who not very long ago had context blinders removed, revealing what software testing can be. I’ll never go back to prescriptive process! Because I love an adventure, the AST Board […]
TL;DR In this post, I will try to elaborate why is often expected from me as a tester to create meaningful application error messages. So, you are using some web application, and you get something like this( thanks to Evil Tester): And that error message does not tell you anything about your action or input. At … Continue reading What is happening in our application? →
One thing I owe my readers is a full review of LoseIt. I keep saying I’m going to do one, but each time I try to get into it, I find the review keeps getting longer and more detailed. For those willing to wait for that, I’ll plan to post it by the end …
This week’s Cambridge Tester meetup was a show-and-tell with a theme:
Is there a thing that you can’t do without when testing? A tool, a practice, a habit, a method that just works for you and you wouldn’t want to miss it?
Thinking about what I might present I remembered that Jerry Weinberg, in Perfect Software, says “The number one testing tool is not the computer, but the human brain — the brain in conjunction with eyes, ears, and other sense organs. No amount of computing power can compensate for brainless testing…”
And he’s got a point. I mean, I’d find it hard to argue that any other tool would be useful without a brain to guide its operation, to understand the results it generates, and to interpret them in context.
In show-and-tell terms, the brain scores highly on “tell” and not so much on “show”, at least without a trepanning drill. But, in any case, I was prepared to take it as a prerequisite for testing so I thought on, assuming I could count on my brain being there, and came up with this:
The thing I can’t do without when testing is people.
Why? Well, first and foremost, software is commissioned by people, and built by people, and functions to service the needs of people. Without those people there wouldn’t be software for me to test. As a software tester I need software and software needs people. And so, by a transitive relationship, I need people.
Which is a nice line, but a bit trite. So I thought some more.
What do people give me when I’m testing? Depending on their position with respect to the software under test they might provide
- background data such as requirements, scope, expectations, desires, motivations, cost-benefit analyses, …
- test ideas and feedback on my own test ideas
- insight, inspiration, and innovation
- reasons to test or not to test some aspects of the system
- another perspective, or perspectives
- knowledge of the mistakes they’ve made in the past, so perhaps I need not make them
- the chance to improve my coaching
- satisfy a basic human need for company and interaction
There are methodologies and practices that recognise the value of people to other people. For example, XP, swarming, mobbing, pairing, 3 Amigos, code reviews, peer reviews, brainstorming, … and then there are those approaches that provide proxies for other people such as personas, thinking hats, role playing, …
Interactions with others needn’t be direct: requirements, user stories, books, blogs, tweets, podcasts, videos, magazines, online forums, and newsletters, say, are all interactions. And they can be more or less formal, and facilitated, like Slack channels, conferences, workshops, and even meetups. They’re generally organised by people, and the content created by people for other people, and the currency they deal in is information. And it’s information which is grist to the testing mill.
And that’s an interesting point because, although I do pair test sometimes, for the majority of my hands-on testing I have tended to work alone. Despite this, the involvement of other people in that testing is significant, through the information they contribute.
- Quality is value to some person.
- X is X to some person at some time.
Fair enough, you might ask with a twinkle in your eye, but didn’t Sartre say “Hell is other people“?
Yes he did, I might reply, and I’ve worked with enough other people now to know that there’s more than a grain of truth in that. (Twinkling back atcha!) But in our world, for our needs, I think it’s better to think of it this way: software is other people.
Edit: I’ve listed some of the other things that were suggested at the meetup in Without Which.
It’s a new year which means it’s time to look back at the previous year. Although this isn’t a lessons-learned or a progress report, these reviews are like a snapshot in time, forever preserved in writing. Unlike the past years I had no specific writing goals for 2016. I knew my attention would be focused […]
So, hats down for the NTD team, you did an excellent job so far.
Tallin, here I come!
I’ve been struggling with the division of manual and automation testing, practically since I started testing – about 3 years ago. I’ve switched sides couple of times, probably sharing all the false expectations that people have even today, claiming to be on any of the both sides. After all I decided for myself that I […]
TL;DR In this post I will explain how I resolved this exception in context of selenium webdriver testing in headless mode using xvfb on linux. You finally managed to set up linux and xvfb server, your selenium webdriver settings are correct, and you successfully run your first scenario in headless mode! Astonishing achievement when I … Continue reading Selenium webdriver Net::ReadTimeout (Net::ReadTimeout) exception →
The 4th State of Testing Survey is now open: http://qablog.practitest.com/state-of-testing/Have your say in how you do testing and your company, how many people are in your test team etc. to contribute to this survey, then later reap the benefits …