QA&TEST Blog

Results from Byte Paradigm’s 2009 and 2010 surveys show that embedded systems engineers widely recognize prototyping as an efficient methodology to speed up embedded system debug, no matter the type of embedded system or its maximum speed.
In the constant quest to achieve shrinking time-to-market, reducing the time spent on a prominent task such as debugging is undoubtedly of great value. Prototyping does help shorten the overall design cycle time and boost the engineer’s productivity.

Innovative, flexible and powerful digital pattern generators are one of the key elements to speed up embedded system debug on prototype. innovation in PC instrumentation can lead to boosting the designer’s productivity and help design better and faster.

Click here to continue reading this article at Embedded Computing Desing

Non-destructive internal inspection of MEMS bonded wafer pairs via acoustic micro imaging is useful in finding, characterizing and eliminating anomalies and defects.
During product development, acoustic inspection is helpful is modifying processes to avoid defects. During production, acoustic inspection spots rejects and identifies process drift.

The ultrasonic transducer that scans the wafer pair pulses UHF ultrasound into the top surface and receives the return echoes. Pulse-echo occurs thousands of times per second as the transducer moves across the surface. Each scanned x-y coordinate yields one pixel in the acoustic image which, in the high resolution typically used for MEMS wafers, consists of millions of pixels.
Click here to continue reading this article at Embedded.com

Some test teams may be stumped on how to transition to agile. If you’re in such a team, you probably have manual tests for regression either because you never have had the time to automate them or because you are testing from the GUI and it doesn’t make sense to automate them. You probably have great exploratory testers who can find problems inside complex applications, yet they tend not to automate their testing and need a final product before they start testing. How do you make it work? How do you keep up with development?

This is a common problem. In many organizations, developers think they have transitioned to agile while testers are still stuck in manual testing efforts and unable to “keep up” at the end of the iteration. The problem isn’t that the testers are too slow but that the team does not own “done,” and, until the team owns “done” and works together to achieve it, the testers will appear too slow.

Click here to read this article at Sticky Minds. 

Agile methods are described as software development methods. Most introductory material, like the Agile Manifesto, describe how agile teams are organized and act but don’t describe some of the things that happen outside the development teams.

When your teams start using new methods, they will act in a drastically different way from the norm, especially in an organization that has not otherwise changed. There is bound to be some conflict.  When you bump into existing processes or rules that seem to get in the way of your agile teams, you will have an important choice to make: ignore the rule, follow the rule, or try to change it.
Click here to continue reading this article at Sticky Minds.

Unit Test has been around almost as long as software development itself. It just makes sense to take each application building block, build it in isolation, and execute it with test data to make sure that it does just what it should do without any confusing input from the remainder of the application.

In the past, the sting came from not being able to simply lift a software unit from its development environment, compile and run it ” let alone supply it with test data.
For that to happen, you need a harness program acting as a holding mechanism that calls the unit, details any included files, “stubs” written to handle any procedure calls by the unit, and offers any initialization sequences which prepare data structures for the unit under test to act upon.

Click here to continue reading this article at Embedded.com

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

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.