Skip to main content

Testing in the dark? How to come out into the light!

Many testers get bewildered when asked to test some software without clear requirements. How not to plunge into panic and come out of this situation safely if you do not have much experience to rely on your senses – this article will tell.
Hardly ever can a tester hope for complete and accurate functional specification document. In many cases there are early deadlines, sudden customer’s requirements changes, urgent tasks, independent or temporary human resources and other obstacles that can complicate the testing process. More often there are also misunderstandings between specialists from different domains that can be prevented only by your broad competence. However here are some tips that can help even inexperienced testers.
First of all you should give yourself clear answers to some general questions:
  • Will it be a unit or system test?
  • Will you do functional, performance or regression testing?
  • Is it a new product or a maintenance project?
  • How do the developers understand the system?
  • What other documentation is there besides functional specification?
  • Do you have a business analyst, domain expert or an end user available?
  • Are there prior functional parts in the system?
  • Are there any risk areas?
  • Which level of expertise does your team carry out?
  • Are you going to do manual or automated testing etc.? 
These points will reveal for you possible directions of testing.
As for the organisational aspect of testing consider the following tips as well:
  • Find out you team’s strong points.
  • Learn about the technical modules developed.
  • Depending of the testing type combine or decompose the modules.
  • Give every person of your team the modules consistent with their skills and knowledge.
  • Provide a constant communication between your team, developers and analysts.
  • Choose clear and analysis-free testing approaches to avoid misinterpretation.
  • Document the basics filling in the details in the process of testing if you have little time.
With these principles taken into account you may try some alternative testing approaches. To do user or acceptance testing involve an unknown user into the system so that you can detect its defects and see how users interact with it. While random testing you can test the system in your own method but this type needs basic requirements and functionality understanding. You may as well ask customers to write so called short stories on small pieces of paper that will make you separate tasks for further testing.
In conclusion, it can fairly be said that whatever the conditions of software testing, one should always think carefully and set clear goals before starting.

Comments

Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:


As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …

Leeds Testing Atelier - April 2018