Instead of a new post, I revisited and modified last month’s post, About youTesting with uTest.
It has now more content, and still has a discussion of pay-per-bug models.
The initial opinions are still there. While the pay-per-bug model presented by uTest is certainly innovative and interesting; the model still misses a lot. It will certainly be center of discussion many times in many circuits :). Continue reading In August, a rewrite of July's uTest post (and maybe official feedback)
(Note: This post,originally from July, was re-written in August. Only format/wording changes, with additions to make it clearer)
This is an interesting topic:
I’ve been involved lately in many conversations about uTest, or more specifically about its model.
uTest is a website where companies can post their software, along with some guidelines on focus areas, and users around the world can download the app, find bugs and get paid for bugs reported (as long as the bugs are accepted by the posting company).
There is a lot of confusion/discussion around the good parts and the bad parts of the model, so I will share here some of the points I had taken from these conversations (thanks to all the friends who shared insights with me)… Some attentive readers will notice the article is an almost copy paste from a reply in the software-testing group.
Please note that I am not saying “
uTest considered harmful” or “
don’t use uTest” or anything like that.
Please note that I am not saying “
uTest is great” or “
use uTest” or anything like that.
All I want to point here are some of the strengths and some of the weaknesses of the model, so every one (both testers and companies) can decide for his own context. I welcome debate over any of these points, and will update my post accordingly. Continue reading About youTesting with uTest
As most words, “quality” has a lot of different meanings to different people.
I guess “Customer Satisfaction” has a lot of different meanings too.
A couple of months ago I tried to access a site (now I don’t even remember which it was) and was greeted by the note below: Continue reading BOtT: Smile, your data is gone!
These days I went to a book fair of a well known publishing house, and found there my very own analogy for Exploratory Testing.
I tell the story and analogy below for your pondering and criticism.
You know how these fairs are, I believe book fairs are similar everywhere: a loft filled with tables filled with books at good prices. You walk around the tables, take the books you like and proceed to checkup.
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: Continue reading Exploratory Shopping – An analogy attempt
Eric Sink is very well known in the software development community. I would say he’s a legend, but he says he’s not one.
He writes books, software, and gives interviews about the craft and business of software. Not only that, but (not surprisingly) he’s also got a blog.
Two months ago he wrote that reading your colleagues code check-ins is a good practice, and I think this is good advice. And good advice for software testers too: I read the bugs submitted by my team on a regular base, and it’s been very enlightening (often to me, at times to them too).
I don’t like copy-paste, but as an experience on the parallels between development/testing, I’ll copy his entire post, just changing the parts that are development-related to testing-related words.
“Great artists steal“, right? Let’s see if it is intelligible (my changes are in blue). Continue reading Read the bugs
I was reading a job position offering these days for a “QA engineer“.
There was the usual mumbo jumbo of the required traits (“BSC in computer science or equivalent“, “Worked directly with R&D department“) and advantage points (“General knowledge of at least one mainstream (programming) language“), and one of the requirements lines said “Testing methodologies: STD, STP“.
I got curious to know what these methodologies are and what the TLA mean, so I called the company offering the job: Continue reading Job Description
I like the SQE.
SQE brings columns by Michael Bolton almost monthly on the Better Magazine. They also arrange the nice STAR conferences (hadn’t the opportunity to participate yet, but I will eventually) and store a large number of articles online of all testing flavors.
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:
Continue reading On certified testers and being certifiable, and on non native english speakers