Software Testing Training of a different kind

Ever dreamed of being personally trained by Cem Kaner? How about Doug Hoffman? No? Ok, maybe Scott Barber is more your style?

Any tester would, but it would be expensive? I mean these guys would typically charge thousands for this kind of training. Besides, they’re all in the states, so airfare, accommodation.  Your company would never pay for it, right? Especially not now the training budget is cut.

Well, I’m being personally trained by these great testers, right now and even better, I’m doing it for FREE. No that’s not an acronym for  Footnote Really Exorbitantly Expensive,(I know its not very good, come up with a better one and let me know !)  it really is FREE.

I’m on the bug advocacy course run by the association of software testing. (note, the website is currently going an upgrade, but you can still become a member etc).

It’s an online course that’s free to all members. Yes you do have to be a member. Yes it does cost money. $85 US dollars for a year. So, if you want to split hairs, you could argue the course costs $85. So what?

Anyhow, I wanted to talk about this course, because its content is really excellent. First of all, lets deal with the title.

Why BUG ADVOCACY?

Because our focus as tester’s is not about raising bugs, but ensuring they get fixed. Its true!  Think about it. That way, not only does the software improve, but we as testers gain credibility too.

So, in order for us to get our bugs fixed, we need to make sure we sell them well and we anticipate and preempt any objections people may have about our bug report.

Its about communication effectively and communicating to the right person. Its about creating the ultimate bug report.

There is a lot more than that in the course. I suggest you take the course and find out for yourself.

The recommended hours per week is 6.  I would suggest you allocate more time.   The course content is practical and you are given assessments that involve commenting on actual bug reports. Some of the assessments can take longer if you allow them too. You work with testers around the world, some I knew of because of their blogs.  Personally, I’ve learned as much from other testers feedback as I have from the trainers.

Make no bones about it though, its a demanding and challenging course and if you are just looking for a piece of paper for your resume, this perhaps is not the course for you. On the other hand, if you’re looking to improve your software testing skills and having a highly respected certificate matters to you, then I suggest you join the AST and take some of their courses.

It doesn’t matter what environment you work in, agile or waterfall, process or exploratory, the skills you learn on this course are relative to all testers out there.

So, if your company doesn’t have a large training budget (or even if it does) this is the perfect solution. Your testers get some really great training, and you get kudos to boot.

Note:  This is my own personal opinion, I get nothing out of posting this on my blog.

Bug Tracking Tools Explained

Like it or not, all software has bugs.You may not know about them but they are there..lurking in the darkness, ready trip up one of your innocent user who has just gone and purchased your software.

That’s why you employ a software tester. A software tester’s job is to find as many of the bugs and report them to you and the rest of the team before they can do untold damage to you and  your software’s reputation.

You can report bugs in as many ways as there are to communicate. You can write the bugs up in an email, on a piece of paper, in a spreadsheet (see my previous post on spreadsheets). You can even directly speak to the relevant person and directly show them the bug.

Or you can use a bug tracking tool.

So why do you need to track a software bug and whats so great about a bug tracking tool?

Software Bug Workflow

Well, just as a normal bug goes through several stages in its life such as egg, nymph, larvae and finally adult, so to does a software bug go through its own lifecycle or workflow. Redmine the opensource software I use as my online bug tracking tool,  uses the word workflow so I’ll use that term in this post.

Typically a simple bug workflow goes as follows:

Bug WorkFlow

Bug WorkFlow

Where:

new is when a tester creates a bug report

open is when a developer  accepts the bug report as valid

fixed is when a developer indicates that the bug is fixed

tested is when a tester indicates the bug has been tested

closed is when a tester accepts the bug has been fixed and the report is now closed

This is a very simple workflow. Alternatives to the workflow can happen when for example,  bugs are rejected by the developer  or a bug fails test and the tester places the bug back to open state. In fact, it can get quite complicated if you let it.

Most bug tracking tools will let you modify or create your own stages and workflows, but if your new to the concept of a bug tracking tool, its better to select a simple existing workflow and use that for a while to get used to what works for you. Redmine, lets you chose a preexisting work-flow.

A bug tracking tool then allows a tester to create a bug report and monitor its progress as it goes through its workflow

So whats the big fuss? Why not just use a spreadsheet or email?

I’ve personally benefited a lot from bug tracking tools. Here are some ways they’ve helped me.

Benefits of a bug tracking tool

1) Its easy to keep track of one bug, but keeping track of many bugs is hard work. A tool helps you easily find out what bugs are still open, fixed, closed. Bug tracking tools normally allow you to sort and filter your bugs and create reports on the bugs.

2) You can track other stuff about bugs, such as how important they are and who is fixing them. This can help you prioritise which bugs are important and require urgent fixing.

3) You can start seeing clusters of bugs which indicates there may be underlying issues in parts of the code

4) Lots of people can see the status of the bugs, not just the tester and the developer. The overall bug status can be quickly reviewed by many avoiding nasty surprise syndrome (NSS) at the end of development/testing.

5) Sometimes not all bugs are fixed in the current release but will be fixed and tested in a future release. This means long after software release the bugs still need to kept open and tracked. A bug tracking tool ensures that these bugs are not overlooked in the future.

6) A bug tracking tool can centralise information. Often a bug tracking tool can be used to track new features as well as issues and can act as a document repository. Redmine offers many additional features such as document repository and wiki.

7) A bug tracking tool can improve productivity by increasing bug awareness and responsiveness. It is also handy when a project is scattered geographically and works across different time zones.

As I’ve mentioned in previous posts, there are many open source options bug tracking tools out there, so if budget is an issue there is no need to spend a lot of money on an top end commercial tool.

And of course, a tool is only as good as the developer and tester using it and will fail miserably if no one is willing to use it, so perhaps if your thinking of adding such a tool to your testing toolbox, speak to the rest of your team first to find out what they are looking for in a tool.

Damn it all, its just not cricket..or is it?

After fifteen years of living in Australia, some things have rubbed off on me. One of the them is cricket.  I have to confess I have spent many a sun drenched day watching the cricket whilst imbibing the odd beverage here and there.

Cricket Image

One thing that I have noticed in the game, is the impact of the new ‘unknown’ player. It suprises me the impact the unknown can have on the game. Michael Clark (or Clarkey to his mates) on his debut in Bangalore went out and scored 151 runs (thats a lot btw).

Here comes the testing bit…

Fergal O’Riordan,  pointed out a similar result in his software testing teams.

When testing is all but hung up and dry, he enlists a new tester.  This tester must be new to the team, and never worked on the application before.  He finds that doing this dramatically increases the number of bugs found in that day.

He breaks the bugs down as follows:

  • The majority are known issues, but previously where not considered to be bugs. The new tester didn’t know that and raised them. Changed circumstances and attitudes now regard these bugs as valid.
  • Most of the other bugs were also known issues, but were either seen as not relevant to the stakeholders or were being dealt with in future releases
  • a small number were new and relevant bugs that required fixing.

So why is it that a new tester is able to have such an impact? He puts it down to the following reasons:

1) These bugs have been seen before but previous experience led testers to believe they were of no relevance to the stakeholders

2) A new set of eyes brings a fresh perspective and outlook to the testing

Doing something different, unpredictable can bring benefits to your team, no matter what the ‘sport’ is.

So there you go, who would have thought that the world of testing and cricket had something in common?

Tea break!

In search of the ultimate bug tracking tool

As many of you know, I’ve been on the hunt for a bug tracking tool for a while now and I’m glad to say the hunt is over.

I needed this bug tracking tool to meet some key criteria.

1) It had to be easy to install. Startups don’t always have a reputation of up front planning and I wanted a tool I could recomend that was quick and easy to install.

2) It had to be open source. I didn’t want to pay for a bug tracking tool unless I had too. My clients feel the same way.

3) I wanted to embed the bug tracking tool into my website Testing Times and then provide it as a service for my clients who don’t have or want a bug tracking tool.

4) It had to be easy to use and secure. I wanted each client to have access to only their project.

TRAC got the heads up for being opensource, but was too hard to install in comparison to YouTrack, which beat it hands down. YouTrack only provided a temporary license though and I had trouble getting my hosting company to support Apache Tomcat. The effort to install something I may have to pay for later, made me feel it was pointless to pursue.

Tails was interesting and looked great, and if I had to pay for a tool, their pricing structure suited my needs. There is no messy install as it’s a hosted service but that meant that I wouldn’t be able to embed it onto my site.

Practitest had similar issues for me, and also the pay per month/user pricing structure didn’t suit my needs.

I was at a bit of a loss until BHARATH suggested Redmine.

Redmine is an opensource tracking tool that’s easy to install, easy to configure and secure.  It ticked all the boxes and it’s now sitting on my website. You can take a look at it at  http://bugs.testingtimes.ie if you like.

I have created a public project called Testing Times for those who want to investigate a bit further.

The real test of course will be my clients, their reaction and how much they use it.

So a hearty thanks to Bharath and a sigh of contentment from me.

Straight up, no ice….

You know the way sometimes, a post, or even a comment on a post gets you thinking. A recent comment by Phil Kirkham on Georgia Motoc’s blog got my subconscious brain working overtime. So much to the point where I feel compelled to put finger to keyboard and write about it.

I had always been a fan of positive praise before negative feedback. As the bearer of bad news (like many software testers), I though this was an effective way of cushioning the impact of what I wrote or said.

So, when Georgia Motoc wrote  a post on feedback discussing the ‘Praise Sandwich’ I was surprised how negative Phil was on the approach. However his comment and  his link (indirectly to a post by Art Petty ) really got me thinking of how I communicate with developers. It made me realise that the positive feedback I was providing was more for my benefit than for the software developer.

Here is some Art’s original post:

5 Reasons Why the Sandwich Technique is a Truly Bad Practice:

  • It is a crutch that is solely for the benefit of the giver, not the receiver.
  • It obfuscates the real message.
  • It confuses the receiver by watering down the key message.
  • It destroys the value of positive feedback by linking it with the negative. Don’t forget that positive feedback is a powerful tool for reinforcing the right behaviors and the sandwich technique devalues this tool.
  • It is insulting to the receiver and borderline deceitful. “Bob, you did a great job on XYZ, but .” It’s like a pat on the back followed by a sucker punch followed by another pat on the back.

I have a real reason why I have changed my attitude to this:

When I’m on a short term assignment (which is often)  I don’t have time or the need to cultivate deep relationships with software developers. What is important is that the bugs I find are communicated in a clear and concise manner. That’s what I am paid for.

The praise sandwich is not necessary and more importantly it does not provide best value to my client.  This is something I learnt on James Bach’s course and has stuck with me. What ever you do ask yourself, “Is what I’m doing right now adding value for my customer”.

Hackers, Blogs and PC’s…. Oh My!!!

What a week!

My ‘problem’ antennas have been twitching this week. It started off with my blog and user access. ‘Hedosnorrenny’ had decided to become a contributor to my blog. Without me asking.  There he (or she?) was, proudly displayed in my WordPress ‘users’.

So, methinks, time to perform some extra security. With all this Gumblar about, you can’t be too careful..  I download some malware software and start scanning. Problem number 2 pops up. Every time my scan runs, it freezes on one particular dll. Uh Oh, virus?

No No my friends…it’s bigger than that…

It’s hardware failure!!! Hooray, at least I know it’s not my antivirus sofware! My Dell laptop M1530 which is only just over  one year old (and so out of warranty) decided to pack in its hard disk. I can understand this. After all, with a 320 GB capacity, that’s a lot of hard yakka.  So, I grin and bear it in true Testing Time’s fashion and replace the  hardware. Fortunately, I’m good citizen material and have recently backed up my data. So, new hard drive and away I go….until….

Problem number 3…

Of course, when wordpress announce a new upgrade for security reasons, I immediately think, fab, this might fix my user registration issue, so upgrade I go.  Then I discover that all my blog links don’t work, neither do my catalogues.

Is there no end to this mess?

Fortunately, because of my good citizen material(see above), I have a backup and roll back an old version and presto…back in business.

I look back on my week of failure and reflect, what could I have done better? I don’t think I could have prevented the hardware failure, and the hacker?  I think I am pretty secure about my access, but I’m willing to admit I still have a lot too learn. 

WordPress upgrade failure?  Completely my fault.

I’m a software tester! What did I think I was  doing, upgrading before testing? I really ought to have known better.

So, yes I’ve learnt a lot this week. Keep your access 100% secure and test before you upgrade. I’ve now got a test site for my wordpress, and any upgrades will be well tested before it has to perform in public.

Basic stuff right? I can’t believe I keep falling into these traps….

Any advice to wordpress users, backup often and have a test site that replicates your real site.

Hmm, I think I’ve heard that advice before somewhere….

Do your bugs only glow when its dark?

Have you ever been in the situation where no-one else can find and repeat the bugs you find? Perhaps you have a canny knack of finding unusual bugs, or maybe it’s time to improve and update how you write bug reports!

I do a lot of offsite exploratory testing in very aggressive timelines and consequently I have to admit, I sometimes start making basic mistakes.

My common mistakes are:

1) I don’t write the bug report up straight away

2) My bug reports are not detailed enough

3) I underestimate the time it takes to write up defects

4) I don’t use a defect tool

You can imagine, when you’re working offsite without even meeting the developer, this can lead to all types of complications. So I need to put myself in that poor developers shoes and make my bug reports as clear, concise and as detailed as possible.

I think it’s tempting when there is little formalised structure in testing to overlook writing a disciplined bug report, but it’s worthwhile to you and the customer. I mean what’s the use of paying someone to find bugs when no-one else can find and fix them?

Anyhow to prevent myself repeating such unforgivable mistakes, I have developed a set of guidelines to follow.

Offsite Exploratory Testing Guidelines to Bug Reporting

1) In the estimate to the customer, make sufficient time to write your bug reports as you go. It’s impossible to know how many bugs you are going to find but you can do a bit of math. If you’re planning three    days of testing, and you find 100 bugs @ 10 mins average, then that’s two days of your testing filled up with just writing up reports.

2) Agree on a detailed bug report with your customer. Try if you can to get agreement with the developer. Try and include as much background information as you can. There has been a load written on what constitutes a good bug report, so I won’t repeat it here.

3) Don’t delay; write up the bug report straight away. This is hard when you’re in the middle of some exciting analysis and you really just want to keep testing in the timeframe you agreed on. But trust me; it takes longer to write them up at the end, when you have to review heaps of cryptic phrases in Session Tester or in your notebook. A capture tool may be helpful in recording data, but if you leave reviewing to the end, it will add additional time and effort to the testing

4) Encourage customers to use a defect tracking tool. It saves everyone a lot of headache and heartache. There’s lots of open source defect tracking tools out there. TRAC and Bugzilla are the two most common.