Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I would like to get my younger brother, who can't program, to test some code I am writing from requirements I provide him in documentation. Is there a way to get him going quickly? Ideas?

Please and thank you.

share|improve this question

closed as too broad by gnat, MichaelT, World Engineer Oct 22 '13 at 1:09

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
How old is your little brother? Are we talking about a child here, or a younger adult? Also, what is the goal? To test your program thoroughly and quickly from an end-user standpoint, or to help him learn as much as he can from this experience about software development and testing? –  Ethel Evans Jan 5 '11 at 18:28
    
@Ethel, he is 15. The goal is for him to gain experience as as well as test different parts of the tool for functionality and coherencies. –  dustyprogrammer Jan 5 '11 at 19:16

5 Answers 5

up vote 3 down vote accepted

I'd recommend just doing black box testing. There are three ways I'd recommend of doing so. First is to let him just mess around with the software without telling him the requirements and see what breaks the program. The second is to write a script for him to follow covering various use cases. The last is to give him a task to perform and let him figure out how to do it himself. There are advantages and disadvantages to each.

Advantage of the first: Lets someone who doesn't know how the software is supposed to be used do things that you didn't anticipate. You might not think that this is important, but users can do some really weird/bad stuff.

Disadvantage of the first: Since you're not telling him the requirements of the software, you don't know exactly what he's doing so you need to more strictly observe what's happening.

Advantage of the second: You are testing the requirements directly and know what is being tested.

Disadvantage of the second: You are only testing what you can think to. This doesn't account for users doing something you did not expect.

Advantage of the third: You are seeing what a user might do when confronted with the software and seeing how well it works with those combinations. You're also getting some usability data on your software as well (I'm assuming this is primarily for usability testing since this type of study was required for that course)

Disadvantage of the third: He doesn't do any tasks you don't tell him to and you have to strictly observe what he's doing to see when something is going wrong or when he's having trouble completing a task.

share|improve this answer
    
I think this is a great way to do it. However, you don't need to do just one of these approaches. I would recommend starting with #1 for 5 to 10% of the time you plan to spend on this with him, then move to #3 for the next 50% or so of your time, and end with #2 to make sure scenarios you care about are getting hit and to introduce him to test plans. This also mimics what testers often do when given new software: Mess around for a bit to "get a feel", then sit down and methodically explore functionality ad-hoc, then design and walk through a set of tests that can be repeated. –  Ethel Evans Jan 6 '11 at 20:15

If you want him to do Unit testing, that's not that trivial thing for a non-programmer to do. But he can "play with program, push the buttons, etc." One doesn't have to be a programmer, to do this type of testing.

share|improve this answer

If you're talking about manual end user testing, I asked a question on stackoverflow which might be helpful.

Where can I find a good beginners guide to user testing?

share|improve this answer

Since you brother can't program I am gathering you are approaching this from an end-to-end testing stance. With this being the case your brother should be able to exercise your application with the documentation. If he is unable to exercise your application based on your documentation then your documentation is inadequate.

Have him plan varying paths through the application after he gets an elementary feel for the application based on your documentation. Have him then write tests accordingly and execute them; providing you the results for review.

Step 1 - Open application
Step 2 - Click blue button (should see blue dialog appear)

One caveat with this approach...his definition of a bug will be anything un-expected since there will be no formal requirements to go on. Is that wrong? Not necessarily, but be careful when stating that that was the intent when perhaps the intent is wrong and needs adjustment.

share|improve this answer

Could you use a unit testing framework (nunit etc)? They're more reliable than little brothers :-)

share|improve this answer
    
Unit testing is good for testing if parts of your program work with the given input. Little brothers are good for testing the program as a whole. This is basically a pre-acceptance test acceptance test. He wants his brother to go through what users would do when trying to complete tasks or find other ways to break the program that he didn't think of. The problem with writing unit tests yourself is that you don't always think of everything. –  indyK1ng Jan 5 '11 at 20:20

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