Tip Discussion: Smarter Tools, Dumber Developers?

If you have any questions or comments about this article please post them here.

This forum post relates to this article

Very good article. I think it hit the nail right on the head. This is one of the reasons why I do not like WYSIWYG editors.. They are fine for small sites that never change, but for a large corporate site that changes often, this kind of thing usually is better off being designed by hand by a programmer who is used to setting up their tests for the tester and having them actually go through the script. Dynamic content is fine, but not when interacting with a database.. Customizing the way something looks is entirely different to changing the way that it actually works..

I enjoyed reading this. Thanks for posting it.

Excellent Article!

I must say this is something I'd recomand to the programmer that I work closely at office. Most of our discussion goes on about him not giving me much control over how the GUI looks or feel.

OK I can understand that certain object are generated dynamicly but so what... even the most complex component have a presentation layer, where by it can be modified to fit into the theme of the entire project/product/site.

The way I see it, if the customer (end user) does not feel happy/welcomed by the look and feel chances are they'd not even bother doing business.

I am sure many of you out there when you see a page with bad colour contrast and really bad mapping of web site get really put off to even consider looking deep into the site.

First impression is the last impression in todays world of ecommerce and Internet business.

Very Nice Article!

I' am not whats considered a senior developer, but i always took the time to analize my code. WSIWYG editors can be an advantage to aid developers in getting code on paper, but a developer should always triple check the output. Everything in an application, whether code or presentation should sync up. Its the job of the developers to understand WSIWYG editors are not there to program but to AID! them in programming. They dont make it easier because the extra "checking" makes it just as tedious (if not more) as hand doing it.

Ranting to the Coders Won't Work

The sins of testability, like most software sins, are sins of specification.

You must make an offer to your project managers. Offer to speed up testing and the whole development process. Explain you'll need a seat at the table when specifying the code.

A seat at the table could mean in a board room at the beginnng, or it could mean sitting in on a coders meeting where they don't usually allow testers. Organizations vary.

Most orgs have a "Big meeting" at the beginning where they "Design the user interface". At least they all get together and decide on command line versus VB program vs intranet. This is the time to bring up testability. For each user interface screen, define the the stuff you need. In some orgs, you'll need to hand out a piece of paper with field names ("BrandNameEditBox17"). In others, all you can get is a verbal promise that you'll get an email back from the devs with the names they promise to stick to. The best way is to persuade devs is to outline the problem so that there is just one obvious solution.

Since your project is underway, talk to your manager, the project manager, the program manager, or the product manager (orgs do vary) and set up a meeting with the devs and one or more of these managers to "Streamline testability". If the meeting doesn't happen you escalate to the manager above and say you'll need that meeting to "Jumpstart testing".

Make sure your testability needs get onto the managers chart (milestones, pert chart, MS Project, whatever he/she/it uses) as a thing that has to be done.

With devs, it's best to ask for "Help" in solving tough testability problems so they think they're geniuses for inventing the idea of keeping the name the same. Or whatever.

Point out that in order to properly document the fields (for example) the same sort of consistency will be needed so that the documentation will be correct. Whether to point this out as a deep insight or to mention it sweetly in passing I leave to you.

Some test tools have automatic GUI run throughs you can perform once and then the test is "automatically" repeatable. The program results are however not included in these babies, so be prepared to point that out when they bring that up. One good technique is to make sure the devs are have a copy of the test tool so they themselves can use it. After you teach them to use it a few times you may be lucky and they'll start using it themselves to speed up development. This would be a great boon to the test department. Explain this idea to your bosses so they think it's their idea. The issue of tool cost will come up. Think of a strategy.

I've been a dev for a couple of decades now and I've had the chance to build some test code and learned about test automation. The great weakness of test automation is that when the product changes the test code is obsoleted and must be thrown in the trash.

The big movement in programming these days (aside from finding a job) is XP. XP is a programming system that involves having the devs code/test/code/test in smaller and smaller chunks. Wiggle yourself into this process. If the testers and the coders are using some of the same tools, dealing with new releases will be easier.

For those that don't know, XP means "extreme programming" (who comes up with these names!? :P). It is a another programming methodolgy. Read more about it here: http://www.extremeprogramming.org/

Although I think this might be a bit beyond the needs of this forum, I'm surprised no-one has mentioned processes like UML, which allow for better execution of software development from the initial planning stages.

I guess it hasn't been mentioned because a lot of guys here are self-taught, which means you're less likely to find out about these processes, until you've either been in the industry for 5-10 years, or you do a programming diploma/degree. Although processes like XP, RAD, JIT, etc are more aimed @ your enterprise level systems, they're something everyone should at least know something about as it will enable you to more easily deliver systems in a more efficient manner. Check out your local PC bookstore, as there are entire books devoted to these programming methodologies.