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.

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

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.