Testing Without Requirements

So, this is a question that comes up a lot: what do we do when we start a job, or a project, and we need to test, but there aren’t any requirements?

To some of us, it might be hard to see how we can be put in this position.

If you’ve only ever been at places where they have documented test cases or specs on a system, then the idea might be foreign.

But there are some places that are either too busy to write requirements, or just don’t see the need for them.

There are lots or reasons why a team or company ends up at this point–some good reasons, some bad ones.

But regardless what the reasons are, there may come a time where you’re in this position, and you’ll be asked to test against something that doesn’t have requirements written, and maybe… noooooooobody knows fully how it works.

Today I’ll explain how it’s not an impossible task–that you can not only succeed, but thrive in this case, and sharpen your testing skills too.

I’m a tester… and I can test without requirements… if I have to… I guess.

 

Black Box Testing

When we take a piece of software, and we don’t really know what’s going on inside it–“inside the box” so to speak–we’re using Black Box Testing to test it.

If you’re not familiar with the term, Black Box might sound kinda spooky.

It’s really not.

It’s a little like… well, it’s like picking locks.

You can’t really see inside the lock, but you can use tools, and your perception, to feel around and learn what’s in there. And, you use what you know about previous locks, to glean information about this one.

Same thing with Black Box Testing.

Probably you’ve tested software before, and you’ve found bugs too. We’ll use these tools and perception for future testing.

Below we have an example of a simple form, along with a sample conversation that leads up to you having to test something without requirements.

Check out this form:

And then here’s a hypothetical conversation you might have with the manager:

Hey so yeah, we had an intern throw together a simple form for entering customer data. We were needing it for a client POC. It was good experience for her.

Client loved it, so we went ahead and built the rest of the product after the fact. This part, this form, isn’t customer facing–we just wanted to have a hook to load customer records into the system.

Aaaaaand now the intern’s gone, and we just never took the time to spec out such a simple form. But it still has to be tested. ¯\_(ツ)_/¯

Awesome. No requirements. Perfect.

Don’t lose hope yet though, because there’s still a lot we can test for. We’re not flying blind.

We know that this form likely stores data in a database somewhere, and we can cover a lot of tests just by seeing if our data gets transferred over to the database correctly.

Here are some other things we can test:

• Do the required fields actually enforce that you put something in? What if you leave all but one blank for each test, do they each fail as expected?
• If this is storing data in a database, can data get “clipped”? If you put in a 20 character name, but the database only stores 18 characters, is that a problem?
• Does the form error out if not enough or too much info is provided?
• That date form–what format does it expect? Does it error out appropriately if the wrong format is put in?
• Does the datepicker next to it populate the date field as expected? Does your locale (US vs. non-US) affect the date format, and does the rest of the system handle it?
• What if you pick a date in the future, is that bad?
• What’s the Active checkbox for? Does that state carry over to the database–does a flag get set? Or if you select it does nothing happen?
• What if you try to make another customer record with the same name, does it stomp the old record or create a new one? And then which of the two is supposed to be used elsewhere in the system?
• What’s supposed to be in the Investments dropdown? Is that populated from somewhere? Do the contents match the source of the information?
• What about the email field, does it sanitize to make sure a valid email address is in there? What if you try to splice two addresses together with a “;” character? Does it allow it?
• For each text field, can you get an XSS or SQL injection attack through? If so, very very bad. That needs to be fixed.
• Can special characters be handled? Not every name is just letters.
• When you click OK does the record actually get stored as-is in the database as expected?
• If you click Cancel then does the data get dropped? If you go back to the form again after canceling, are there any artifacts left over from the previous attempt–fields that were filled in from last time, still showing up next time?
• Can you modify the DOM and get wonky data shoved in somewhere it doesn’t belong?

There’s a LOT that can be tested. There’s likely more. Can you think of other cases?

A small part of software testing is making sure the software does what it’s supposed to. The remaining, larger part of it, is ensuring that it does NOT do what it’s NOT supposed to do.

It’s by far the bigger challenge, because we have to think of things that other people usually don’t think of.

And, it’s the kind of challenge that will sharpen your skills, and put you a level above people who rely on (and need) requirements in order to function.

---

If you’re up to the challenge of looking hard at how the testing and automation piece is done, I can help with that. And then I can help you level up. www.archdevops.com