DO you Think Testing is neglected?

[Chakkilam]

Hi,

I've been speaking to a number of application development companies and developers.It is surprising to know that most of them do not have a defined testing practice. However, the reasons might me the tight delivery schedules or lack of defined test processes and procedures or
dearth of testers. I believe that developers can deliver a better product only when Testing Practice is implemented right form the designing stage.

This will ensure a high quality product coupled huge cost saving ( Fixing the bugs identified by users is always costly). The better the quality of the product, more the customer satisfaction.

I welcome your views on this.

 

[enigma1]

Yes, regarding testing it is interesting because unless the man in the middle or merchant understands the development cycle of a product the only thing you may get is a plain requirements email. Not even a document or a detailed explanation for each requirement.

In many cases it comes down to the developer or freelancer to setup the timeline or schedule for work completion. More and more people are looking for the cheapest possible option thus in many ways this comes at the expense of quality (and lack of testing). To counter this many companies or freelancers offer some support after the product is delivered but in many cases the terms and conditions are unclear.

Another mistake merchants do is switching developers in the middle of a project or they are forced to hire a different developer to fix bugs because the original contract had no guarantee of any sort. I have seen people spending more to fix or replace parts of the finalized code than the entire project is worth.

As a merchant you should always keep a balance. Invest just enough to setup something that you can promote and sell products and leave the exotic features when you have the right budget. And test the finalized product at least from the normal user interface that you should be familiar with. It may sound strange but I run into situations where a merchant will contact me months after the completion of a website asking how a feature, he originally requested, works (let alone testing and fixing bugs).

 

[fisicx]

Testing is almost always neglected to the detriment of the customer. There are so many ecommerce sites that were written from a developers point of view rather than the customer,.

Usabuility and accessibility are often put to one side in the desire to cram as much information on the screen as possible whilst forgetting that the visitor might actually want to buy something.

 

[FireFleur]

It is hard to find good testers. A good tester needs to understand the underlying technology and be able to understand how to produce errors that are not straightforward in their reproduction.

So, what normally happens is if a tester is good they can earn more money developing or in security.

Functional style programming and good specifications is the real way with unit tests but not many want to stump up the cash for that.

The industry tends to work on acceptance testing, so the client tests the system.

Developers are always testing, I think people don't really understand that, all the way through they are doing a number of checks, but they cannot be expected to find everything they are too close to the code, but they will actually find more bugs than anyone else in the process; i.e. they are the top tester.

And development is where ideas hit the road, if you specification is wrong then at implementation that's where it becomes rather glaringly wrong.

On the whole there will always be some errors that slip through, but to be honest the state of software is much better than it was just a decade or so ago.

Testing it is a good thing to do, but how much extra to dedicate someone to it or a team, well it depends on the product.

 

[Chakkilam]

I agree with you when you say developers are always testing and they cant find all the errors. However, good testers shifting to development profession may not be so.

Companies can save lot of money when bugs are identified at requirements/ design level.

 

[FireFleur]

Problems identified early on is the best time to find the bug generally.

Worse time is being waken 3 O'clock in the morning on a Friday, to find a system has problems and the transactions are mainly weekend based.

The problem is if you have testers who don't understand the technology you end up with a load of false positives and subjective testing, have a read of some of the Beta game testing articles and you will see a big variance in how companies handle this.

With games people are generally interested, but good testers are hard to find, it seems people want to do design not testing, and then not design as in responsibility for the whole system and how it fits together, but design and champion their own idea.

Really good testers tend to be hackers, they look to break stuff and will generally find the problems, but they also tend to enjoy the technical stuff, so testing unless it is penetration they tend to gravitate away from.

I think automated testing is the way forward, and quite a lot of open source stuff uses that approach, build gcc and it comes with a perl suite of auto tests. You can use things like X automation and visual greping to test stuff, I think that is the main value in testing automate it.

So returning the idea what do you mean by testing, guaranteeing there are zero bugs, insuring against there being bugs, and what is a bug?

 

[Astaroth]

I think there are different types of testers, certainly those that are doing unit testing need a good understanding and may well do better by moving across to programming but User Acceptance Testing people do not require that, they require a strong knowledge of how the actual end users will operate the application/ site.

As others have already said, there is a fundamental shift required (with the associated increase in costs) if we are ever going to get into the place where proper testing is done. Before the age of the internet I knew of very few SMEs that would commission applications to be built as almost all bought off the shelf packages which at best could be branded or tweaked with settings. Now you have a massive volume of SMEs, new starts and speculatives wanting custom software developed on a shoe string budget.

To be able to do rigerous testing you need to have rigerous specifications and to have rigerous specifications you must have rigerous business requirements. All of this adds a lot of time and effort and thus also cost. Back in my corporate days development was under 20% of the time estimate with the rest being made up predominately of design and testing.

It does raise a big question though.... an existing SME with a brand image approaches a web agency wanting to move into ecommerce. Should the agency look at the 1 page email and then start to sell a custom template for their standard ecommerce package with a budget of £X and a timescale of 3 weeks or should they spend what can be a month or more accurately capturing all the requirements and ensuring that everyone will be 100% met and so potentially increasing the project cost to £10X or more?

I don't think many small businesses are prepared to pay the cost of "traditional" development (particularly if you think waterfall methodologies rather than agile) in terms of monies nor speed to market. I do think that they prefer the 80:20 rule (or possibly even 60:40) due to the savings. I dont think many realise that is what they are doing though!

 

[fisicx]

See I'm looking at this from a competly different perspective. I couldn't care less about the bugs in your code, that's your job. All I care about is my potential customers. I care about the order and how the information is presented, the processes to be followed and the pathways to get from one area to another. It doens't matter how many hacks you used to get the checkout to work - if the user experience is soured then they won't buy anything.

So before you finalise the code, you need to get some user testing under your belt. They may not be able to break the site but they will know which bits they don't like. No pount in delivering a website that works perfectly but nobody can work out how to find a product.

 

[KingsandQueens]

I typically get beta users who are tech savvy to undergo user acceptance testing. This reduces the cost of testing and time to market for most projects.

Tech savvy user’s love having a say on how to improve a system and if you throw in a few enhancements based on their suggestions for free then you have some very happy customers who accept they are guinea pigs and the beta bugs but the love the system.

The ONLY person qualified to test a system is the end user, as a developer I just need to make sure the system does what the user assumes it will and that the any issues picked up in UAT are dealt with quickly.

 

[FireFleur]

Usability is often subjective.

It should be rationalised and included in the specifications, but not many can do that, so you often see usability testing done on gut instinct and it is often wrong, or undulates between wrong and right.

To give you an idea of good usability, Perl is one of the most free form languages, the motto is there is more than one way. Of course this leads to a maintenance nightmare on some Perl code.

Perl Best Practices attempts to rationalise each structure of code layout, and tries to avoid the subjective instead looking for the perfect form.

I don't see many usablity testers capable of that rationalisation, I do see a lot of twisted knickers, pouting and back tracking though.

Usability is often about exposure and engagement as well, it doesn't lead it follows, and something can be thought of as bad on usability one moment and the standard the next. MDI and SDI is an example of this, with SDI taking over from MDI currently, but could flip back.

 

[stevemac]

Slightly different angle:

I'm astonished at how many websites fail W3C validation - HTML/XHTML errors, CSS errors, etc. I primarily use Firefox to browse the web & my 'develper toolbar' very rarely indicates no errors.

Very few websites display the W3C 'validated' icons. I view validation as a sign of good practice & a direct reflection of the professionalism of the webmaster/designer.