Testing is an Engineering discipline

In fact, as I understand it, in many companies Testing is the department that imposes discipline on Development--which shouldn't be.  SW Development Engineers have a set of steps that they go through when developing an application/component/whatever, which is different than the steps that SW Test Engineers go through--but each have their purposes.  It is not Test's job to ensure that SW Development Engineers have gone through their steps properly; it is however, Test's job to ensure that the product of Development's efforts is something suitable for what it was intended for. Next, SW Test Engineers--please please pleeeeeeaaassseee take some accountability for your job title!!  Check out wikipedia's entry for Engineering:

Engineering is the discipline and profession of applying scientific knowledge and utilizing natural laws and physical resources in order to design and implement materials, structures, machines, devices, systems, and processes that realize a desired objective and meet specified criteria. More precisely, engineering can be defined as “the creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.”

Engineering - Wikipedia, the free encyclopedia ...and notice the word "discipline".  Development Engineers can (and should be) hounded for bad formatting and not commenting their code--along those same lines of being disciplined, let the rest of us know what you're trying to accomplish when writing your tests!  Be explicit about what you're trying to test for, show steps for how to test for that, and be concise about what to expect.  Just as a screwy, uncommented piece of code that someone else wrote can drive a Development Engineer nuts, a screwy test can have the same effect on your fellow Test Engineers.  Please, learn to be disciplined in your work--you'll gain respect from your co-workers and probably realize that you missed a few things along the way.  It's not hard--it just takes discipline!

US FDA/CDRH: General Principles of Software Validation; Final Guidance for Industry and FDA Staff

I ran across this link while looking for a specific page in my del.icio.us test links, and while the products that this document is geared towards are a little different than what I deal with on a daily basis, the concepts are great.  I particularly liked this section--especially the first sentence here--in the Verification & Validation section:

Software verification and validation are difficult because a developer cannot test forever, and it is hard to know how much evidence is enough. In large measure, software validation is a matter of developing a "level of confidence" that the device meets all requirements and user expectations for the software automated functions and features of the device. Measures such as defects found in specifications documents, estimates of defects remaining, testing coverage, and other techniques are all used to develop an acceptable level of confidence before shipping the product. The level of confidence, and therefore the level of software validation, verification, and testing effort needed, will vary depending upon the safety risk (hazard) posed by the automated functions of the device.

There's also a great section called "Software is Different From Hardware", which points out some great subtle-but-huge differences between the two. Section 5. Activities and Tasks has some good practical info on planning and test tasks--both Black Box and White Box (although not explicitly so). US FDA/CDRH: General Principles of Software Validation; Final Guidance for Industry and FDA Staff

Vista annoyance

I love how Vista just decides to reboot and apply some updates while I'm in the middle of writing an email.  No warnings, nothing.  Just shuts down as if I said "Shutdown and kill all my apps in the process"...  Nicely done M$.  I love it when my OS gives me the finger.

Apple's Characteristics of Great Software

A friend & coworker of mine sent me a link to Apple's Human Interface Guidelines, with the intent to give some insight in to testing the UI applications that I test for my job (thanks Mike). After stepping through a few pages in Part I, it clicked for me that a number of the "Characteristics of Great Software" that Apple lists are the same as some of ISO 9126's quality characteristics. After attending a CVBI meeting this morning where the topic of conversation was "building quality in to software products", I'm really encouraged to see Apple not only list these characteristics that it thinks are important, but back up why they think they're important. One of the things that was discussed implicitly in this morning's meeting was that in order to end up with better quality products, developers (and testers) need to be taught at some point what quality is and how to get there. Apple uses this doc to clearly communicate some ways to raise the quality, not just on Apple applications, but on all applications. Seeing this crossover between the quality characteristics that ISO setup and the ones that Apple setup really gives extra weight to these characteristics. Without having read too much in to the Apple doc yet, it looks like for the characteristics that Apple lists:

• 2 out of 7 (Ease of Use, Attractive Appearance) are related to ISO's Usability
• 1 out of 7 (Reliability) are related to ISO's Reliability
• 1 out of 7 (High Performance) are related to ISO's Efficiency
• 1 out of 7 (Interoperability) are related to ISO's Functionality
• 1 out of 7 (Adaptability) are related to ISO's Portability
• Mobility seems to be a hybrid of ISO's Usability, Functionality, and Efficiency

...interesting that in ISO terms, Apple is most heavily weighted on Usability...