How To Software Testing Without Requirements
It is a common question that keeps popping up in my talks with other experienced and inexperienced testers.
First of all, there’s no such thing as no documentation at all in a software development environment.
Ok, but I am facing this right now and it is a reality to me. How come I get no requirements for my tests? You ask.
Well, it can happen but maybe the issue is not that there’s no information whatsoever. There’s must be an example, a draw, a mockup, a discussion, a description of some kind that software testers need to dig up to get that information.
Perhaps is the methodology applied to your team or the project you are involved in with, being in-house or remotely.
I can tell from my own experience that it can happen but being creative as we testers are, we need to find out, in the process, where to look up for that info.
Here’re the things that I would do. Tailor it accordingly to your needs.
Don’t be afraid of asking questions, is better to look foolish for a couple of seconds or minutes than miss an opportunity to clarify something and look even foolish when the time has passed and you only realise when the product is released.
Don’t be afraid to go beyond the boundaries. It’s kind of tied up with the questions. Investigate, clarify and go where you guts tell you to. I’m saying this coz other stakeholders may say that you don’t need to test this or that. Without losing objectivity and drawn too much on your plate, go beyond the boundaries and explore further. Make the unthinkable thinkable and trust me, most of the times it pays off.
The information is in somebody else’s minds, you need to dig in. The answer is given with questions and tries to find information in backlogs (for example in Agile projects), a help file, emails, other versions of the application, test cases from other stakeholders.
Be open to help. Offer to appear at meetings, stand-ups, discussions, meeting with clients, customers, users. Walk into the developer’s team and politely ask if they can share the unit tests with you, talk you through how they are developing and how did they get the info from the project team.
Build Your Own
While you are investigating and questioning yourself. How am I going to test this? Write a list of questions and arrange a moment to sit down with the BA (Business Analyst), Developers, Product Owner even Client/Customer to seek clarification.
Sometimes, you may find that stakeholders can over protect its project and are not used to share information. This is a reality that most of us testers has to face on the daily basis.
Draw a Plan
Somehow I debate the fact that we testers (not just testers, the whole team) need a map. You don’t decide in go on holiday and simply show up in any airport lounge and jumping a flight somewhere in the world without any planning. You know where you are going, you plan how many days, you make sure you have sufficient funds to cover your basic bills and expenses while you are away, how much money you need to spend while on holiday, you buy suitcase, clothes, food, book hotel, hire a car, buy the ticket then off you go.
In a way not given you something to hold on with gives you freedom to explore. It totally contradicts the topic above, but it is true. If you can’t find information, explore, be creative, use your past experiences and apply assumptions. While you are doing this, discuss with the team, ask what they may think about this and that. I’m sure you will definitely get something out of it that you can finally apply towards your test scripts.
To Conclude All This
My approach is, to be frank. Talk facts and don’t over promise.
I do follow the principles of testing but in most cases the phycological interaction with people that makes the difference in being able to write the test cases, being objective and deliver the result adding value to the project, the team and the end result desired.
I would say it’s simple, but not easy. Stick to your guts, talk to people, observe, gathering the information as much as you can, record all the info in a structured manner, present the facts.