QA&TEST Blog

The question “what is embedded?” continues to plague many of us, even those who are deep in the throes of the technology. It’s sometimes easier to make a point using a negative. For example, could you imagine a world without embedded technology.  Probably not. If that were the case, we’d be without computers, vehicles as we know them today, any type of aircraf, cell phones, the Internet…
In fact, most of our industries would not be doing business the way they do it today without embedded technologies. And yet, a vast majority of the general population will have a perplexed look on their face when you ask them “what is embedded?”

Click here to continue reading this article at Embedded.com

Virtualization, a concept of the mainframe computing and business IT world, is no longer a technology restricted to large computing centers and business computing environments. Increasingly confronted with the requirement to communicate with business IT and to integrate complex processing environments, programmers and developers of embedded systems increasingly rely on virtualization techniques.

Click here to continue reading this article at Embedded Europe.

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. Project teams can make a difference by adopting and implementing agile practices. When implemented correctly, agile practices greatly mitigate the most common risks associated with requirements on software development projects.

Click here to continue reading this article at Sticky Minds.

When a software developer is acquiring a compiler, a primary consideration is the code quality produced by the compiler. But other features that are not required by the ANSI language description (that are tailored to embedded developer needs) can make the developer’s task simpler to maintain.

Click here to continue reading this article at  Embedded Computing Desing about some desirable features of compilers used in embedded application development, and some techniques for making use of these features.

The topic of coding standards is an emotive one among software developers, whose divergent opinions raise questions that range from “Why do we need such restrictions?” to “How could we possibly operate without them?”
Software engineering has always wrestled with standards, and the development of the C and C++ languages brought the issue into even sharper focus. These flexible and powerful languages are now deeply rooted in industrial and embedded environments. In the past decade, developers have accepted the need to control and restrict these languages for industrial, commercial, or other safety-conscious purposes.

Click here to continue reading this article at Embedded.com

Have you heard any of these lately?
“The testers are finding too many bugs and holding up the project.”
“Anyone can test. We just have to give them the right process to follow.”
“Our test cases will provide complete system coverage.”
Not one of these common statements about testing is true. At least one of them could have been said by a tester.
Delivering and promoting accurate communications about testing is essential to the tester’s and test manager’s job. We have a responsibility to dispel myths and misconceptions about good testing and what it can and cannot do. We must also be alert to and prepared to address distortions or attempts to spin the message about testing from any source—including ourselves.

Click here to continue reading this article at Sticky Minds.

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.

Embedded systems are becoming increasingly important to today’s products. This, combined with shorter product development schedules, is driving a number of improvement initiatives for embedded systems.
From a business perspective, an embedded system offers a lot of opportunity. However, the process of developing these systems can be fraught with challenges. Unclear requirements, tight delivery dates, late availability of target hardware, and lack of visibility to system interactions just add to the complexity.
What can you do? Click here to continue readin this artcle at Embeded Now

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