Wind River Blog Network

Test Automation Meets Simulation

By Paul Henderson

I'm seeing increasing interest from many companies in using simulation environments with test automation systems to accelerate the testing process. Specifically, putting Wind River Test Management together with Wind River Simics is getting creative juices flowing in industry thought leaders.

Why? Well, development teams have started to realize the benefits of simulation systems for speeding and validating system and software design, and for accelerating software development and debug in advance of hardware availabilty. And even when hardware is available, systems like Simics provide tremendous access and control to speed analysis and diagnsotics.

Continue Reading >>

Wind River and IBM Attack Software Quality

By Paul Henderson

As I've mentioned before, we've been working with IBM Rational for some time around quality management automation. Both companies see the skyrocketing software content and architectural complexity in the embedded device market as creating a tipping point where companies will not be able to continue with business as usual.

Product development teams will need to take a more managed and automated approach to quality that spans across the lifecycle and access into the devices under test. This is particularly true in markets that require strict adherance to standards and compliance regulations.

We put together a joint whitepaper on this subject downloadable from here. And we are also having a joint web seminar next week on Tuesday Aug 31 at 2pm EDT. You can register for this event here.

Continue Reading >>

Test Driven Development Meets Continuous Integration

By Paul Henderson

In my last posting I mentioned I'd be running a webinar with James Grenning on Agile testing. James is a recognized expert and frequent speaker on the topic of software development and one of the original authors of the Manifesto for Agile Software Development.

We talked about the case for agility where today's embedded software projects are inevitably faced with changing requirements and market conditions that cause unplanned, mid-course corrections. The result is what went in is often not what was expected to come out. Testing folks are the tail trying to wag the dog as they try to test in quality at the end of the project.

Continue Reading >>

Industry Investing in Better Device Runtime Visibility During Testing

By Paul Henderson

Here’s the final installment in my series about our embedded device software industry testing survey conducted in April-May 2010 with almost 900 respondents (see previous blog postings).  If you’d like a copy of the full report in pdf, please drop me an email at paul.henderson@windriver.com and I will send it to you.

In this section of the survey we asked participants about what test tools they use today and where they are investing in test automation. Given the high cost of product failure, accelerating complexity and reduced schedules the industry is turning to more test automation in 2010 to help address these problems. The top investment are moving to new tools that can help test teams and their management better understand how well they are testing, better focus their efforts on the areas needing testing, and reduce cycle time through more automation.

Continue Reading >>

The High Cost of Poor Quality – Brand, Market, Budget

By Paul Henderson

I’m continuing my series on our embedded device industry software testing survey conducted in April-May 2010 with almost 900 respondents (see previous blog posting).  If you’d like a copy of the full report in pdf, please drop me an email at paul.henderson@windriver.com and I will send it to you.

In this section of the survey we asked participants about how they measure the high cost of poor quality. Respondents told us that the true cost of poor quality is much higher than program budget. The majority of respondents showed that the true cost of poor quality is measure by damage to company brand and lost revenue due to missed market windows.

Continue Reading >>

Inadequate Management Visibility into Quality is Eroding Confidence

By Paul Henderson

Here’s the next installment in my series on our embedded device software industry testing survey conducted in April-May 2010 with almost 900 respondents (see previous blog postings).  If you’d like a copy of the full report in pdf, please drop me an email at paul.henderson@windriver.com and I will send it to you.

In this section of the survey we asked participants about how they measure software quality today, the metrics most often cited by survey respondents were reactive in nature such as tracking customer-reported failures and open defects rather than metrics that can help them prevent defects.

Continue Reading >>

Compressed Schedules Driving Shorter Testing & Defect Resolution Requirements

By Paul Henderson

Today I'm continuing my series on our embedded device software industry testing survey conducted in April-May 2010 with almost 900 respondents (see previous blog posting).  If you’d like a copy of the full report in pdf, please drop me an email at paul.henderson@windriver.comand I will send it to you.

In part 2 of the survey we asked about schedule compression and what affect that was having on the device testing cycle. A majority of survey participants reported that market conditions have forced them to shorten their development schedules by as much as 18 months.

Continue Reading >>

What’s New in Wind River Test Management 3.3?

By Paul Henderson

Today we announced the latest version of Wind River Test Management, Release 3.3, our test automation system for monitoring, executing and managing embedded device software testing. Wind River Test Management lets teams optimally execute complex tests while dynamically gathering information from the production software under test as it is running, without requiring special pre-instrumented software builds. This approach allows teams to adopt new white-box test techniques that give testers visibility into the operation of the device and help them determine the thoroughness of the tests, quickly identify defects and performance bottlenecks, and focus efforts on sections of software that are most in need of testing.

Release 3.3 is a major new release that adds a number of significant new features. You can learn more and download several new whitepapers from www.windriver.com/products/test_management.

Continue Reading >>

Wind River @ IBM Rational Innovate 2010

By Paul Henderson

Today marked the opening of the annual IBM Rational Software developer conference, this year called Innovate 2010, here in Orlando Florida.

The 4 day event is covering a range of topics on both IT and embedded systems software development and test lifecycle tools and technologies. Wind River has a presence on the exhibit floor and a number of conference tracks. The mood is very positive at this 13th conference. 4000 attendees are here, a 20% growth over 2009.

The show opened with several IBM executives led by Dr. Danny Sabbah, GM IBM Rational Software reviewing IBM's "Smarter Planet" strategy including "systems and software econometrics". Dr. Sabbah described how software innovations are now driving the world, particularly as related to intelligent products and services.  

Continue Reading >>

Quit Bugging Me: Revalidated

By Mike Deliman

One day, I get this phone call. "We're working with the system, we see the calls that update the exception handlers early on - connecting the clock routines, etc. Then not very much farther on we see the system has run past where tasking should be running but it's not. 

When we check, we're not getting any clock interrupts, and the clock exception handler isn't there any more. How could the system do that? Is there any way the OS could remove it's clock connections?"

Continue Reading >>

Quit bugging me: surprise NaN!

By Mike Deliman

You've got a complex system. There are dozens of tasks, a handful of interrupt routines. Your system runs fine, for hours or sometimes days on end. The loading on your system is somewhat "bursty" in that average loading is only about 20% of peak load, and peaks only happen once every hour for less than 5 seconds. Every once in a while, for whatever reason, you suddenly get a divide by zero, not-a-number, or other unanticipated erroneous results on one of your floating point calculations.

In your system you only have a few tasks that employ floating point. You're pretty sure none of your ISRs do, all they do is copy or move data around, they shouldn't have to compute anything. Yet for some reason, occasionally any one of the tasks running floating point will go belly-up with unexplainable results. It just looks like some kind of random corruption.

Continue Reading ››

Targeting Your Assets

By Paul Henderson

Embedded folks know that managing your target device is a key part of the development process. While you can do a lot on the host, the 'rubber meets the road' when you run your software on the actual target hardware at full speed.

Developers using IDE's like Wind River Workbench have a nice target management environment that fully supports cross development. But testers don't have this luxury. In testing, the whole process of managing devices is slow and painful.

Most companies have a lab full of equipment covering new and old devices of all configurations. Often with new devices, the prototype hardware needed by the team is scarce and expensive. Plus, these labs are spread across the world -- Americas, Europe, China, India.... How do you know where the equipment is, and how do you get access to the device or board you need remotely - now?

Continue Reading ››

Tolerating Delays

By Mike Deliman

This may sound a bit funny, but in the space industry, we're constantly playing catch-up.  We're either looking at or for things that happened millions or hundreds of millions of years ago, sending rockets off to get to where something will have been just in time to take a picture of or bore a hole into it, or designing new rockets for flight 5 years from now with computer bits that would have been considered top-of-the-line 5 or 10 years ago.  When we're recovering data and sending commands from and to deep space probes, we point our antennae to where the probe is supposed to be 30 minutes from now and start sending our data now; the idea is by the time the data actually gets there the craft will be where it was expected and receive the commands, and send it's data back to us.

This process I just described - of anticipating where a craft is, transmitting before it's there - and it transmitting back - is pretty much how the Deep Space network is currently used.  It takes huge amounts of planning, all done in advance, to set up the multiple sessions that allow one successful exchange like that to work out.  People consult tables of times when craft will be "visible", consult tables of one-way light distances to find transmission times.  When they think they know when they need time, and how much data they expect to exchange (how much  time they need),  they contact the folks who run the big antennas.  if the time slot is available, arrangements are made, and that one set of transmissions can take place.  The folks who run the Deep Space Network and their customers do this sort of thing all the time - it's how they try to make the most efficient use of their giant antennae.

Continue Reading ››

RDC in China

By Tomas Evensen

I just came back from a couple of weeks in China. Fascinating country. Besides the usual customer visits, we also held three Regional Development Conferences (RDCs) in Shenzhen, Shanghai and Beijing.

The RDCs were a huge success with on average more than 400 attendees per day. And they were all very interested in hearing about Wind River's latest offerings and future plans.

How do I know they all were interested? Well, my leading indicator was that all seats were taken from the front working towards the back. Somewhat different from your typical American or European conference, where the back seats seem to be the hottest commodity. (BTW, I am of course not indicating that our American and European friends are not interested... Perhaps they have better eye sight).

Continue Reading ››

Mitigating Risk

By Mike Deliman

The phone rings.  A customer has an application destined for a high-risk environment, and somewhere in test they've found a new unanticipated condition.  A "Tiger Team" is formed - a group of experts who've "been here before", who understand the priority and the risks, and know how serious it is. Many times a Tiger Team may give the go / no-go, the final answer that either saves a mission, or drops all that work into the dust-bin.  Such a team itself represents a *lot* of work, frustration, and time - investigations may run on days, weeks, or months, as long as they reach their conclusion on-time.  And there's the one facet that can't be changed by any engineering practice:  Time.

Continue Reading ››

Reporting Exceptions in QA

By Bulent Kasman

I now have a habit of asking for the Exception Detection and Reporting (ED&R) log as a minimum, and the core file if available, whenever QA observes exceptions during testing. If you are not a VxWorks 6.x user, ED&R log is like a signature of a core dump. It briefly describes the exception by providing the address of the crash, stack backtrace, register values, and even a disassembly of the surrounding code. Core file lets one use Wind River Workbench debugger and other host tools, like the host shell if you like to use command line to dump memory and see tasks at the time of exception. In many cases this all I need to pinpoint the root cause, and fix the defect.

Alternative used to be rather painful, time consuming, and much less deterministic. It preempts what I was doing, so that I can setup my environment to recreate the same crash scenario based on the description of the eye-witness (i.e. the tester). If the bug is obvious enough this method works, of course. But, what if I can't reproduce the crash? Was it a faulty setup in the QA lab or was it some rare race condition that caused the exception? And, if I do reproduce the crash, the first thing I'll probably do is to look at it using a debugger, which is what the core file gives me to start with.

Continue Reading ››