Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

I have experience testing from a business perspective but I'm currently working in an system which is a small part of a bigger system, so I don't have a clear vision of the entire business value flow.

From a black box perspective its just a service with one input and one output:

Input: a cronjob starts the service and it will query a DB for specific cases where it should send an email;

Output: the system sends a reminder email and write in the DB that the email was sent.

The developers write unitary tests, integration tests and system test. Its pretty well covered by tests from a white box perspective.

From a black box perspective, which kind of test can I put in place?

share|improve this question
add comment

4 Answers 4

I would start with what you have, the inputs and outputs, then start questioning. I like to go through a bunch of what if's, such as in your case "what if the database is unavailable?" or "what if the mail queue is full?" or something like that. If you can't come up with questions like that, then ask the developers "what didn't you test that you think I should?".

Often I am testing a small portion of a larger system in isolation, or just changes to only a specific smaller piece of something larger. Then you need to check the overall flows for the bigger pieces to the smaller, and the other way around. Definitely start with the requirements, and there are always requirements somewhere, and then start looking at what you have and think outside the box, so to speak, to whatever else there is that might fail or be an input or output that may or may not fail, or be other than what was expected.

I find it helps to know the whole system, but its often not necessary, as in many cases it depends on what it is you are trying to accomplish.

share|improve this answer
add comment

As a system of systems, black box really doesn't have a meaning (except what it means to you in your context). Let's take your last statement at face value, that the developers have unit, integration, and system testing well covered. I assume your question can be rephrased as "Give me some ideas for contributing to the team!" :)

Ok, here goes:

  • I assume the last DB write has a time stamp. Play with changing the time bases of the systems. Try cases of nearly the same (e.g. time zones), wildly in the past, wildly in the future, leap years, etc.

  • Play with connectivity. Get from the DB, then make the DB connection unavailable when the confirmation attempt is made. Try glitching it for a few seconds, a few minutes, a few hours. Does the output queue if the DB is unavailable? If so, does it lock up the service? Can you overrun the queue? Likewise, try making the mail server unavailable for a few seconds, a fews minutes, etc.

  • Next, play with network noise. Get a network simulator and inject some random error bits in the initial DB read, the email send, and the DB confirmation. Keep increasing the lag, bit error rate, etc. until you get a failure. Was the failure unexpected? Did it corrupt any of the messages without the system detecting the corruption?

  • Try invalid messages. Put all kinds of random characters in the DB fields, mail address, mail body, mail subject, etc. Can you make the system crash using invalid characters in the fields?

Those are just a few suggestions based on your general specs. Good hunting!

share|improve this answer
add comment

Your test cases have to be based on the requirements for your system.

If no requirements have been documented, you should ask some people from the project or from the appropriate business department for the requirements.

In your case, these requirements would probably contain the specific cases when an e-mail has to be sent, what content and which receiver the e-mail should have and so forth.

You do not need to know the entire business flow to test your system.

share|improve this answer
add comment

First of all you must have a clear understanding of the requirements. You should be able to understand how the requirements of the smaller system are going to affect the bigger system. Risk analysis and risk based testing are surely going to help in this type of scenario.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.