Real-World Testing Questions

Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")

Moderator: General Moderators

Post Reply
nowaydown1
Forum Contributor
Posts: 169
Joined: Sun Apr 27, 2008 1:22 am

Real-World Testing Questions

Post by nowaydown1 »

Greetings Guys,

I wanted to see if I can lean on a bit of the expertise here to help me solve a testing related problem I seem to be facing. Most of my employers have been small businesses that build web software. The dev teams are generally very small (2-3 guys), and the companies don't have the revenue to support a QA department. As a result, the developers are normally left to figure an approach approach to testing the product.

Existing testing practices follow a very loose set of test cases (steps to test a single feature). There's a few unit tests here and there, but as far as code coverage goes it doesn't exist. The product as it stands is probably somewhere around 35,000 lines of code. As the size of the product continues to increase, as you can imagine it becomes more difficult to test.

The app is written in PHP5. The project doesn't use any sort of MVC setup, so the page level logic is normally contained in an appropriate .php file. So for example, we might have a page that asks for an email address. The validation code for checking that email address (among other things) would reside at the top of that page. There's classes, but they don't really handle business logic and more serve as a method of getting stuff into and out from the database. The code for the mostpart is fairly clean & readable. That said, it's already to the point where the amount of testing time required to adequately make one testing pass has become too excessive.

Have any of you guys faced a similar situation? Any thoughts for solutions? My gut feeling is that time needs to be invested in getting code coverage in the form of unit tests. Given the limited financial resources, and the existing state of the product, I'm sort of at a loss. Any thoughts/suggestions welcome.

Thanks guys.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Re: Real-World Testing Questions

Post by Ambush Commander »

It sounds like Selenium would be a good idea, since a lot of what you're doing right now is probably manual testing. However, if you don't have a "testing culture", it'll be difficult to keep the tests maintained.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Real-World Testing Questions

Post by Jenk »

First thing to do is to encourage your colleagues/employers to try out TDD/BDD - don't force it. It's guaranteed to be rejected if forced :)

Try out Ping Pong programming, it's good fun, and you can add a degree of competitiveness to it if you think it won't cause conflict, which is a good way to keep the discipline. (e.g. add a points system, so if developer A writes one line of test, that takes developer B 10 mins to satisfy, he/she scores 10 points. Developer B writes one line that takes Developer A 5 mins to score, he/she only scores 5 points etc.)

There's some good literature on converting "legacy" applications, such as the Strangler Pattern devised by Martin Fowler and friends.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Re: Real-World Testing Questions

Post by McGruff »

nowaydown1 wrote:That said, it's already to the point where the amount of testing time required to adequately make one testing pass has become too excessive.
Bad code can be very difficult to test, so much so that it may be better just to tear it up and start from scratch. I had to do something similar recently with one of the first apps I ever wrote. It worked but it was impossible to maintain. If good code is a finely-crafted Rembrandt this was a load of old Jackson Pollocks.

Anyway, if it really is that bad, I think I'd start by writing acceptance tests. These will tell you when something isn't working (although not why: you need fine-grained unit tests for that). That gets the app under control. The same tests also define the target to hit for the new version. On the side I'd TDD away through the code until it's sorted.
Post Reply