This was an interesting exercise.
What took my interest in this one? - First of all, I liked Pradeep’s post about learning to code.
Learning to code is an important skill for a tester. I can relate to it because I am trying to learn PowerShell. I program in some languages (C#, C++, PHP, VbScript…) and have a programming background (after my Computer Systems Engineer degree, the ‘natural’ path was to code, and I worked as a programmer for many years before finding Software Testing), but PowerShell has different approach and paradigms and learning it will definitely be fun. - Second, I had an impromptu vacation day, and I thought it would be educational to use it for a peer testing puzzle. I thought I could win this one quickly (I was mistaken, it took me long).
So I downloaded Pradeep’s application, and got to work!
Rather than just trying to solve the puzzle, I looked at it as if the mission was:
“This is commercial 'roulette' style game. Stakeholders want to know it the game logic can be broken/learnt, which could mean a substantial loss of money when people start winning every time.”
Testing Hint: Cem Kaner says “Testing is an empirical, technical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek“. So it is important to set straight what is the information to seek. Which kind of bugs to look for?
In this blog I describe my attemp to answer this question in an exploratory way. (more…)
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. (more…)
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:
(Disclosure: I am not a lawyer!) (Request: Are you a lawyer? Please send me corrections )
Matters related to law, and all the discussions around it, interest me much — especially when related to Software.
This made me read about the subject and keep contact with the legal representatives within the company I work for. This also motivated me to learn and lecture about the legal guidelines in software development adopted by our company, and to lecture about legal matters on software in general at the last Israeli SIGiST conference.
Most important than all, this made people share with me a lot of comments, questions and stories pertaining to the law.
For example, one colleague brought to my attention a case in which he and some friends had bought a PlayStation 3 in the local Office Depot website for 220NIS – when the normal price is almost tenfold! They believed it was some special sale promotion, but at the end Office Depot announced it as a typing mistake and cancelled the sale after it had been acknowledged (sale confirmation by email).
(There is an article about the episode in Hebrew here if you want to see it).
What is my opinion on the legal aspects of the story? I was asked.
I don’t have one, as I am not a legal professional, I answered. I am, though, a Testing professional, and here is the tester rambling I sent by mail commenting the occurrence:
Some colleagues and I do voluntary work at TechCareer, helping immigrants learn matters related to technology and score a career in the Israeli Hi-Tech industry either as programmers or testers. It is a very good project, with nice leaders.
My colleague Issi Hazan was asked to teach the ITCQB syllabus to testing-oriented-students at TechCareer, but he bravely thought of pushing them to real tests instead, even before they find a job – this would allow them to build experience and get a job more easily (one way to solve the “hard to get a job without experience, hard to get experience without a job” problem).
So we built a lecture on how to “create a tester portfolio“. We explain how testing can be done even outside an enterprise environment: Lots of Open Source projects are seeking for good information from software testers, and a good record there is certainly sure to help. Crowdsourcing is also a possible way to work on testing before getting a real job (see two posts on crowdsourced tests here and here).
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 . (more…)
(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. (more…)
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: (more…)
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). (more…)
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: (more…)
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’ve recently heard The Graphing Calculator Story, a ~54:00 min long Google Tech video on YouTube. On it, Ron Avitzur tells the story of the development of his (and Greg’s) Graphing Calculator, an impressive mathematical software that shipped with Mac computers for years.
What’s special about the story? Well, he did it at Apple, but for free (his contract was already closed), and in secret (Apple had cancelled the project). As he says, sneaking into the building and volunteering for an eight billion dollar corporation.
I enjoyed the story very much. It is very exciting to see the passion he had (has) for his software and how he was committed to it. Plus, Ron is a great story teller.
The graphing calculator had all the ingredients of a cool app. It scratched a developer’s personal itch, and is a great example of NeoVictorian computing: built for people, built by people, crafted in workshop, inspired.
Actually, if we’re commenting on NeoVictorianism, Ron was one that really “woke up one day to find himself living in the software factory“. The night got very cold, they said the factory is going to close and he should move somewhere else. The cool part? He kept doing his individual craftsmanship inside the corporation. Secretly.
This is the third Happy New testing Year, after this one and this one.
This is quite exciting, three new years means two full years!
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 .
Writing the Fitnesse posts turned to be harder than I thought.
I do have a bit of tests ready for the triangle case, but not enough text to make an interesting post. As I’m not using Fitnesse in my day-to-day work, it makes it harder to bring cool insights or to explore on the framework.
But I just discovered someone who not only uses Fitnesse at work, but also writes articles about Fitnesse that give the Fitnese feeling:
The last BotT (Bug of this time) was long ago, when we talked about testing and the Excel bug.
So now we’ve got a cool one, on which the most notable point is not the bug, is the submitter .
Bug 439858 on Fedora (a Linux distribution) was (supposedly) submitted by Linus Torvalds himself. He started the Linux wave on August 91, and is still posting bugs on March 08 – you gotta admire him.
I am aware that the submitter signing “Linus Torvalds” may not be Linus. It actually doesn’t matter, let’s just pretend it is for sensationalism’s sake (regarding the admiration, you still gotta admire him even if the bug’s not his ).
Let’s try to analyze the bug report, and the bug itself, to see what we can learn:
In this year I held a session on the “SIGiST Israel” conference.
It was a one hour lecture introducing advanced techniques, with examples of software testing through Fault Injection (with HEAT tools) and through Fuzz (variety of free tools). This month I received the average grade from the feedback sheets: 97/100!
Of course, I’m happy with the results. :) Thanks to all who attended and asked questions.
It is possible that I’ll post here a transcript or some text about this lecture. One option may be to add my comments from the lecture as notes in the powerpoint slides and post the slides here. But I don’t like powerpoint much as it does a poor job of passing information (it takes the written word and limits it into bad format and structure).
Finding the time, I’ll write the lecture in extense text.
In order to keep this post still useful, here goes a short summary of the talk:
Annotations from day 24/06/2008 of the Sigist conference on Software Testing.
When not from a lecture focus, then from a side comment or explanation. Below you’ll find some insights I gained from today’s lecture. When not from a lecture focus, the ideas come from a side comment or explanation:
We all are told constantly not to think like a programmers.
We’ve told other people dozens of times “Don’t you think like a programmer. We don’t care why the software does it – it is still wrong”.
For testers, thinking like developers is evil. If you think like a programmer, you’ll start excusing the software and will forgive the system’s bugs.
I am reading the very cool book “Dreaming in Code” by Scott Rosenberg, and I just understood a little bit more on why’s so bad sharing the developers mindset.
I’ve started a quote collection. Many times I want to quote someone but I just don’t remember how exactly the phrase was. Or remember the quote but am not certain on the source…
I am fond of quoting.
Not sure why, but I like to quote. I guess it gives some legitimating to what I am saying.
@shrinik I agree with that "Why" one. Asking for a Business Case for providing a Business Case may be appropriate.. Just don't loop forever. (link)
@shrinik For *dead* humans, breathing is a total waste of resources. (link)
@shrinik People may take decisions that are not beneficial for the business. Buy a new server because its case is prettier? (link)
@shrinik Thinking with you here... maybe not asking for a Business Case can be even more dangerous? (link)
@shrinik It is definitively appropriate to ask for Business Case for 'walking'. That's what birds did, apparently. (link)
Disclaimer
I do not speak on behalf of my employer, nor am I authorized to represent it publicly. All and any opinion expressed in this blog is solely mine, and do not represent my employer point-of-view. Nor my manager or department point-of-view. Nor my colleagues point-of-view. Nor anybody else's.
This is our fourth Happy New testing Year post, after 
.
Hi.
In this year I held a session on the 
It is possible that I’ll post here a transcript or some text about this lecture. One option may be to add my comments from the lecture as notes in the powerpoint slides and post the slides here. But I don’t like powerpoint much as it does a poor job of passing information (it takes the written word and limits it into bad format and structure).
When not from a lecture focus, then from a side comment or explanation. Below you’ll find some insights I gained from today’s lecture. When not from a lecture focus, the ideas come from a side comment or explanation:
