I’ve decided to start dating my ‘Random Article’ posts as they are going to become more and more regular I think. Today’s are mostly from the current issue of IEEE Software which I cannot directly link to as it is payware. But if you really, really want a copy… 🙂

Software Testing and Industry Needs
Five Testing “experts” answer Does the practice of software testing effectively meet industry needs?

  1. Robert L. Glass
    • … there might be a common general understanding of what testing is, but practices vary across companies
  2. Ross Collard
    • Most people enter the field accidentally. I know I did. See this post for a mini-rant on what could be done about this
    • Test jobs are often consolation prizes for those not considered good enough to hire as software engineers… If thats how you hire testers, then your Quality is not going to be anywhere near its potential.
    • … and the salary gap between developers and testers remains significant. Heck, even between testers and product support in some organizations
    • Career development is more haphazard than strategic. Unless you take control of your career. I guess this comment flows out of the consolation prize point made above.
    • Most testers are self-taught. I don’t think I’ve seen an Introduction to Software Testing course in any of the local universities, but even if there was …
    • No universally agreed-on terminology or testing body of knowledge
    • Many testers love their work and wouldn’t trade their careers for anything. Except maybe a career in software liability law. Oh wait, that also is about Quality of software…
    • … testers have unusually strong opportunities to contribute to a society that increasingly depends on reliable software
    • Effective testing is a quest …
    • Rewards for the best 20 percent of testers typically include exponential career growth, substantial monetary compensation and wide influence.
  3. [James Bach](http://www.iei.pi.cnr.it/~antonia/Antonia Bertolino</a></li>
  4. <a href=>)
    • A skill that all people who strive to be great testers should develop is better known as ‘general systems analysis’ or ‘general systems thinking’
  5. Cem Kaner (that site is horribly out of date)
    • … programmers’ productivity accelerates relentlessly faster than testers’, threatening to render testing irrelevant because the productivity gap means testers impact proportionally less code each year.
    • … evolution from quality control to quality assistance
    • … software testing is an empirical investigation, conducted to provide stakeholders with quality information about the product or service under test
    • The purpose of testing during development is to help … stakeholders understand what they’re getting, in time to correct weak programming practice or (re)negotiate the design.
    • … testers are measured by their skill as investigators and communicators and by the tools they can create and use to support their investigations — not by the level of control over the product’s code or design.

Static Code Analysis

  • Research tells us that code reviews are probably the best way to eliminate bugs
  • Unfortunately (that) takes a lot of time … therefore (it is) impossible to use … on a project’s complete code base.
  • Most errors fall into known categories, as most people tend to fall into the same traps repeatedly.
  • It is exactly the predictability of people’s fallibility that gives tools … a chance
  • FindBugs
  • Static code checkers for Java come in two flavors
    1. Works on source code: slow, but checking mirrors the exact program code written by the programmer
    2. Works on byte code: much faster, but compilers might be doing some funky optimization
  • The percentage of false to true positives is an important indicator of a code checker’s suitability …
  • Checkstyle
  • PMD
  • Klockwork K7

Designing for Recovery

  • James Shore’s Fail Fast argues that careful use of assertions allows for early and visible failure, so you can quickly identify and correct problems
  • Most software needs to keep working in spite of many anticipated glitches
  • How gracefully (software) reacts and responds to anticipated exceptional cases is a measure of its quality
  • Failing fast will not be your first choice when
    • a connection is intermittent
    • a resource isn’t currently available (but could be very soon)
    • an external system doesn’t respond
  • Other options
    • Ignore the request … when there aren’t any serious consequences and when it won’t compromise requirements
    • Raise and exception … only in the case of an emergency
    • Resign … instead of blowing bits all over the screen, free up resources used, etc then go *POP*. Think of this as the graceful fast failure.
    • Retry … when the failure was likely caused by a temporary condition. Base retry strategies on reasoning, logic and a deeper understanding of the design
    • Involve humans … as a last ditch effort, put something into an error queue and notify a human to deal with it

Unit Tests Reloaded: Parameterized Unit Testing with Symbolic Execution

  • In many projects at Microsoft, developers have written more lines of code for unit tests than for the implementation they are testing. They say this like its a Bad Thing
  • Wolfram Schulte‘s Microsoft Reaseach page
  • There is also a whole bunch of programmy stuff in the article that rapidly went over my head and/or interest

Agile Software Testing in a Large-Scale Project

  • Agile practices require full integration of testing and development …
  • … fully adopting agile quality practices is slower and more difficult than adopting aglie programmer-oriented practices …
  • Kent Beck’s Cost of Change Curve
  • … testing (is) part of each team member’s work, and a key measure of both team and personal productivity.
  • … because people knew tehy were required to test their specifications and code, they designed them for testibility.
  • … test size is more highly correlated with complexity than are lines of code or specifications …
  • … only features that have full regression testing at each iteration are counted as delivered …
  • … tasks lacking full written tests are incomplete …
  • … professional testers add value not through more testing, but by writing some of the developers’ tests, thus freeing them to code more new features. Ummmmm, nope, don’t agree with this one.
  • Dealing with testing bottlenecks is relatively straightforward: developers simply code less and test more.
  • Testing and coding time are usually equal …
  • Defect flow in Agile projects
    • Anyone can open a defect
    • Anyone can close a defect
    • Anyone who finds a defect, also assigns it to someone to fix
  • … fix every defect as soon as you discover it
  • … devote the beginning of each iteration to fixing the previous iteration’s open defects
  • No concept of defect severity. If it is a defect, fix it. Deja-vu

Behind the Glass Curtain

  • It’s designed almost as a living environment—it’s much more like being at a university than being in a conventional work environment. Is this really such a Good Thing? Maybe in the short term, but in the long term?