Get out your tin whistles

At last after a year of wrangling, shuffling and even some pleading Michael Bolton in association with Testing Times is coming Dublin to give his wonderful Rapid Software Testing Course.

Not that Michael needed persuading to come. He jumped at the opportunity. Mostly because he loves giving this course and helping testers well, develop sense. But I will let you into a little not so well known fact about Michael. He loves Irish Music and his a keen Mandolin player.

So we knew we were onto a winner straight away!

For those not familiar with Michael Bolton and his course.

Rapid Software Testing is “a course, a mind-set, and a skill set about how to do excellent software testing in a way that is very fast, inexpensive, credible, and accountable.” Its written by James Bach and Michael Bolton

This course is excellent, its practical and thought provoking!  I can personally say that because I’ve taken it. If you have ever asked yourself the question:

“Is there a better way to test this stuff ?”

Then I suspect this course is for you.

Some of the issues it addresses are:

  • Are you finding it difficult to assess how much time and effort you’re going to need to test effectively?
  • Are you overwhelmed by or uncertain about approaches to test planning, design and execution?
  • Are you working in an environment where some people aren’t following “the rules”?
  • Are you having trouble finding the right balance between planning, documentation, and testing?
  • Are you interested in learning skills and techniques that will help you to become a better tester?
  • Are you finding that “industry best practices” are infeasible and a poor fit for your organization?
  • Do you want to get very good at software testing?

Read more information about Michael Bolton and the course go to his website: Michael Bolton Rapid Software Testing

Even better Skillnet has agreed to partially fund the course, so you are getting this 3 day course at a knock down price of 770 euros.

If you have any money in your training budget, this course is the one to go for!

Rapid Software Testing Details

  • Date: Monday 13th to Wednesday 15th September 2010
  • Venue: Xilinx, Citywest Business Park
  • In association with Testing Times & Xilinx
  • Duration: 3 day course (9.00am to 5.30pm)
  • Cost to non-members: €1,700 per person
  • Cost to Software Skillnet Members* after Grant aid: €770 per person

*Membership to Skillnet is Free

For more details and booking go to the skillnet website:  Skillnet Rapid Software Testing

Kids, Kittens and Karma

Have I ever written about how competitive I am?  Lets just say I like to win. A lot.  Best explained by an example I think.

In my heyday I was a bit of a runner. Not a bad one, but not the best and I knew it. My favourite race was the 800 meters,  a bit shorter than the 1Km, more like a fast sprint.  Each year at school we had a sports day where we all got to compete in races against each other.

The way it worked at our school, was that you got to choose which race you wanted to run in.  So, naturally I chose the 800 meters, but was dismayed to find out a week before that the best runner in my class was running that race too! I mean she could have picked the 1K, 400m or even the 100m. Why the 800 meters?

Well, I decided I wanted to win that race, so I convinced my main competitor that for the better good (there were class points system too), she was far better off running the 1K.

I remember the look of reluctance on her face as she agreed  that it was best that our class win two races instead of having 1st & 2nd in one race.

Well I sailed to victory in the 800 meters.

I still remember that day, traced with a mixture of guilt and pride (well, it was a neat bit of negotiation).

I’m still competitive, but I guess I prefer these days to win on my own merit instead of resorting to nobbling the competition.

So where is this all going? Well, I submitted a video to the Eurostar 2010 VideoStar competition. The prize is a speaker spot at Eurostar 2010.

(Its got cute kid , but not kittens I promise, I’m saving it for the sequel)

Anyhow, now you all know how competitive I am, I wish all my Videostar competitors the very best. I know its hard work to create a video (some of them are great)  I look forward to hearing some great talks in EuroStar.

Oh, and in my enthusiasm for creating the video, I failed to mention what I was going to talk about, which is software testing and startups, working on the bleeding edge.

Of course, if you want to vote for me……

http://www.eurostarconferences.com/content/videostar-competition.aspx

Walking the walk, but can you talk the talk?

In my experience, selling testing is a lot harder than testing. Despite being Irish, “the gift of the gab”  eludes me, often leaving me tongue tied and twisted when selling my wares.

Its one of the reasons I have got myself a business mentor.  His main focus has been for me to understand my ‘product’ and my customers.  He’s arguing at the moment, that the word ‘testing’ is not sufficient to draw in my customer base. The reason being, is my customers work in a different paradigm and use different language and so fully fail to comprehend the benefits that testing can provide.

We know as testers that testing can have massive benefits right across the company, and that the information and insight (thanks Joe) we provide is useful beyond the IT development lifecyle.  For example, we know that marketing can benefit from data resulting from performance testing, that legal teams can benefit from any compliance testing we perform.

There is a bit of a trend recently to describe our work in clear terms such as testing and bugs. Where before we perhaps worked in QA, we our now testers. We have ceased to use language such as gatekeepers and milestones. But I wonder in using such limiting language such as testing and bugs does it make it harder to sell testing to these stakeholders? I certaintly struggle in finding ways to bridge the language gap between testing and my customers.

Words such as Quality and Assurance have in a way become tainted and I try to avoid such terminology, but really where does this leave me?  I know for effective communication with my customers (who exist outside the IT world), I need to use their language and describe testing in their terms.

I will give you an example.

I attended a BizSpark networking event recently where a number of Venture Capitalists were present. One concept I’ve been toying with is to provide independent technical reviews on software products for investors and the like.  I know, it sounds a lot like testing, but if I used the word test  and bugs, VC’s eyes glaze over.

So I speak to them using words such as due diligence, audits and risk management.

Does this mean I’m not testing anymore?  Am I now selling insurance as opposed to  testing? Personally, I don’t see it that way, to me the core is all about testing. It’s just that the context has changed, and so the language has.

Perhaps I’m over complicating things here. I’m unsure.  I know that placing testing in their context it makes it easier for them to buy into. Is that so wrong?

I’d really like to hear people’s thoughts on this, it’s a topic that fascinates.

Waxing and Waning during Exploratory Testing

I had this great plan for today where I would observe how I work throughout a day of exploratory testing.  Unfortunately, the software is not quite ready for testing, so my plan has been slightly scuppered. Still I suppose this situation is often typical of any testing  scenario, so I will still include it into my final analysis.

The idea behind this ‘observation’ is I want to have an understanding of how my enthusiasm, concentration change throughout a day of testing.

The reason I want to do this is because I’ve notice that often at the end of testing I tend to be less enthusiastic than say at the start.  That’s understandable and probably most testers have noticed this wane themselves, especially if the testing goes on for a long time.

I attribute many reasons to this, for example, sometimes I leave the boring and tedious tests to the end, or perhaps I feel the majority of ‘interesting’ bugs appear to have been found. It might even be that once the excitement of testing something new has left, I’m left with my own discipline and sheer determination to get through the rest of testing.

So, I thought it might be interesting to track my enthusiasm and concentration in exploratory testing. I get to chose what I test and when, so perhaps with me in control of my testing destiny it would be interesting to see how my enthusiasm wanes and waxes. By observing how it changes, I might be able to put into affect some different techniques to use the peak  points of enthusiasm and concentration for testing the software and perhaps the times when I’m er a bit less enthusiastic to do documentation etc.

The idea is that by observing my testing flow I can plan better how to use my day.

I wonder if this is something that all testers would find helpful?  I imagine that most testers would differ in their daily ebb and flow. If you observed your concentration levels what would you see?

I will keep you posted on how this little exercise goes.

Testing my backbone

I’m a nice person. Well, I like to think I’m a nice person anyhow, and some people tell me that’s true too. Especially my kids, they tell me I’m the best Mum in the world. Aw shucks!

But sometimes, being nice creates problems because I want people to be nice back to me too.

This can be a real problem in software testing when faced with an aggressive and rude developer with little respect for your work.

The consequence of being ‘nice’ is that I’m as helpful and co-operative as possible with developers. Generally testers like me raise great bug reports and are very attentive if the developer requires further information.

On the down side, at some point in your working life, you are going to face an aggressive and unpleasant developer and to do your job, you are going to have to stand your ground.

And then its time for wimpy tester to find her voice and become  assertive tester.

So I’ve had to come up with some techniques to turn my wimpy ‘nice’  persona into an assertive positive voice.

For all you wimpy and not so wimpy testers out there, here they are:

1)  Rule Number 1. It’s all about the software, its not about you. Focus on your goal and don’t be distracted by outrageous and manipulative statements. Sometimes I imagine the developer yelling and screaming at the software not me.

2) Rule Number 2: Stick to the facts, and backup statements with evidence or in Cem Kaner’s language, find a credible source.

3) Rule Number 3: Don’t be bullied by an aggressive developer, raise your risks and speak your mind.

4) Rule Number 4: Keep a pleasant an even tone in all your discussions. Emotion is not required here.

5)Rule Number 5:  Focus on the commonalities. You both want the software to be delivered successfully. Work as a team even if it doesn’t feel like a team.

Remember the goal is not to get the developer to like you, its to get good software delivered. At the end of the day, you are responsible for raising bug reports and identifying risks. If some developer is determined to be aggressive, that’s their call, but if you stand your ground at least then you can complete your work with a clear conscience.

So you want to be a software test consultant?

Today, I’ m handing out some pointers that may or may not help you on your path to becoming a software test consultant. Some of these I’ve gained through bitter experience, others are more hindsight on things I ought to have done.

So, without  further ado, here are my tips.

1) Dreams are not goals

Its easy to have a dream about setting up a test consultancy, and actually, it’s really easy to setup a company, print some business cards and your dream is realised!  But unless you have short and long term goals, your business won’t go far. I set quarterly and yearly goals for myself and my business.

2) What does success mean to you?


I think this is essential to understand. What is driving you to run your own business? Money, freedom of choice in your work, flexibility? Knowing what will make you happy when you achieve your goals and dreams is essential to having a successful business. For me, my initial goal was to work for myself and not have to answer to anyone! It has changed over the years to include flexibility to spend time with my younger children. At times, this has meant my business has not been highly profitable, but it has always been successful.

3) Know your market and your products.

Who are you targeting your testing at? Any particular sector? Any particular size of company?  Ask yourself what products/packages would they be interested in? Ask your market what products/services they would be interested in? All this ought to be in your business plan. In my view a business plan is the equivalent of your testing strategy and approach, and its a very personal document. It helps you through knowing your market and your products, your rates etc.

4) How much should I charge?

There is no easy answer to this, which is why spending hours googling websites like mine is not going to help you. The general advise is that you should charge enough to cover your expenses and how much you need to live on. So, if you estimate on working 40 weeks of the year, and you need a salary of $100,000 yr to live on, you have company expenses of $20,000 /yr  then you will need an hourly rate of $75.  This may not be the final rate you charge, but you know its your minimum rate. That’s helpful to know if a client is trying to offer a lower rate.

I went for a tender recently and lost out. I asked why and they mentioned that my rate was to high. I was dissapointed naturally, but I knew that I had offered the right rate for me and I would not have lowered my rate just to get this piece of work, the risks were too high.

There’s a whole other heap of things that contribute to your daily rate, such as knowing who your market is, and what they will take. Bear in mind rates are very fluid, and in times like recessions they often move down very quickly.

Personally, I think you just have to go out there and try out a few numbers with potential clients. You will soon learn what’s acceptable and what’s not.  So, get off your butt, find a customer and charge a rate. If you don’t get the work, ask them why? Was the rate too high?

No-one said this was going to be easy!

5) Marketing Yourself

I have to mention something about marketing etc, because a) its so important, and b) it can be very time consuming. What are the best methods to promote yourself? Like any good tester, I’m going to say it depends!  There many ways to promote yourself on-line and off-line. I have gotten work from both online and through knowing people. Each country differs in what works best. For example, in Australia, a lot of my work came through the internet, so having a good online presence was essential. In Ireland though, it’s more who you know and going out and meeting people is more important.

Be very careful how much time your spending on the internet twittering, blogging etc, your time may be better spent meeting people or speaking to people on the phone. This is a big trap and one I constantly fall into!

Writing articles and speaking at presentations are other ways of promoting yourself and its a good way to start seeing yourself as a provider and not a consumer.

6) The baby years.

Realise that though you may plan to work 40 hours a week, you may end up working less than that, especially in the first couple of years. So what do you do?  Either you need a little nest egg which you can rely on for two years, or else you are going to have to supplement your business through short term contract work.

In fact, I think its a good way to transition from permanent to running your own business as it helps you learn about other consultancy type skills such as understanding the tax system, raising invoices, working by the hour, dealing with clients and learning market rates. These are all skills which you may not have come across in your permanent role and will be helpful in running your own business. At the same time, you are still assured of an income.

7) Always be on the look out for new clients.

This is a real challenge when it comes to working for yourself and I think is one of the biggest challenges to running your own business. Marketing and selling your work to new clients is essential if you want to keep the work coming in and takes an enormous amount of effort. But how do you fit this in when working for a client five days a week?

I don’t have any easy answers to this and I still struggle with balancing my sales activities with my paid work. Paid work has to come first, potentially leaving only evenings and weekends for marketing and sales type activities.

If you value you family life, you can try working 4 day weeks and leaving one day (or 1/2 day)  for admin activities.

Another idea I had, but I haven’t tried is to outsource your marketing and sales to another freelancer. I don’t know if this approach works, but sometimes I’ve been sorely tempted to try something like this out!

8 Use your network.

Everyone knows that in order to find clients you have to network. I remember being a bit overwhelmed at the thought of having to find this ‘network’ of people to source work from. How in the hell to I meet these ‘people’ who had work?

I realised after a while, that I didn’t have to look anywhere as I already had a network! My network was my family, friends and people I had worked previously for. So, when I started looking for work, I turned to these people first.  Let them know you have started working for yourself and could they pass the word that you are available? It doesn’t matter if they are non IT people, you just never know where your next piece of work is going to come from. Also, ask them if they know of someone who may be able to help or give advice? (People love giving advice!). The key is to start talking to people you know, and people who your network knows.

A great place to start is with companies you’ve worked with. These people know you, and what you can do. You also have the advantage of knowing their systems etc. Don’t be afraid to go back and ask for any work they may have. If you can make it part time even better as that way you can focus on building your business. One of my first jobs came this way.

9) Work smart

I will let you in on a little secret. I have a business mentor. I suggest you go out and find one yourself. A mentor is an excellent way of guiding you through some of the pitfalls in starting up your own business and can help you with the all important and essential business plan.  I got my business mentor through an enterprise network, look around your local area and see if there is something equivalent.

Footnote. I am not offering any business mentoring, so please don’t ask.

and finally

10) Its your path.

It’s good to get advice and ask for help. However, no-one is going to give you a template or process for success. You are going to have to make it up as it goes along. That’s half the fun of running a business. I liken it to raising kids. It doesn’t matter how many self help books you read on how to raise your children, in the end, they are only guidelines. You are the one who is going to make to decision on what to do. Are you prepared for that?  If you want it all mapped out for you, stick to your permanent job.

That’s about it!

I’ve listed some related articles I’ve written on the topic below:

Presentation: It includes some stats on where I get work etc

Article I wrote for the STC On being a successful consultant

I could go on, but I think I’ve addressed the main points. If you have any more questions on this  topic, feel free to ask in the comments below. If you think you’d be interested in this topic  at a conference let me know that too!

Please don’t post asking for work, that you will have to find on your own!

Good luck on your venture.

It’s time to grow up and ditch the security blanket

One of the hardest parts of working as a software tester is keeping on top of new technologies, techniques in testing and development and software testing tools.  I can sometimes feel quite intimidated at the amount of information that I need to absorb in order to keep on top of the game.

Gavin Davies writes about this feeling of intimidation in his post Software Development: Doing It Scared and how we naturally are tempted to retreat to a place of safety. As he points out though, it doesn’t get the job done.

He gives some tips on overcoming these feelings, I pass them on to you here:

1)      Cut it down to size.

If you have a task that’s overwhelming, cut it down to smaller manageable tasks. I like to set these tasks to dates as it helps keep me focused.

2)      Get Help.

There are lots of places where you can go and ask for help online (my personal favourite is the softwaretestingclub).  Try and keep your questions specific and put some context in the question to help those answering it.
One word of caution though, whilst there is no such thing as a dumb question, your question may have been already asked. Do everyone a favour and search first to see if your question has already been adequately answered.
Also, ask your colleagues and team members for help.

3)      Remember your existing skills.

Remind yourself that you are already skilled in some aspects of testing. Once you have learned your new technology/skill, you will be able to quickly ramp up and apply the new skill to what you already know.  It will get easier!

There’s a bit more on what not to do in the post, which is good reading. Gavin ends with this worthwhile point:

“Software can seem overwhelming. The more we learn, the more we realise how much there is to learn – more than one person can possibly know. As software developers, we will always face fresh challenges. Nevertheless, a life worth living will take you out of your comfort zone time and time again and positive thinking, teamwork, good practise and organisation can help tackle daunting tasks.”

Happy learning!

Is it Nerdy to Test on the weekend?

I’m talking about the European Weekend Tester Sessions that have just started up.

This was an entirely different kind of testing. The kids were screaming and running in and out of the house as I sat down on my computer on a beautiful and warm Saturday afternoon to join in with a group of people loosely called the european weekend testers. I shrugged off that feeling that perhaps testing on the weekend was a slightly nerdy concept and opened up Skype in preparation for a couple of hours testing.

Of course, there was completely nothing nerdy about the whole thing. Only a great bunch of people wanting to share and explore. Some testers such as Phil Kirkham, Anna Baik and Thomas Ponnet I already knew from the softwaretestingclub, but I didn’t know everyone.  Ajay Balamurugadas our facilitator, was one of the original organisers of the Bangalore Weekend Testers. We were set a mission, warned about some ‘traps’ and then basically were left to work our way through a problem.

After the testing, there was time for discussion on how the testing went and what each tester learned from the experience. Some great insights in particular on test management and how testing could have been planned more appropriately.

I liked getting to know everyone better. Perhaps it was the fact it was a weekend, but it seemed that everyone was very relaxed and easy going. Plenty of jokes were cracked and the whole experience was fun.  I felt I got to know other testers a bit more. I liked this a lot, as normally I work alone, so I guess this is the closest I get to working in a team environment.

Anna describes the event perfectly in her quote “But I will say it’s the perfect antidote to 6+ months of project deathmarch. Testing is fun again!”

Many thanks to Anna Baik and Markus Gartner for starting up this chapter.

Back To Basics: Automated Testing

Automating parts of testing has always existed since people have tested software. In my early days of testing the concept of separating testing into manual and automated testing never really existed. Well not where I worked anyhow. We tested, and sometimes we used tools to help us test.

In conformance testing we used protocol analysers and executable test scripts to verify conformance to ETSI protocols.  When testing Intelligent networks we used call generators and created SQL scripts to load data into databases. There was never a big divide between automated and manual testers.

I think this chasm only started happening with the introduction of capture and replay tools that offered the potential of allowing not so technical users the opportunity to reduce the amount of time required for regression testing.

When I talk about automated testing, I’m referring to the use of any tool that will help me test better.  If in the process, I end up testing more efficiently then that’s a bonus. Lots of tester’s think this way too.

Most of the time though, when the term ‘automated testing ‘ is used, it refers to coded scripts that help speed up regression testing and is seen as a superior substitute to manual testing offering added benefits of  faster testing and consequently greater coverage.

There is no doubt that automating your testing can deliver great benefits in improved testing, greater efficiencies (have you ever tried to manually perform load testing?) and in some cases cost and time savings.

But automated testing isn’t always the elixir or panacea that we think and if anyone approaches automated testing with a cost cutting  goal in mind, I’d encourage them to perform a cost-benefit analysis before engaging down this path.

I’ve discussed the benefits already, here are some typical costs that you might face:

1)      The development time for automating the tests.
The time involved for automating tests can be quite extensive, especially if you’ve never automated tests before.  If your automating tests inside a project, can the project afford the trade-off between delayed results (initially) and the longer term gains of repeatable and maintainable tests?

2)      Maintaining Test Scripts
Factor the cost of keeping automated test scripts up to date and relevant. If the software you’re testing has plenty of code changes, it can be safe to expect similar effort in keeping the test scripts up to date.

3)      Do you have the necessary skillset?
Do the testers have the skills to build an automated test framework? Do they know what tools to use and how much these tools will cost? If programming will be used (as opposed to capture replay tools) do the testers have the competence in the languages needed? If the testers need to learn new languages, are projects aware that a ramp up time will be required and that this may affect timelines?

4)      How do you decide what to automate?
Knowing the best area ‘s to automate is an art in itself. What is the best strategy for test automation? Which areas are best left to manual testing? The cost of getting this wrong involves starting from scratch again.

Automation can provide real savings and leave testers to go off and do more interesting stuff (while their tests are running), but needs to be implemented with intelligence and keeping the above factors in mind.

Many thanks to Evan Phelan for his input into this post.

Always look on the bright side of life..

The Magician

And what better way, than to download the new Tester Types E-Book.

Its a light hearted look at some of the types of testers out there and I guess we could all do with a bit of a laugh now and then.

I big hearty thanks to Rob Lambert and Rosie Sherry for writing and putting this together.

So, why not download it, grab yourself a cuppa and enjoy a read.

Oh and Happy New Year to you all.