Recently I was at our European partner advisory board.  This is a session where we all get together and talk about the current market, the upcoming release and anything else to help our partners be more successful.  The most valuable sessions for myself is hearing from the partners on what works and what doesn’t.  This ranges from commercial issues to technical issues with the product.

One very clear message from all the partners was that our MISRA support was a huge plus.  Here in North America we have seen small pockets of adoption, but in Europe and even Asia it used quite a bit.  As we have mentioned in the past, it is not only automotive organization but all levels of business.

Soon MISRA C 2011 will be released.  Look forward to seeing all the changes especially with the added support of C99.

I read an interesting post on electronic imports that could contain security threats.  I can only speak from the software perspective, but I can say that most customers I’ve dealt with usually integrate some sort of software security audit process with any 3^rd-party integrator and from my experience that means adopting static analysis.  How many organizations are there that haven’t jumped on board with static analysis?  Probably more than I can count.

It would be very interesting to hear of some of the Armed Services and Intelligence cyber threats that the government has not publically disclosed.  That might be an eye opener.

Michail the friendly, programming vampire.

Instead of fomenting dissent (that barely exists) in a brazen attempt to boost readership, I’m changing tactics to look at ways in which testing and development are complementary, beyond their common goal of releasing quality software products.

What can I say? After my previous post, How developers drive testers nuts–let’s count the ways, I’m clearly getting less edgy.

I approached our newest addition to the Klocwork development team, Michail Greshishchev. While he’s a new full-timer, Greshishchev is not a new face around here.

The recent Carleton University engineering graduate did two co-op terms here–one in professional services and the other in testing.

So I asked Greshishchev how his stint in testing affected his development. Here’s exactly what he said:

1. Writing short, efficient unit tests comes naturally after dealing with mammoth testing frameworks. Most of the code I write are tests – the techniques and skills I’ve learned in testing are fully applicable to development.
2. Developers have no idea how to execute a test in our automated test system (I don’t blame them–the test machine is a large, well-oiled beast distributed over dozens of operating environments). Having the knowledge to run test team tests on developer builds means I don’t need to wait for nightly build test results to address issues. More importantly, I can add my own tests to the test team’s automated test system.
3. It’s common for a developer to request more information about a tester’s problem report. My experience with the test team allows me to access the information on test machines myself, saving time for everyone.
4. The test report pages actually make sense. This allows me to investigate test failures in the nightly build before a tester comes to my desk to tell me I broke something.

His experience as part of the test team has been win-win for him and his colleagues. Testing and development sound like allies, don’t they? Well, as much as werewolves and vampires can be allies, I suppose. And he was such a nice guy too, but the change is upon him.

The U.S. Department of Homeland Security, in conjunction with the SANS Institute and Mitre have been hard at work again.  See the article.  There are two new programs called the Common Weakness Risk Analysis Framework (CWRAF) and the Common Weakness Scoring System (CWSS).  Using these two in conjunction will help users identify the most important weaknesses for their business.  It will be interesting to see adoption in the upcoming weeks.

In addition to CWRAF and CWSS the 2011 CWE/SANS Top 25 list has been updated.  There has been a number of position changes and a few that have been knocked out and replaced by CWE-250, CWE-676, CWE-134, and CWE-759.  Not too many surprises but I never really noticed CWE-134 not in the list before.  That certainly makes sense.  However it does shock me that CWE-129 (Improper Validation of Array Index) didn’t make the list this year.  Certainly a problem that I’ve seen a ton, although it was close (#27).  To see Klocwork’s coverage of 2011 CWE/SANS Top 25 go here.