While user bug reports are the most important ones, there is a category of external reporters which I historically have a special interest in and great expectations for: entry-level testers. I was one, trained some, interviewed many, had a few hired, and have always wanted someone to wake them up and get going before it’s too late.
There is no secret that quality control is not as glamourous as other IT specialities, and there are no famous (or maybe any) student programs for testers. Usually people come into testing because it is deceptively open for newbies, planning to obtain a few points for a CV and switch either to development or to project management as soon as they can. Most do, a few stay.
It creates a vicious cycle. Since this is a well-known pattern, employers hire testers without experience not to teach them, but to let them do brainless mundane work. In turn, newcomers gain a distorted impression of the speciality, get discouraged and move on long before the job has a chance to grow on them.
But it doesn’t have to be like that. Nowadays a new-born tester can get good karma before starting the first job, and enter the market as an equal. The job is very different when you are hired as a specialist and not as a cog, the work won’t be nearly as frustrating, and you’ll be able to make a well thought-out decision about the future.
First CV: skills and portfolio
Since you don’t have any work experience to put on the CV, you usually have to go with education and skills. You can add another important part though — a bug report portfolio.
Particular technical skills are mainly important for the initial screening, when some HR simply match your CV against a wishlist that they have. You still need to gain some to pass, since you mustn’t lie in your resume, ever. But once you get through to the technical interviewers, if they know the first thing about testing, they will look at two main points:
whether you know what it means to be a tester;
whether you show any potential for being a good one.
Testing is not easy, and your interviewer is painfully aware of that, so it’s important to show that you have already tried, somewhat succeeded, and made a conscious decision to keep doing it.
That’s something you can prove by providing the bug report portfolio.
It reveals a lot about you, much more than just your hunt-fu. While a CV is only something you can say about yourself, your public portfolio shows what the world can say about you as a tester, since your bug reports are evaluated by independent parties. Only a really dumb interviewer could ignore it.
So, it is worthwile to make sure you create a good one.
How to choose the project(s)?
The common idea is simple: you choose a project with a public bug tracker and start testing it.
If you want to deal with the source code, obviously the project has to be open-source.
If there is a particular field you want to get familiar with, choose a project where you can focus on it. There is no need to worry about testing technologies: you can use whichever you like, or want to learn, and apply to the product of your choice.
Also, the product should be fairly known, so that the interviewer can easily understand the context of reports.
Main traits of a bug report portfolio
An interviewer will try to quickly evaluate your portfolio. Thus, it’s important that all bugs can be viewed, searched and filtered by a non-logged user, and that you can create a permanent link to a list of your reports only, preferably with some sorting.
The list should display a summary of the report, its severity/priority from the project’s point of view, status/resolution.
It should either contain all your reports, or come with an explanation which filters were applied, and how to remove them. Don’t hide “bad” reports behind obscure filters. Instead, make sure that most of your reports are really good.
Severity/priority shows your hunting skill. It is fine to report minor issues and cosmetic problems if you notice them, but if most of your reports are like that, it just won’t impress the interviewer. One killed bear is worth a dozen of quail… Although, be smart about it. People like juicy crashes, but sometimes non-crashing functional bugs are much more important, and hopefully your future interviewers know that.
Status/resolution shows a lot more.
The more fixed bugs you have on your list, the better — it means the reports were valid, and were taken seriously. Confirmed but not fixed bugs are not bad either.
Many “Can’t reproduce” bugs is a very bad sign — it means you either cannot provide reproducible test cases, or cannot communicate them to the project people. Both are crucial for a good tester.
Many “Duplicate” bugs is also bad — it means you don’t bother or cannot search the bug base before filing a bug. Nobody likes those who don’t use the search.
Many “Not a bug” entries is suspicious — it looks like you don’t check documentation with due diligence.
Many bugs which were just submitted but didn’t get any feedback don’t say anything about you as a tester, only show that you probably chose a wrong project to work with.
Watch for common flaws in bug tracking routine
Disclaimer: Any resemblance to bug trackers living or dead should be plainly apparent to those who know them, especially because the author has been grumbling about them for really long time…
The criteria above are reasonable in theory. Unfortunately, it happens that you get your portfolio spoiled without any fault from your side.
To display the real ratio of your report severity, the bug base should provide access to all reports. If the critical bugs remain hidden, then the visible list will only contain mediocre bugs, and the better your real list was, the less impressive your portfolio will look.
It often happens that a report is initially confirmed, stays in the queue for a (long) while, and eventually gets closed because the bug is no longer reproducible in the current version.
Not only is it unfair towards the reporter, but is also dangerous for the project. The project’s problem is another story, but for you it means that you’ll have an unfair share of bad “Can’t reproduce” reports on the list.
Wrong “Duplicate” status comes in different flavours.
First, it can be a consequence of hidden bugs. If something is not searchable, you cannot find it, so you reasonably file a new one, and it gets closed as a duplicate.
Secondly, the problem can be similar to “Can’t reproduce” ones. You file a bug in June, it is confirmed and stays in the queue, then 3 months later somebody else reports the same issue, it gets fixed, and the older bug is marked a duplicate. There is no harm for the product, so developers find this unimportant (but try to call them plagiarists after somebody copied their code, and see if you live through the day…).
Another, more subtle issue with “Duplicates” is that it can be set after a deep analysis by a developer, because, although bugs look nothing alike, they (allegedly) have the same root cause. Again, doing so is wrong for the reporter and dangerous for the product.
Also, numerous “Not a bug” problem can be caused by a lack of documentation. If you can’t find out how something is supposed to work, you are likely to waste time on reporting something that will be dismissed. So, make sure that the product is documented.
Most of these problems do not really concern users or senior testers, just maybe irritate them. For you, they are critical. While you’ll have very good excuses, keep in mind that you won’t be around when the interviewer initially evaluates your list. So, try to avoid it in advance — browse the tracker of your choice, check the history of some reports, see how things are done there. Exceptions can and do happen, but they should remain rare.
Why MariaDB?
Of course, my goal is to convince new testers not only to start testing, but to choose MariaDB over other projects to perfect their skills on. While I’m somewhat biased, I still think that MariaDB is objectively a good choice:
It is a crazy open-source mix of various technologies — numerous engines, plugins, connectors, replication, Galera, optimizer… Whatever you want to focus on, unless it is seriously exotic, you will most likely find something related at MariaDB;
MariaDB Knowledge Base contains a lot of information about the products; also, for the most part the MySQL manual applies;
All our bug reports are public, so the visibility problems do not exist;
JIRA which we use for bug reporting is hardly the best system in the world, but it does provide enough searching/filtering to fulfill all the needs associated with building a portfolio;
We release early, and unstable early releases are golden mine for eager testers;
And last but not least — it takes one to know one; you can expect that your interests will be taken seriously. We cut some corners when it comes to internal reports, but I’ve been trying to make sure that our external reporters are treated fairly, and I think our developers started picking up the idea. So, if something was done wrong with your report, you can let us know without a fear of being laughed at, and we’ll try to make it right if the request is reasonable.
Perks
If you indicate that you are a tester, I can provide you with some hints on how to improve your report, or some other community members might (we don’t bother users with improving reports as long as there is enough for us to go on). If there is a demand, most interesting cases can be later analyzed in blog posts; finally, if you are a regular reporter, and a really good one, we can also provide you with a reference for your first CV.
How to start
download
get started
choose a component or functionality
test
report
It is really this simple.
PlanetMySQL Voting:
Vote UP /
Vote DOWN