Testing without Documentation

Any seasoned tester would have at least one story to tell when he/she has to test a system or a piece of software without any documentation, and those who have done so would also tell you the many problems they faced as a consequence of having to do so.

But testing a piece of software without documentation isn’t something that’s going to go away, regardless of how loud we, the testers, complain or shout about it. The sad reality of life is that this has happened in the past, it is still happening now and will, undoubtedly, continue to happen in the future, especially with the current trend in Agile Development, where the emphasis is on closer and frequent communication between Agile team members and less so on documentation.

So, what do we do when we are faced with the situation of having to test an application with nothing to compare it with? I would suggest a few pointers:

  • You would use Exploratory Testing to discover what the application does, and treating purely as a Black Box.
  • You would record the behaviour that we observed, in as much detail as possible. This means the following:
    • running end-to-end scenarios of the application, on the first instance
      for each interface/dialog,
    • trying out all controls (e.g. text boxes, check boxes, lists, drop-down boxes, radio buttons) and noting their behaviours
  • Making a list of all input data type/class and how they are processed by the system and the outputs generated.

Once you have completed exploring the system and noting the behaviour you would present these to the developers, analysts and stakeholders, i.e. end-users, and determine if the observed behaviour is what is being designed or for requested by the users.

Any discrepancies identified between the system behaviour and what the user expected or what the analyst designed can then be deemed as defects.

Leave a Reply

Your email address will not be published. Required fields are marked *