Showing posts with label quality. Show all posts
Showing posts with label quality. Show all posts

September 4, 2010

Defect Driven Testing: Your Ticket Out the Door at Five O'Clock

are you not doing TDD yet? start with DDT...

Defect Driven Testing: Your Ticket Out the Door at Five O'Clock:
Test automation is not a controversial topic in most circles. Even developers who don't write automated tests agree it's a great idea. They just don't have time to work on it very often.
....
DDT is a fairly simple concept. When you find a bug, add a test.

Why take this approach?

First, no one can dispute the need for the test. If an issue was found, then it had been missed earlier. Perhaps the developer missed it and QA spotted it. Maybe it slipped past everyone and it was reported by your customer. Whenever it's reported, it needs to be fixed in a way that will prevent it from reappearing.
....
DDT is a gradual approach.
....
Over time you'll find that DDT creates an extremely effective test suite that targets the most problematic parts of your code base. Run your defect driven tests inside of a continuous integration system and you'll find your code running more cleanly every day.

August 27, 2010

Dennis Stevens: We are Doing QA All Wrong

A few interesting things from an article by Dennis Stevens, very loosely quoted...

  • We Don’t Understand Quality Assurance
  • We Don’t Understand the Cost of Rework
    • Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.
  • the cost of setting up testing environments is much lower
  • Quality Assurance needs to be part of the development team and process. We need to change our thinking around this. So we need to integrate Quality Assurance very early in the process.
  • We have the Wrong Expectations
    • We Expect Perfection - Not Improved Value
    • We Expect Local Optimization - Not Flow
  • Enable value, flow, and ongoing improvement
Dennis Stevens » Blog Archive » We are Doing QA All Wrong 

From the comments:
  • One thing: No one can assure quality. Can I convince you to change the reference to “Quality Assistance?” (Jon Bach)
  • I prefer ‘testing’ and ‘tester’ to ‘quality assurance’ and ‘QA engineer’ or whatever. But these are nits. The message of Dennis’s post is the point – focus on value, improvement, delivering a better product. (Lisa Crispin)
  • I introduce myself to teams as the “public health nurse” for their project, and then subtly place ‘quality assistance’ in my email signature. (Adam Geras) 
  • testing is a complex, organic, cognitive activity, rather than a rote, bureaucratic, clerical one. (Michael Bolton)  

Blogged with the Flock Browser

May 26, 2010

TDD w/javascript using jsTestDriver and (f.ex) QUnit

JsTestDriver is seemingly yet another unit testing framework, and it stems from Google. I say seemingly, because the JsTestDriver guys has made some delicious improvements over the normal work flow which sets it apart from other unit testing frameworks for JavaScript so much it's not even funny to compare.

Having said that, JsTestDriver is (as the name implies) really more of a test runner. It ships a default assertion framework, however it doesn't offer all kinds of JavaScript specific assertions. Instead, JsTestDriver makes it fairly accomplish-able to use your current assertion framework of choice with JsTestDriver by providing a bridge. Last time I checked, both QUnit and YUI Test had functional bridges.
Test driven JavaScript done right / JavaScript - cjohansen.no

There's also an eclipse plugin.

 ff
Blogged with the Flock Browser

February 18, 2010

Separate Estimating from Committing

Don’t let your estimates become commitments. Remember the difference between an estimate and a commitment and keep the two activities separate, educating management and customers as necessary.
Separate Estimating from Committing | Mike Cohn's Blog - Succeeding With Agile®
Blogged with the Flock Browser

January 31, 2010

interface code smells

Interfaces are a very useful language feature, but are much abused. Symptoms include:
  1. An interface is only implemented by one class
  2. A class implements multiple interfaces. Often touted as an advantage of interfaces, usually it means that the class in question is violating the principle of separation of concerns.
  3. There is an inheritance hierarchy of interfaces (often mirrored by a hierarchy of classes). This is the situation you're trying to avoid by using interfaces in the first place. Too much inheritance is a bad thing, both for classes and interfaces.
All these things are code smells, IMO.
(Jim Cooper)
Why do most system architects insist on first coding to an interface? - Stack Overflow
Blogged with the Flock Browser

January 27, 2010

building from scratch is mind-bogglingly easy compared to changing something

Building something with a single purpose from scratch is mind-bogglingly easy compared to changing something that already exists. 
....
The real cost of complexity increases exponentially.
....
One guy wrote eBay in a day -- one guy, one day! When they built version 2, the project took the same guy many weeks. Version 3 took many years. There can never be a version 4
....
why does each version take longer -- even if replacing the system in full? The answer is that small amounts of increases in perceived complexity (e.g. each new requirement) expands the real complexity of the system exponentially. Want examples? Take a hand-built web-site and add internationalization / localization. Add accessibility support. Add support for other devices, such as an iPhone. Add scale-out. Add high availability. Add security. If you know someone that thinks it's easy, then whatever you do, don't hire that person, fire them if they already work for you, and quit if you work for them.
/dev/null : Weblog
Blogged with the Flock Browser

JsUnit - unit testing javascript

JsUnit is a Unit Testing framework for client-side (in-browser) JavaScript. It is essentially a port of JUnit to JavaScript.

JsUnit
Blogged with the Flock Browser

November 19, 2009

exception handling, bug reporting

Then when an error occurs, try to only ask the user questions you can't answer programatically. Ideally, your exception handling should already track their current action (saving an invoice), current context (invoice screen), the entity being acted upon(invoice #10013), and all the exception info from the program. If you can't capture this and retrieve it remotely, feed it to your web form (in URL params or whatever) when the user clicks 'report this issue'. Ensure you pay attention to any sensitive data requirements.

Then you should only need to ask your users the human questions like - 'How can we best contact you about this issue?' (method / times / etc.), and give them an idea of how long it'll take for them to get a response from a human.
What is the best way to cater for users reporting bugs ? - Stack Overflow
Blogged with the Flock Browser

July 6, 2009

questions for daily stand-up

this is from a pdf on a different topic entirely (PDF: Dr Holt's CCPM Games - Sixes Game), but in the middle (p.8) is a few questions that could be used for a quick daily stand-up:
1. Did you complete the Active Task Yet?
If not: 2. How Much Time is Remaining?
If not: 3. What are you awaiting?
If not: 4. What can we do to help you?
no. 1 and 2 is in effect info om MIT(s), the Most Important Task(s).
no. 3 and 4 is in reality info on what i call BPP (SPP in Norwegian): Biggest Potential Problem.

this could also be used along with a kanban board, especially if you limit yourself to only one Active Task most of the time.

positive effects of asking/ providing this daily:
  • people will recognize the urgency of completing tasks
  • people will disconnect the due date from the actual completion of the task
  • giving time remaining leads to a better daily view of actual project buffer status
  • having a list of BPPs/ "what's holding up our process" is extremely valuable for process improvement and planning
  • "how can i help" may actually provide help to lingering tasks
NB: ask the 4 questions daily, without much discussion, without penalty, with assistance as needed

July 1, 2009

rapid, "throw-away" prototyping is the crucial and neglected stage in project design

a problem I think is endemic in the industry these days [is] the inability or unwillingness to engage in rapid prototyping. Every successful project I've ever worked on (and I've worked on some fairly large enterprise-sized projects), we started by designing and coding a quick "throw-away" skeleton of the application, that let us look at how the thing worked, where the unseen warts were, and where the vendors had lied about their APIs, etc. This is the crucial and neglected stage in project design, one that most modern design paradigms ignore or actively discourage.
The Hacker Ethic - Harming Developers? - O'Reilly Radar
Blogged with the Flock Browser

June 16, 2009

June 2, 2009

CubicTest

CubicTest is a graphical Eclipse plug-in for writing Selenium and Watir tests. It makes tests faster and easier to write, and provides abstractions to make tests more robust and reusable.
CubicTest
Blogged with the Flock Browser