Testing Presentation (Why we need testers)

As I promised in my last blog post, here is the presentation that I gave a couple of years back on why we need testers in development teams.

please note that everything about this presentation is rough as it was never meant to be publicly shown or distributed, it was created for a small in-house audience.

I’ve posted the headline text for the slide-show in this blog post and then link to the powerpoint file below. You’ll have to fluff out the main text as it’s only main headlines so I knew what text was coming for which slide.

DOWNLOAD THE POWERPOINT PRESENTATION

If you wish to make a similar presentation in the future you’ll have the slide-show above and the headline text below to refer to.

Text for the Slide-Show =

QA – Why we need Testing and Testers

2)      Jigsaw story or why developers shouldn’t test

3)      What is Quality and how to measure it?

Well we sometimes take quality to be subjective and we expect that others will know what we mean when we say that a product has quality.

But in an example of an car one user may say that the car has quality because of leather seats and air con – yet another may think otherwise and base the quality upon the engine specifications etc. However quality can universally be measured by the way a product meets its specifications.

If a finished product meets its design specs 100% then it can be argued that it is a quality product as it has been built exactly the way it was supposed to be built.

4)      BAD CODE = Creating poorly written code

Even after decades of advancement the software industry, the quality of software produced remains one of the biggest problems. This coding bad practice started mainly during the dot com boom as new start ups rushed to produce a working example of the “next big thing”, Even in today’s market we have a large focus on “time to market”, not only this but also the sheer growth and volume of software being developed, and the amount of amalgamated new technologies to absorb, it really is no surprise that software development houses still continue to face quality problems. There are two main sides to these quality problems: high defect rates and lack of code maintainability.

5)      ROI – Return on Investment

Speeding up Development time and less cost.

Almost every organisation in the world be they schools – governments or Nasdaq/FTSE100’s rely on software to help them with their daily processes. A vast majority will depend upon the software industry for product development, production, marketing, support, and services.

Spending on software development is very costly but there is a great way to partly reduce that cost and that it efficient testing processes. For example if there is going to be more that 3 iterations of software then it will usually be financially viable to start an automated regression testing process.

Better company image.

There can be nothing worse than using a piece of software and it crashing in front of a user. Especially if it does it in a messy way (losing data etc.)

Imagine buying a piece of software and having it fall over constantly because you put an apostrophe in a name field (O’Donnell for instance). This type of thing will happen on badly coded systems with SQL back ends (SQL Injection).

But with through testing the system should never fall over in front of the user and if it ever does the error should be captured and the user given a helpful message. With wide spread use of the internet its also possible to have automated bug reporting built into programs so that they not only provide the user a decent message and close correctly but they will also automatically report the bug to the software house with a small process tree list and provide the user with a defect ID.

This goes back to the car and idea of a quality product. If it does what it says on the tin then it should be OK.

But of course we can’t just test using this “on the tin” approach we have to try and break our product by first doing what it says “on the tin” (the design specifications) and then by doing everything else (lookup equivalence partitioning).

This can include buffer overflows.  Out of range integers – non syntax types – e.g. text in a date field etc.

6) But I said we need testers before I mentioned automated tools so can’t we use these test monkeys find these bugs?

Well the answer is NO –

Bugs are found during manual testing based on a testers desire to deliver quality product. Verification is conducted while the testers are operating the applications and comparing the actual results with the results they expect.  However, some bugs are still not detected with manual testing. Therefore, it is desirable to automate as many of the manual testing tasks as possible.

But these automated tools lack the common senses of a human being. Manual testers are still needed to test the high-risk areas of the products.

Test monkeys however do have a purpose and are often used in addition to human tests. Test monkeys are automated tools. Their testing actions are randomly performed without a user’s bias.

Benefits of them can be

1)      They will run and run until they crash a system (fuzzing being my favourite kind)

2)      They can be put on an old or slow system

3)      They don’t get bored or care if they GUI has changed.  (they can run test scenarios for days on end non-stop)

4)      Microsoft said that 20% of all its defects found were by using monkeys.

Not all automated tools are dumb monkeys in fact the majority of tools used are partly AI based.

7) The Perfect tester

What makes the perfect tester? In my opinion it’s the same hacker mentality of Steve Jobs, Steve Wokniak, Bill Klaxton and Bill Gates the old school hackers who helped to create the systems we use. They took a look at what systems existed (virtually everything back then was IBM or listed as IBM compatible) and wanted to change those systems by making them better.

It’s wanting to know how something works and wanting to see if you can beat it.

This beating it for me is finding a bug.

If any of the above is used in any presentations then I’d love to see/read your take on why software needs testers.

The Developer Jigsaw (or Why we need more testers)

A couple of years ago I was asked to present a talk at a testing conference.

I did a whole presentation that I will post up to the blog in a week or two. The one part of the presentation that seemed to grab everyone’s attention was a story I told about the Developer / Testing Jigsaw.

I think the reason it was so widely accepted was because its given in the form of a story, and we all like a story right?

So if your all sitting comfortably then I’ll begin.

There was once a small boy and his father sitting down together one Sunday afternoon.  The father said to his son I have a small surprise for you. I’ve made you a little jigsaw puzzle, its of a tree with grass and sky as the background. Wow, said the little boy as his face lit up, can we do the jigsaw now please?.

Of course said the dad.

So the dad tipped out all of the pieces onto the mat and begun attempting to put the jigsaw together. The son asked his dad if he could help by looking at the picture on the box and advising his father on where he thought the pieces were meant to go.

However his father said “no need – I created this puzzle so I know exactly how it should go together”.

The father struggled on for another 3 hours and wasn’t really any closer to getting the puzzle finished. He then got in a mood and said that he gives up and some pieces must have got lost.

The son then took over and compared each piece to the box making sure that he was putting the pieces where they were meant to go.  He did the smart thing first by putting all of the corner pieces where he thought they should go.  He looked at the box once more and thought to himself that blue is the sky, the green is the grass and the brown is the tree.  So he separated the coloured pieces in 3 piles

He eventually finished the puzzle in about 45 minutes.

There is an obvious key to what is happening above in this  story.

The Son is the Tester

The box is the Functionality Specification Document.

The Dad is the Developer.

The jigsaw is the piece of software that has been developed

Yes developers can test code, in fact I encourage it (peer reviews of other developers code and Unit tests),  however they should not be the sole testers of code, especially if the code is written by them.  Going down that route is a recipe for disaster.

The son who had never seen the jigsaw before managed to finish it in a faster time than his father and also in a more methodical manner.

Testing is a mindset. It’s an art that I, and many others spend every day attempting to perfect.  Developers spend most of their day writing code, (also testing their code – Unit tests etc.)

I’m all for test driven development, however lets not forget that with specialisation comes speed and efficiency savings.