It seems obvious that automation will affect the test organization. Less obvious—but no less real—is that it will also affect the development organization. In fact, when you choose to automate the testing for an application, your relationship with development changes completely.

Think about it. Manual testers only have to be able to interact with the application using the screen, keyboard, and mouse or other device. Automated test tools, on the other hand, have to interact with the software at a deeper level, thus exposing the inner workings of the code and perhaps uncovering problems that prevent or complicate automation. If you’re not careful, developers might think you have suddenly transformed into an interfering busybody who is sticking your nose into their business.

This shift in your relationship with development can be handled in a bad way or a good way.

Click here to read this article at Sticky Minds.

It’s been said for every measure, there’s a countermeasure, and that’s also true for securing code in embedded systems. Sometimes a small device can be just the countermeasure needed to thwart cloning of flash contents.

Many systems use external standard flash memory chip(s) to store the operating program for processors that do not include embedded nonvolatile program storage. This is great because it allows easy flash memory expansion and software modification, perhaps in the manufacturing line as a customer download or during a maintenance operation. The downside is that the OEM loses control over the contents of the flash, potentially allowing unauthorized copies or modification.

Click here to continue reading this article at Embedded Computing Design.

Teams who perform unit testing on a regular basis are perceived to be more reliable, professional and advanced. But what do you need to consider before choosing a unit testing solution?

We have developed the ‘8 commandments’ below as a guide for ensuring you select a unit testing solution that is right for your development.

1. Thou shalt not waste time on the learning curve
When choosing a unit testing solution, you will want one that will require minimal time for implementation. It may be worthwhile to time a new developer within your team with the framework to get an accurate idea of how long it takes to get started. For example – how long will it take them to write the first three tests for some class in your system? Is the API clear and simple? Is there a single point of entry in the API? Is there clear guidance on what to do at each step of the way? How often, if at all, do you need to check the docs and tutorials? How easy is it to look for the next step when you’re not sure what to do? Some tools offer guidance within the IDE, while some provide extensive help. Some don’t do either.

Click here to continue reading this article at EE Times Embedded.

A good idea is a valuable asset, and a lot of good ideas can be like a treasure trove. But what do you do with those ideas?  Many ideas wither, not because they are bad ideas, but because of clumsy presentation. Most nascent ideas stand a better chance if you remember these four things:

1. It’s not about you.
Most of the time, people pursue a new idea because they can see how it will help them. Don’t just tell them why you think your idea is a good one. See the world from their point of view, and frame the idea in terms of what matters to them. If your manager cares only about cost, then talking about quality, speed, reuse, or elegance won’t convince him to try your idea. Connect your idea with what’s important to the people you are hoping to influence.

2. It is about who you know.
Bringing your ideas to fruition is a social process. You will need the aid and interest of others to make your idea reality.

Click here to continue reading this article at Sticky Minds.

By best estimates, the software development effort behind 90 nm chip designs has already surpassed the hardware development effort. The projection for 2011 is that less than 40 percent of the overall chip development cost will be spent on hardware. Software now dominates project cycles and determines when a chip can get into volume production. As a result, the importance of software verification has increased, and software has taken on an integral role in the hardware verification process.

Click here to continue reading this article at Embedded Computing Design.

Ask an engineer what he is doing and there is a good chance his answer will be, “I am debugging.” Day in and day out, project after project, engineers debug — it’s part of being an engineer. Sometimes, it’s quick and easy, but sometimes it’s hard, not obvious, time consuming, and unpredictable. Everyone knows that debugging is a dreaded but necessary part of the design and verification process.
One alarming trend that is not necessary is the increasing proportion that debugging consumes in the design cycle. Within functional verification, it is the single largest component at approximately 60 percent and is projected to grow even larger. Broadly speaking, the reason for this trend is that traditional debug practices are not adequate for today’s problems.
Sooner or later, debug will get your attention.

Click here to continue reading this article at Embedded.com

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.