Testing without requirements

Joel Montvelisky, Chief solution architect at PractiTest – test management tool, and Rob Lambert, Director of cultivated management, a tech consulting company with today’s topic: testing without requirements.

  • You can always find materials for reference that can be used as requirements, whether it’s a person, a system or any other source. If you don’t know what the spec is, go ahead and find out.   
  • Use testing oracles to find out how the system should work. The oracles can be customer requests, functionality of other systems, the code itself, email trails, commit feeds (using GitHub), etc.
  • Exploratory testing can be a good option in case you don’t know the system very well.
  • If you get conflicted oracles, try to brainstorm with their sources in order to decide on the right direction.
  • When performing exploratory testing on a system, use “personas” with a different personality and different skills in order to get the point of view for a variety of potential system users.
  • Having a map of the system’s current functionality will help you when you get conflicting opinions from customers.
  • As a tester, it is not only legitimate it is also important to meet customers face to face.
  • Watching users interact with the system can be very helpful. If you can communicate with users while they use the system you can gather valuable information.
  • If you are working with a SaaS system, logs can be very good oracles. If you have a certain area in the system, that you expect users to visit and they don’t, maybe it’s not good enough.
  • The support team can point out areas of the system that customers tend to ask about and help you discover the non-intuitive areas.
  • Review sessions, in which the team makes a decision about a certain functionality, can be crucial for a future agreement on implementation of a new functionality
No comments yet.

Leave a Reply