So when you run your test data through your program, what do you see?

- does it crash (all the time, some of the time, specific test case)
- does it produce bad output (all the time, some of the time, specific test case)
- does it produce the right data in the wrong order
- does it loop forever / not at all.
- etc etc

We need more than "here's my code, it doesn't work". We provide help, not a rescue service.

Being able to debug your own code is a vital skill, as is being able to clearly communicate the exact nature of the problem.

For example, the first test would be a list with only 1 element.
If the test passes, fine, then move onto the next test.
If not, then you have a really simple case to step through the code with a debugger to find the problem.

Try it with a 2-element list.
Try it with a 3-element list. By the time you get to this one, it should be OK for any list.

So a report like, "it works for 1 element forwards and backwards, 2 elements forwards and then it just crashes at the start of printing 2 elements in reverse" is a meaningful description of a problem and shows us that you've done some work yourself.

If you don't know how to use a debugger, then now is a good time to get some practice in.