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