Time To Quality Test

Humans are not perfect

Humans are not perfect, and since we are the ones doing the programming, a lot of times programs have what´s known as bugs, or errors(Fun Fact: they are called bugs because way back in times of the ENIAC, what caused problems were literal bugs who crawled to the machine).

Sometimes bugs can be as disastrous as cracking your program the second you run it and ruin everything you´ve worked so hard for!!! and other times they´re not as bad, but either way the best thing to do is spray Raid over them and kill them(please don´t spread Raid ver your computer, that thing is really toxic).

Resultado de imagen para software bugs

Software testing is just what it sounds like, to run your own program and see how it works, so you can correct any mistakes you may have made. This is usually made in order to debug your program, or to give it maintenance(which a lot of times ´maintenance´ means a new bug was discovered). While it may seem easy, it often gives not-experienced programmers(like me) a really really hard time.

This is a huge topic and has a lot of coverage in it, so we´ll start from the beginning.

Why do we do it?

Well, first of all, a crash in your program carries a risk of damaging your hardware. Also the people funding or contracting you don´t want to pay for later debugging, because that is quite expensive. A study from the NIST in 2002 found that this is the cost of debugging at later phases of the development.

Cost to fix a defect Time detected
Requirements Architecture Construction System test Post-release
Time introduced Requirements 5–10× 10× 10–100×
Architecture 10× 15× 25–100×
Construction 10× 10–25×
Table taken from NIST Study, 2002


can see, if they skip just one phase at debugging, it could end up costing 3 or even 10 times more than it would had you noticed them in their respective phase, of course this takes a lot of experience, which is also why it is one of the hardest parts of software development. Also, from a consumer standpoint a lot of times you want to pay for something of good quality, so if a program is not correctly debugged, it may end up decreasing sales.

All right, I get it…how do I stop it?

There are a number of different ways you can test it.

  • Static and dynamic testing
  • Visual testing
  • integrated testing

But the one that is most common of them all is the box testing.

Box testing

The box testing is a combination of two methods called the white and black box testing

  • White box testing: Is the testing you do to all your internal gears and workings, it is a test that can be performed at any level or phase because since the program doesn´t change, just gets added. A white box test can usually work, but it is recommended to do it at a unit level(go as deep as you can) some of the techniques include:
    • API testing : testing of the application using public and private APIs (application programming interfaces)
    • Code coverage : creating tests to satisfy some criteria of code coverage ( tests to cover all the possible oprtions)
    • Fault injection methods : intentionally introducing faults to measure the efficacy of testing strategies
    • Mutation testing methods: modifying the program just slightly.
  • Black Box Testing: This tests is done on the funcionality level alone, it´s the equivalent of dummy testing in other areas. It is supposed to be done simulating you have no knowledge of the inner workings of a software. This is the kind of testing they do when inviting outsiders as beta-testers.

Software testing can be a really important step depending on the objective of your software, but it´s still a very important test to be performed. Software doesn´t yet have a set of rules like other areas do(Quality examinations) but this one´s hoping they don´t delay much.

All images used in this post were taken from http://imgur.com/r1YL0R5