QA&TEST Blog

Virtualization is a long established technology in the server world. It has been used for decades as an enabler for platform consolidation. In the recent years, the technology has also gained new public interest due to its availability for Desktop PC platforms. The fact that it can provide strong isolation between applications and that this level of isolation can be achieved with only a very small layer of trusted code has also raised interest from the security related field of applications.

The possibility to integrate multiple independent subsystems in a single physical machine could also prove beneficial for many safety-critical applications.However, in addition to the spatial isolation that virtualization readily provides, most of these applications also require some level of temporal determinism: Each subsystem typically interacts with a technical component and, consequently, it has to keep up with that component’s timing properties.

Click here to continue reading this article at Embedded Control Europe.

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

One of the challenges in real time systems, especially in multitasking OS based implementations, is defect fixing. To resolve the defect one has to be aware of the program flow during the defect or faulty condition. Normally, this is done by using in-circuit emulators (ICE) along with the break point feature available in the environment of the emulator.
However, the ICE support may not always be available for the system under consideration. Considering the case that ICE is available for the system under consideration, and the ICE hits a breakpoint, then the dynamics of the system is lost.
All the interactions the system was having with some networks or other systems/modules are stopped at once. Therefore it again may be difficult to reproduce the defect or anomaly exactly. Though some makes of ICE provides a feature of real-time trace function, but that is also limited by the ICE memory.
At times it is required to stop the system in some logical trigger, so that the condition of the system can be analyzed at that point. This feature is also not common in normal debugging systems.

Click here if you want to read the whole article at Embedded.com.

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

Despite virtualization‘s obvious appeal to embedded software developers and OEMs, adoption of the technology may stall due to inherent limitations in virtualization platform architecture. Here is a look at the limitations and how they can be overcome by a different approach to building embedded virtualization software.
Over the last five years virtualization has evolved from an obscure technology to become a key enabler of enterprise server and desktop applications. More recently, virtualization has begun to play a comparable pivotal role in embedded development and deployment.
If you want to continue reading Gernot Heiser’s article at Embedded.com, click here.

The highlight of a Danish company dedicated to software testing is that has a 75% of autistic people at its workforce. Thorkil Sonne, the founder, became interested in integrate autistic people in the working world in 2004, when his son was diagnosed with Asperger Syndrome (a type of autism that seriously affects the way of relating). Sonne found out that only 6% of the autistic population is integrated into the labour market, and realized that the characteristics of the perfect software tester were the same skills showed by his son: having a good memory, follow instructions carefully, be persistent, note any deviation from the expected results… These are the characteristics of autism.

Currently, 50 people are working in this company, and they remain faithful to this same philosophy: providing future opportunities through integration.

As a tester or test manager, do you have an essential set of tools you take with you to new projects? Whenever I join a project I take with me the collection of low-tech tools I’ve designed and assembled to help me manage testing. It’s tremendously useful to have at hand templates, spreadsheets, and practices that have worked for me in the past, to remind me of what’s important and to get a head start on the work. Even when my client has standardized deliverables, I treat my own tools as checklists to supplement their templates, if necessary, with information I consider essential.

I call this collection my Test Manager’s Vade Mecum, from a Latin phrase whose literal meaning is “go with me.”
If you want to continue reading Fiona Charles’ article at Stickyminds.com, please, click here.

One certainty in this business is watching the pendulum swing. One year, hardware gets most of the attention; the next year, software takes center stage. After a period of deafening buzz about multicore processing, the next swing seems to be heading back in the direction of software as the battlefield for competitive advantage.
It’s logical that an increase in hardware complexity and capability would be followed by attempts to get software caught up and, judging from recent announcements, that appears to be the case. Designers don’t want to spend time optimizing code to run on multiple cores, so they have looked for new tools to optimize software for execution on multiple cores and processors, like OpenMP o Codeplay Sieve C++ Parallel Processing System.
If you want to continue reading Don Dingee’s whole article at Embedded Computer Design, 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