Self Testing Tips? [closed]

Question

Basically I'm wondering if anyone has any tips for ensuring your code is well tested without getting any help from anyone else in a limited time frame?

In the past I've always been able to find someone else to do testing on my code or had a dedicated quality assurance team go over everything and find all the errors.

I'm usually pretty careful but I always find there a things I miss and when I test them I just don't see them.

However in my current job I've been given two PHP web applications to write in a very limited time frame and I've been told I need to do all the testing myself despite my feedback that this wasn't a good idea.

I was wondering if anyone else had this problem before and could offer some insight?

I was thinking perhaps it would be good to write a quick test plan before coding each area and also to double check the requirements before doing testing.

Answer 1

Certainly unit testing, whether test-first or not, should be your first line of defense, ensuring that each piece of your application works the way you think it should. However, the type of testing you're talking about, where it can be helpful to get another pair of eyes, is more in the area of acceptance tests -- does the application as a whole work the way it should; does it work for various weird scenarios or behaviors, etc.

One helpful approach is to imagine personas: first test the application as yourself, but then test it again imagining that you are 85 years old, can't see terribly well, and don't use a mouse that well. You may tend to click on the brightest or largest thing, assuming it's what you're supposed to do, which it may not be. Now imagine you're 12 and in a tearing hurry. No way are you going to read instructions. Does it still work?

For any given field, what are the edge cases of what a person might type in? What happens if you type only spaces? Only numbers into a textual field? What happens if you type HTML? Javascript? Something in a non-western alphabet? What if you type something really really long?

The key is not just to test the "happy path", where the user goes through the application the way you had in mind. Go through the application in ways no one ever should. Because... they will.

The other important piece is never to ignore anything. It's easy to have a weird screen come up and say to yourself "Oh, that's just a fluke." You have to make yourself notice and track down everything that isn't just as it should be.

Answer 2

There are always constraints on how much testing you can do. Within the constraints, you obviously need to construct tests. Clearly you want to construct tests for the most critical areas first (security, possibility of damage, loss of data, functionality).

Other than the functional specification, you're not likely to get a lot of manual help deciding what to test. But you can get automated help in the form of test coverage tools. These tools tell you what code you have tested, and therefore what code you have NOT tested. By inspecting the untested code, you can determine if it is more or less critical, and therefore more or less deserving of having tests coded for it before release. Test coverage tools also tell you the ratio of tested code versus total code, and its an industry best practice to ensure that this ratio is 70% or above. You can use this data to negotiate more time with your boss by a simple artifice: "We only have 15% test coverage... dare we release it?"

A test coverage tool that works with PHP can be found here: Semantic Designs PHP Test Coverage Tool