QA&TEST Blog

Considering how much information is available in log files, you’d think companies would pay more attention to them. Client computers, servers, firewalls, network devices, and other appliances generate reams of event logs every day, but these logs often go ignored.
Although it’s a security sin, it’s understandable on many levels. First, logs can contain vast amounts of uninteresting events. In fact, most logs are nothing but noise. With the rare exception, most logs are close to useless. At one current client, 1,000 computers and one perimeter firewall generate 25GB of log files on a daily basis. Out of that, in a typical week, not a single event is a true security issue requiring an immediate response. Oh, security events do happen, but when they do, they are normally buried in a sea of unimportant noise.
Click here to continue reading this article at InfoWorld.

Even though every new system rollout is, hopefully, accompanied by rigorous training and thorough documentation, it is obsolete by the next release or new hire. Most business-critical software (as opposed to desktop productivity tools like word processors and spreadsheets) exists in a constant state of change as the business adapts its technology to fluid competitive and customer demands.

Unfortunately, training classes usually can’t be justified for only one or two new features or new hires at a time, and pressure on delivery schedules doesn’t always allow for updating documentation and training materials. So, training becomes organic: Carla trains Darla, and by the time you get to Marla variances have crept in. It’s like the telephone game. The result, of course, is the very unpredictability that ends up distorting the test process.
But what if, instead of documenting the processes and training the users, we automated the processes that the users should follow? In other words, what if we trained the software, not the person?

Click here to continue reading this article at Sticky Minds

System design with open-source software has many advantages. Most notably among them is that development organizations can build systems faster, more flexibly, and more economically by tapping into this vast, free resource .
In this economy, it’s difficult to conceive of a scenario where anyone would start a development project with the plan to write it entirely from scratch. Numerous examples of open-source components including databases, kernels, stacks, report generators, XML parsers, utilities, tools, and platforms are available. They’re free and can easily be combined with other code to bring a system to market faster and more cost effectively. Developers can easily find code just using Google or by searching specialized sites for open-source code.

Click here to continue reading this article at Embedded.com

On the 11th of December 2008, the Consortium of the World Wide Web (W3C) published the second version of the Web Content Accessibility Guidelines (WCAG) 2.0.
This new standard will help designers and developers to create Web sites that consider the needs of elderly users and/or with disabilities. Based on the experience of the authors and the recommendations of the community of users, WCAG 2,0 updates the already excellent recommendations of the W3C to include new more exhaustive technologies and tests

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.

Know these recommendations

Increasingly in this modern world, we rely on systems where an error could cause financial disaster, organisational chaos, or in the worst case death. Software now plays a crucial role in these systems, but the disturbing fact is that the increasing use of embedded computers, controlling all sorts of devices, is moving us in the opposite direction.
Organisations like ‘Which?’ in the UK devote their energies to examining such devices. They test them thoroughly, but importantly they also examine and dismantle the devices to detect engineering defects, such as unsafe wiring. If they find a device unsafe it is rated as unacceptable and the public is protected against the dangerous device. But as soon as embedded computer systems are involved we have no such transparency. Cars, for example, are now full of computers and without access to the software details, there is no way to tell if these cars are ‘Unsafe at Any Speed’.

If you want to read Robert Dewar’s whole article at ESE Magazine, click here.

Code review checklists are usually a pain. They’re often ridiculous in length or content. They’re not fun to use. Checklists can be an excellent way of finding defects early in the development process, but most of the time, checklists are so impractical that they’re more of a hindrance than a help.
The problem is that people use the list as a general guide. They don’t consider every item in every file. Which items will they remember as they look at the code? Will it be the most important ones?

If you want to continue reading Jason Cohen’s article at Embedded.com, click here

People have been writing software for over 50 years, and building embedded systems for 30 years. The one constant over all of that time is that features increase while schedules shrink.
We’re trying to manage three conflicting things: an impossible schedule, an excess of desired features, and quality. Remove just one leg of the three, and the project becomes trivial. Can we ship with lots and lots of bugs? If so, getting it out on time is pretty easy. Can we neglect the ship date? With infinite time, we can get every feature working right.
If you want to continue reading Jack Ganssle’s whole article at Embedded.com, click here