Archive for the ‘Quality Assurance’ Category

More Reasons For Testing: Prevent The Morning-After Syndrome

March 11th, 2010

Testing (Test Driven Design, Unit Testing, Mocking) is a part of developer popular culture – most developers understand that by writing the tests first we’re forced to focus on the important details as we build software, that by writing tests we prove that our software works as we build it, and that by running our test suite against our changes we gain assurance that our code still works, but did you know that testing is also a cure for the ‘morning-after syndrome’?

The ‘morning-after syndrome’ as described by Uncle Bob (Robert C. Martin):

Have you ever worked all day, gotten some stuff working, and then gone home, only to arrive the next morning to find that your stuff no longer works? Why doesn’t it work? Because somebody stayed later than you and changed something you depended on! I call this ‘the morning-after syndrome’. – Robert C. Martin, Agile Principles, Patterns, and Practices in C#

Bob makes the point that by writing tests we make our code more stable and brittle to change, which prevents our coworkers from making casual breaking changes. Sure-sure, brittle tests are frustrating when refactoring, but at the same time these brittle tests accentuate the importance that the code under test should not be modified. Core components that your system depends on should be stable and brittle.

Bob continues:

Many factors make a software component difficult to change: its size, complexity, clarity, and so on. But we are going to ignore all those factors and focus on something different. One sure way to make a software component difficult to change is to make lots of other software components [like tests] depend on it. A component with lots of incoming dependencies is very stable, because it requires a great deal of work to reconcile any changes with all the dependent components. – Robert C. Martin, Agile Principles, Patterns, and Practices in C#

Author: Adam Kahtava Categories: Book, Quality Assurance, Testing Tags:

Fun with “Bugs Bugs Bugs, If I had them all in jugs”, Bugbears, Bohrbugs, Schroedinbugs

September 14th, 2009

Some software bug trivia.

Where did the term ‘bug’ originate?

According to Phil Factor:

The word ‘bug’ actually is short for Bugbear, sometimes found as Bugaboo. The meaning is much closer to ‘Gremlin’, where the people who worked on engineering prototypes often grew to suspect that the problems were due to malicious spooks. I sometimes still hear it said that a particular piece of software is cursed with malicious spirits. The ‘Bug’ or ‘Bogey’ part of the word is traceable back to the fifteenth century in the meaning of ‘Hobogoblin’, devil or ghost. … the word ‘Bugbear’, first recorded in the sixteenth century, is still used in referring to problems with machinery. – Confessions of an IT Manager, Phil Factor

How many bug types can you name off?

Wikipedia lists six types of bugs: HeisenbugsBohrbugsMandelbugsSchroedinbugsPhase of the Moon bugs, and Statistical bugs.

Which music should you listen to while squishing software bugs?

The Bug Song by Canada’s Stompin’ Tom Connors of course.

Bugs Bugs Bugs, If I had them all in jugs
I’d dig dig dig, till a big big hole was dug dug dug dug–
And that would be the end of the bug song…repeat

Author: Adam Kahtava Categories: Musings, Quality Assurance Tags:

Quality Assurance: Unit Testing: Test Driven Development (“TDD”): “Write the test first”

July 19th, 2006

The quality assurance (QA) activities in software development generally include: defect tracking, Unit Testing, source-code tracing, technical reviews, integration testing, and system testing. Out of these activities: Unit Testing, source-code tracing, and integration testing are informally left to the developer. Out of these three developer specific activities, Unit Testing seems to be the most overlooked and misunderstood activity with the greatest potential for improving the development process (improving quality, efficiency, etc…).

The procedure [for Unit Testing] is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. – Wikipedia: Unit_testing

By writing good unit tests and employing a good Unit Testing framework you can significantly improve your software development cycle. By writing unit tests you decrease your dependency on a debugger, decrease source-code tracing (debugger walkthroughs), and so on. And by employing a good Unit Testing framework you can begin to lay the scaffolding for other forms of developer specific testing (integration, system testing, and even GUI testing). Unit Testing also contributes to better documentation – if a developer doesn’t understand the purpose of a component they can now read an additional piece of documentation, the unit tests. Unit Testing and Unit Testing frameworks can bring a team of developers to the same level – the capabilities within a team vary by developer. By using the same underlying framework, by identifying general areas that always need Unit Testing we develop a heuristic approach to testing and with that, test patterns, and a new vocabulary to assist with inter developer communication – design patterns accomplish a similar goal. Marc Clifton has a tutorial on Unit Test Patterns.

Unit Testing has its flaws just like any other technique or methodology – there are no silver bullets. Unit Testing is contingent on GOOD unit tests – it’s just as easy to write bad code that works, as it is to write bad unit tests that pass (work). Unit Testing won’t catch every error, but that’s the reality of writing programs, it’s also why we have a large number of software testing (QA) activities – writing software that is 100% bug free is impossible. These are just a couple issues with Unit Testing.

[Test-Driven Development is] a computer programming technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. The goal of test-driven development is to achieve rapid feedback. – Wikipedia: Test-Driven Development

The Test-Driven Development (TDD) programming technique is fundamental to many of the Agile methodologies – particularly the Extreme Programming (XP) methodology. The TDD approach uses Unit Testing as a process for designing and testing software. The core idea behind TDD is to have the developer “write the test first” then write the code to pass the test. The technique forces the developer to “thinking before acting” which is really a “best practice” advisable for everyone – I would hope that “thinking before acting” is practiced informally by most experienced developers, but that’s often not the reality. Other programming techniques that revolve around the “thinking before acting” idea include: the Pseudocode Programming Process (PPP), and the Program Design Language (PDL) Both the PPP and the PDL have gained exposure through Steve McConnell’s book Code Complete.

The mature unit testing frameworks that have gained popularity through the TDD / XP community are important; unit testing through these frameworks will compliment any quality assurance plan and improve any development process.

For more information on Unit Testing and TDD see the following:

Author: Adam Kahtava Categories: Quality Assurance, Software, Testing Tags:

Quality Assurance: Advanced Unit Testing: NUnit

July 17th, 2006

Marc Clifton has a great five part series on Advance Unit Testing. Throughout these articles Marc builds a Unit Testing framework based on the NUnit framework – NUnit is a Unit Testing framework for Microsoft .NET, it’s very similar to the JUnit framework for Java. Marc explores Unit Testing, the interworkings of Unit Testing frameworks, and the XP methodology.
Don’t be intimidated by the number or size of these articles – most of the content is source code.

  • Part I: Introduction to unit testing and a case study taking the XP process up to the point of writing some unit tests
  • Part II: Implementation of an NUnit look-alike and developing the case study further with real tests and real code
  • Part III: Implementation of NUnit extensions, revising and progressing with the case study
  • Part IV: Using reflection to create unit tests that are script based instead of code based, and the impact of that on the case study
  • Part V: Unit Test Patterns