Magnetic custom team scrum sprint/story cards

A team's sprint board needs to radiate information about how the sprint is going. Fridge magnets for use on a team's magnetic sprint whiteboard can be custom printed. The trick is to print "business card fridge magnets" for only ~AU$10 for 10-20 cards. Vistaprint (I have no commercial benefit) provides a great service of uploading your card image (e.g PNG) and printing it.

I've found these magnetic card reusable using whiteboard markers. For magnetic tags like "BLOCKED" or team member names, create a card with many tiles and cutout the tiles when delivered (See example below).

Examples:

 

     

     

Revitalizing Legacy Code - Properties returning concrete types

You have a legacy code base that has properties returning concrete types. This makes unit testing (UT) very difficult. To change the signature to use an interface requires lot or refactoring and therefore risk of an error refactoring. Here is an approach to incrementally refactor these properties out of the code base.

To provide an alternative add another property to the type with a suffix like "I" that returns the appropriate interface. This become the base property with the concrete property referencing this new property. This enables new or code being changed to migrate to the new property incrementally. Once the old property is no longer used it will be deleted.

Legacy code:

  public class WidgetA
  {
     public WidgetB PropertyB
    {
      get
      {
        // whatever stuff done here
      }
      get
      {
        // does other stuff here
      }
  }

Testable (incrementally) legacy code:

  public class WidgetA
  {
     [Obsolete("Use  PropertyBI instead")]
     public WidgetB PropertyB
    {
      get { return (WidgetB)PropertyBI;  }
      set { PropertyBI = value; }
    }

     public IWidgetB PropertyBI { get; set; }
  }

The use of the ObsoletAttribute ensures that developers will see the property struck out in intellisense to promote useage of PropertyBI instead.

When the old, concrete type, property is no longer used it will be deleted and the "I" suffix property renamed to replace it.

Nice incremental refactoring of the code and allowing for incremental unit testing.

Automated application tests on active legacy applications - Team kickoff cost

How does a team get started with automated application tests on active legacy applications?

By that I mean tests for verification that the application does what it is supposed to do. Automated application regression tests. Like everything to do with software dev and testing teams there is the "change management". How does a team get the steam up to start running with automated application tests on an active legacy application.

By "legacy application" I mean any application that is out there, running, under on-going new feature development, but does not have any automated application tests. It may have developer unit and integration tests but no tests that assert the customer's required end behaviour (BDD?).

Such a team is under pressure to add new features and is experiencing "legacy" defects discovered during verification testing and, typically, the people on the dev team have changed so domain knowledge is not ideal (I do often think that a developer's domain knowledge is just poor code architecture migrator).

In these, common, scenarios to get automated application tests up and running to a point were a team can incorporate them into its culture is a big ask. There needs to be an investment in the framework, team training, and that means the business needs to understand the cost/benefits. So in the end it comes down to the tech/dev lead to identify and communicate the opportunity to the business.