"Create your testing portfolio" presentation

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).

The presentation is available below in flash format, and can be downloaded here: “Create your testing portfolio“.

But PowerPoint is Evil™, so I feel compelled to write it in real words 🙂 too.
It goes like this:


If you are searching for your first job in software testing, one of the big challenges you will face is how to have your résumé stand out. Either if this is your first job ever, or you’re changing career from a different background, the question remains: How can your résumé compete with seasoned testers’?

The solution to the 1st challenge constitutes your second one: actually acquiring this experience that differentiates the seasoned testers. And this is hard.
People looking for jobs often complain they “can't get a first job without experience, and can't get experience without getting a first job“. The logic sounds leak proof solid… where it not for the fact that, well, most people do get a first job. 🙂

So how can a newbie gain this differentiation?
Many people seek certifications, hoping that the additional line or two in the CV with the uppercase LETTERS will cover for the lack of skills and practice. Now, here’s a secret: they won’t.
Certifications do not give you skills or wisdom; they give you a determined lexicon and specific definition for terms. Some employers may want that, but they know it does not equal practice.
Software testing is an art. Young artists do not collect “painter certifications” or “canvas master certifications“… What young artists do is paint a lot, toss all the colored canvases in a big binder, and show them to galleries. Gallery owners can through this portfolio see their practice, evolution, style and commitment.

This is our suggestion to you: start testing, and be prepared to explain your tests to prospective employers.

Meet your Pseudo-Employer

Testing without having a tester job sounds farfetched, but it is actually within reach.
Of course, you can enter a bug-hunting-spree and find defects in any software from your desktop or the web. While you can learn techniques and tools this way, this method misses the most important (and fun) part of testing: The interactions.
The interactions with people involved in the software will give you focus on what is important for them to know. It will also redirect your tests as you go with feedback and comments, making sure you are always providing useful data. Last, being in touch with this human side of the software will give you the opportunity to explain, discuss and participate in fix/no-fix decisions – transforming your findings from simple bugs to valuable information on quality and risks.

And there are many ways to be involved with testing in the development of software.
Here are a few options:

–> Academy Projects

There is a lot of interesting software being done as final projects for Computer Science graduations. These students do all the work themselves, and they will be certainly glad to have help in testing the software.
One of the great things here is that the interaction is all 1 to 1 and face to face, allowing it to be a closer and more dynamic relationship. Feedback and bug-fixing times are quick; you can suggest a change and then see it done the day after.
Posting your ‘testing offer’ as a note in the wallboard, or asking from one of the project mentors to point you a needy student, are all good ways to get started.
And, for what it’s worth, you may appear in the credits on the project report! 🙂

–> Open Source

Sourceforge has hundreds of thousands of open source software projects under development. You can pick one that suits your interests and limitations by using their filtered search, and you can also take a look at their “Help Wanted” section, which many times ask for help in testing.
The open source community is thirsty for contributors, and they respect sound advice. If you show your competence and are provide consistent views/comments, the community will pay attention – and they don’t care about your degree, background or years of experience.
And, for what it’s worth, you may be given credits (or ‘tip of hats) on the release notes! 🙂

–> Crowdsourcing

There are websites where you can receive money for reporting bugs. The two examples I know of: uTest and Flash Mob Testing.
Testing in this environment may pose problems (see this post for a list of concerns) and the interaction you have here is by far less involved and meaningful than the previous two options.
We listed this in the slides because the couple dollars are tempting and people may prefer this option over the others.

Note that here, you won’t get public credit for your work, in case you wanted to showcase it in an interview.

–> Volunteer for a company

This one wasn’t at the slides’ first version, because I had forgotten about this history completely.
When I was at the university, I had a friend working for a software company, a small one without a testing team. To exercise my ‘criticism’ (I didn’t know I was ‘testing’, back then) I started to write him comments on their webpage and their application, notes that they triaged in their bug meetings and fixed in the next release (sometimes).
So it was volunteer testing for a real company.
(This entire story slipped my mind until 3 weeks ago I had a course in the same building as this company is located. It all came back to memory suddenly: that was my first testing gig!! 🙂 ).

In summary

There are many ways to test without a testing job. Find or invent the option that better fits you, and start differentiating yourself as a real tester.
Try it! 🙂
With a little work from your side, you can demonstrate to employers your capabilities, style and passion. And having volunteered to test and provide data isn’t something a recruiting manager sees every day, so it is likely to attract his attention.

The next steps

After you’ve decided where to start testing, following a consistent way of work will make your testing much more efficient.
The slides include many suggestion on how to get a good start: Follow the forums discussing the software (and ask questions!), be sure to read the bug submitting guidelines so your information is treated with care, and find a lot of bugs 🙂

An Alternative

When applying for a job, capitalize on the experience you’ve already got.
Software projects need domain expertise just as they need testing expertise. If you were a stock-broker, a software house developing stock-market software can have great benefit from your testing. If you speak languages, a lot of specific software can benefit from this trait.
See my comment in this post: The entire experience you bring to a team is valuable; recruiters aren’t always only looking for super-testing-wizes.

Good luck! 🙂

In August, a rewrite of July's uTest post (and maybe official feedback)


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 :). Read the rest of this entry »

Tags: , , , , , , ,

About youTesting with uTest

(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. Read the rest of this entry »

Tags: , , , , ,

BOtT: Smile, your data is gone!

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: Read the rest of this entry »

Exploratory Shopping – An analogy attempt

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: Read the rest of this entry »

Read the bugs

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). Read the rest of this entry »

Job Description

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: Read the rest of this entry »