I should likely wait for the next issue to come out on Saturday before doing this, but the 4 issues I haven’t processed yet are bugging me…

April 2009

  • CERT C Secure Coding Standard – Never heard of this before. Warning flags waving at the notion of a ‘coding standard’ and then the inclusion of ‘Rules’. What happens if you are exploited, but followed the rules? Do you get to sue CERT? Oh, and of course they only apply to C. Would be much more useful if they made them generic for all languages. What about languages that aren’t C, but are implemented in C? Wow I’m a cynic.
  • Dynamic Taint Propogation – Dynamic solution that tags and tracks user input at runtime and prevents its improper use to maliciously affect the execution of the program of safe code are enforced by a combination of static (e.g. bytecode verification) and dynamic (e.g. array bounds checks). DTP does not rely on fault injection and does not disrupt the normal behavior of the application. For this reason, it does not require any effort beyond standard functional testing (Don’t think I had heard of this one either.)

May 2009

  • YUI Test – YUI Test is a testing framework for browser-based JavaScript solutions. Using YUI Test, you can easily add unit testing to your JavaScript solutions. While not a direct port from any specific xUnit framework, YUI Test does derive some characteristics from nUnit and JUnit.
  • Ross Collard has an excellent article (first in a series) on Test Patterns. Its available behind the ST&P pay/registration-wall (seriously, you give away full subscriptions, why hide individual articles?). I’d like to see all these somewhere on a wiki, but until then, I’ve tucked this list away for later. I might spend the hour or so to make them more consumable at a later point.

June 2009

  • ‘What I really wanted to do was to marshal the set of tools available to me to take the set of test cases, assign each test case to one of several queues, then to run each queue simultaneously on a number of virtual machines.’ – From Chris McMahon’s article on building out build systems. Build systems are one of my favorite rabbit holes.
  • Ross concludes his Pattern discussion with another big list of them. Seriously, these should be on a wiki somewhere.
  • Elfriede Dustin and Bernie Gauf talk about hiring our an automation team. It assumes a certain type of organization, which for me, wasn’t very useful, but their list of ‘other’ attributes for automation team members is food for thought.
    • Be quick learners who enjoy performing a variety of tasks, learning new things, and touching many different products
    • Have an aptitude for conceptualizing complex activities
    • Understand complex test requirements, be able to formulate test planning and design approaches to support requirements and be able to perform multiple tasks concurrently
    • Be able to develop work-around solutions to problems encountered during test development and execution
    • Be creative, with the ability to think of multiple ways to exercise a system or application to ensure that it works in all circumstances, and be able to identify all conditions under which the software or system could fail
    • Be diplomatic and discrete, especially when having to report major defects, and be able to work closely and effectively with a variety of stakeholders
    • Possess strong verbal, written, and grammatical skills, with the ability to communicate any issues and articulate ideas to the customer/stakeholders
    • Be detail-oriented and able to identify difficult-to-find glitches, and have a strong interest in improving the quality of a software product, including being self-motivated and trying to find all defects possible
    • Be process-oriented and skilled in the ability to understand inputs, logical sequences of steps, and expected outputs

  • The Perception vs. Reality article is about process improvement an seemed to be focused on big-P process improvement. The kind that come under the guise of BPM and other such buzzwords. But this paragraph was good.

    Although often not explicitly recognized, implicit in generic process improvement is the need to identify and improve the REAL process. Many (and probably most) generic and branded process improvement efforts fail because they don’t properly understand what a process is and therefore don’t identify the real process that needs improvement.

July 2009

  • The only thing that was new to me was the WS-I which gives testers a world of resources to help increase confidence in the interoperability of their Web services beyond the scope of commercial testing tools. Oh ya! Another WS* alphabet soup organization. Do we really need such a group? Web Services are client specific and even there, context specific. Guess what? You are going to have to do custom mapping between multiple ones. Would it be easier to do this mapping if they all adhered to a specific standard designed to address this? Sure. But by doing it, are you creating more work for the development team? And the test team? And is that work worth the Opportunity Cost that it represents?