Tell your child that it's like the coders give you a vending machine.
Then you put candy and chips into the vending machine, you decide how much of each item you want to start with. You also get to decide the prices on the items in the vending machine. - Sometimes you don't, but best case scenario you get to create your test data.
Then you start by doing the easy tests:
YOU: "If I put in a dollar, and I select A1 do I get the bag of chips?
Do I get any change?"
If you should get the bag of chips, or you don't get the correct change, then you call the coder over and show them:
YOU: "Hey I did this, and I didn't get what I wanted"
The coder sometimes looks at the problem and knows immediately that you did something wrong.
CODER: "You hit 1A, not A1. Try again using A1"
But sometimes you put money in, hit A1 and the bag of chips starts to come, but gets stuck. Then you have to show it to the coder, and the coder will say:
CODER: "Well that's not my problem, you have to talk to the
architecture guy. He probably made the gap between the glass and the
products too narrow. I told him I wanted more space because we wanted
to put candy and chips in the vending machine, but he said it costs
too much money."
Then you have to deal with the coder and the architecture guys going back and forth. You just wanted a bag of chips - but THEY turned it into a "Who's engineering degree is better?" contest. Which is why you got out of dealing with code or architecture by doing software testing. So you just write the issue down and hand it to them to figure it out while you try to move on and do more testing.
That issue is a bug. Coder's HATE the word bug ... it means they are not infallible ... but they are, and so are you, and so is the architect... everyone makes mistakes.
Maybe once these two stop working against one another and actually try to get something done, you get a fix to the "glass too close to product" issue. Then you can test it again on the vending machine. Until then you can't do any more testing, so you just drink coffee, and browse Facebook.
You to try to get all of the products out of the machine, and you keep checking that each time the machine took your money, gave you the right candy or chips, and gave you the right change.
Once you've done all that work, you have to try to break the vending machine. You start doing "silly" things like putting no money in and pushing buttons. If you got candy, but didn't pay for it that would be great - but in the real world that means that the vending machines would always be empty.
If the vending machine wasn't built correctly because the coder assumed no one would ever try to get candy without paying money they'd lose all their candy. Then the coders wouldn't get money or have candy. That would be sad...
If all the products got stuck in the vending machine because the architect didn't know that a bag of chips can turn sideways as gravity takes over, then people that did pay for chips wouldn't get them. That would also be sad...
So your job is to help make sure the vending machine works the right way. But you also have make sure that the vending machine doesn't work if someone tried to use it the wrong way.
Once you say the vending machine is ready, then your company starts putting them everywhere for everyone to use. Because you did your job your company starts making a lot of money from people buying candy and chips from the vending machines.
That's just functional testing though. There are other tests:
Usability tests - Are the buttons on the vending machine too high up for a child to reach?
Performance tests - How long does it take to get my candy? How long will it take a bunch of people in a line to get candy out of the machine?
Security tests - Does the vending machine take credit cards? Does it have WIFI? Can I get all of the credit card numbers from the vending machine... to buy candy for myself at a different vending machine...
