Knowledge Nuggets

Wednesday, 3 June 2009

What is a mock object?

In object oriented programming mock objects are simulated objects that mimic the behaviour of real objects in a controlled way. Similar to a crash test dummy in car design.
You might use a mock object when a real object is impracticle or impossible to incorporate in a unit test or to test behaviour which is new.
Mock objects are used in test driven development.

Monday, 1 June 2009

Show what you know and what you don't know

Be generous in sharing your knowledge (without inflicting help). But also be willing to hear other peoples' ideas, build on them, and help others shine. Admit when you don't know the answers; there's nothing worse than a know-it-all who is wrong. Asking for help helps others see you as a real person, and people generally like to behelpful.

Advice from Esther Derby's "Insights you can use" blog
Article: 5 ways that team members build trust with each other (April 02 2009)

Monday, 18 May 2009

Why keeping a backlog on index cards is a good idea...

Portability - easy to pick up the cards and take them wherever.

Easy to prioritise - put them on a table and shuffle them.

Focused - there's not much you can write on an index card so only the most important information will be written on them.

Low maintenance - all you need is a pencil and a pile of index cards, and if something changes tear up the current card and write a new one.

Friday, 15 May 2009

What is a test stub?

A test stub replaces a real component on which part of the system under test (SUT) relies.

A stub is used to inject the SUT with indirect inputs allowing the test to execute different paths through the SUT.

There are two types of test stub - a responder and a saboteur. A responder injects valid values and a saboteur injects errors or exceptions.

Thursday, 12 February 2009

Burnup or Burndown

A burndown chart shows how much work is left to do. For example, a release burndown will show the amount of story points left on the backlog for a particular release, or a sprint burndown will show the amount of ideal (golden) hours left for the current sprint.

A burnup chart shows how many running, tested, features have been done and is thus more value-focussed.

What is the difference?

A burndown chart tracks net progress. It doesn’t easily depict changes in scope. For example, if we have 100 story points to burndown and we discover 20 missed points whilst completing 50 then we still have 70 left to do.

A burnup chart tracks gross progress.

When would you use each chart and why?

In Scrum, a burndown chart is best suited to depicting sprint progress because scope is not permitted change during a sprint. A burndown chart also gives the team a sense of an end goal (the ‘getting to zero’ feeling). On the other hand, a burn-up chart is best suited to depicting overall product progress because scope is likely to change throughout the lifetime of the project. Burnup will easily communicate these changes in scope because a change in the top line clearly indicates this change.

So why might you use a burnup chart for a sprint or iteration?

A burnup chart being used for tracking a sprint or iteration is generally a sign that a team is unable to work out its’ velocity. This can happen for a number of reasons, most notably:

  • Poor estimation – tasks are not broken down into small enough pieces (rushed planning meeting)
  • Unclear stories (information provided is often unsuitable)
  • Poor acceptance criteria (not done before or during sprint planning)
  • Missed tasks, such as reporting
  • Working on items not in the sprint (such as items slipped in undercover, bugs or management tasks)

Wednesday, 11 February 2009

GIF

GIF (Graphics Interchange Format)

  • Uses a palette of 256 colours
  • Handles solid colours well
  • Handles sharp edged line art well
  • Doesn’t handle gradients well (can be handled with dithering and blur)
  • GIF allows interchange of images / frames to support animation
  • Handles transparency on block objects
  • Uses matting for edges of graphic & transparency

A Bug is not a Bug unless you provide

  1. Steps to reproduce
  2. What you expected to see
  3. What you saw instead

Followers

Contributors