Seven mistakes of software testing


News: Seven mistakes of software testing

  1. Seven mistakes of software testing (1 messages)

    Though most developers know the importance of testing, it seems that a lot of them still aren’t testing enough. And if they write tests, they test just test wrong.


    If some tests are written in applications, most of them will be unit tests. It’s easy to test a utility class by just calling all utility methods, passing some values and checking if the expected result is returned.

    A first mistake arises here. Most people don’t think out of the box, or not enough. You can test that 1 + 1 =2 , that 2 + 1 = 3 and that 3 + 1 = 4. But what’s the benefit of doing almost the same test 3 times? It’s better to test the boundary cases. Are the arguments of the sum( ) method primitive types or Objects? If they are Objects, what happens if you pass null values? If an exception is thrown, is that the expected one? Does it clearly tell what the problem is?

    Read the rest of the article at the following URL:

    Java Code Geeks: 7 mistakes of software testing

    Edited by: Cameron McKenzie on Jan 17, 2012 8:16 PM
  2. Mistakes about software testing[ Go to top ]


    i had in mind that lot of people, even specialists in software testing, were used to use wrong terms about it at the companies i've already worked in the past, and now after reading this article i realized this is not only about that companies but this is becoming a global mistake.

    The author is forming a wrong opinion when  defining "Unit testing", "Integration Testing" and "Functional Testing", and this is a real problem and that's why i decided to send this comment.

    Actually, according to the most important references in software testing there are 3 phases:

    - Unit testing

    - Integration Testing 

    - System Testing

     And for each phase you can use lot of techniques like:

    - Structural (white-box)

    - Functional (black-box)  // THIS IS NOT A PHASE ! ! !  

    - others (mutation, gray-box, etc..) 

    So in a OO approach, we can define the unit as a CLASS or a METHOD. If the CLASS is choosen as a UNIT, each test case needs to test the whole class, otherwise it should test the METHOD, and in this case we can say a test that interacts with two or more methods of the same class is not part of the unit testing phase, but the integration testing phase, because the test would integrate two units.

    Another point i would like to make clear is we can use any technique in all phases, for example the author mentions the method sum() and in this case this is using a functional technique (result x expected), but this is not mandatory. It's possible to use, for example, a structural instead.

    All this information needs to be part of the test plan, where all the objectives, criterias, phases and techniques are detailed. 


    Best regards,