Wednesday, 31 December 2008

Agile Planning - Prioritizing Features

I attended Giora Morein Agile boot camp course yesterday and during the day Giora (while talking about Agile Planning) has shown the following diagram:

Picture1

He then asked the class what would they think should be the best order in which to tackle the given features. Several answers were given and all of them started with the "Low Risk- High Value" category.

I cant say I was too surprised by this. People, especially developers, have a tendency to first pick up the "low hanging fruits". Their natural reaction is to fear risks and go for path of least resistance (I've touched this subject in a previous post:Cost of Change – The Fear Factor).

However the "responsible" answer, would be to start out with the "High Risk - High Value" category and only then tackle the "Low Risk - High Value" features. The reasoning for this, is since the features in the "High Risk - High value" category have a HIGH value, eventually they will need to be done. It would be better to tackle and remove the risks involved in them as early as possible. Removal of risk is healthy for a project. One must try to remove as much risk as possible as early as possible, if a real nasty surprise is lurking, which will cause the project to fail. We want to fail it fast to minimize the amount of money wasted on the failing project.

BTW, after finishing all the "High value" features, a good strategy would be to proceed with the "Low Risk - Low value" category, and find something better to do besides "High Risk - Low Value" features.

Design For Testability - Lecture

On the 14/1 ill be giving a lecture for the Nes Tziona user group. The title for the lecture is Design for Testability is a fraud - TDD is easy! and will deal with the myth that user code must be designed in a specific way in order to make it testable. The complete lecture abstract with more info can be found here.

Wednesday, 17 December 2008

Code snippets for Isolator

I've worked a little with the AAA syntax of the isolator and after writing a couple of tests I felt the need to add some snippets to make things go faster. So here a couple I found useful.

(In order to use just copy each xml code into a .snippet file and use the snippet manager to import them)

The first one is for creating faked instance:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets
xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet
Format="1.0.0">
<Header>
<SnippetTypes>
<SnippetType>
Expansion</SnippetType>
</SnippetTypes>
<Title>
Typemock Fake</Title>
<Shortcut>
tf</Shortcut>
<Description>
Create a fake instance</Description>
<Author>
Lior Friedman</Author>
</Header>
<Snippet>
<Declarations>
<Object
Editable="true">
<ID>
Class</ID>
<ToolTip>
</ToolTip>
<Default>
T</Default>
<Function>
</Function>
</Object>
</Declarations>
<Code
Language="csharp"><![CDATA[$Class$ fake = Isolate.Fake.Instance<$Class$>();]]></Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>

The second one if for setting the behavior of a method call:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets
xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet
Format="1.0.0">
<Header>
<SnippetTypes>
<SnippetType>
Expansion</SnippetType>
</SnippetTypes>
<Title>
Typemock When Called</Title>
<Shortcut>
twc</Shortcut>
<Description>
Create a fake instance</Description>
<Author>
Lior Friedman</Author>
</Header>
<Snippet>
<Declarations>
<Object
Editable="true">
<ID>
Method</ID>
<ToolTip>
</ToolTip>
<Default>
fake.DoStuff()</Default>
<Function>
</Function>
</Object>
<Object
Editable="true">
<ID>
Action</ID>
<ToolTip>
</ToolTip>
<Default>
WillReturn</Default>
<Function>
</Function>
</Object>
<Object
Editable="true">
<ID>
Value</ID>
<ToolTip>
</ToolTip>
<Default>
0</Default>
<Function>
</Function>
</Object>
</Declarations>
<Code
Language="csharp"><![CDATA[Isolate.WhenCalled(() => $Method$).$Action$($Value$);]]></Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>

and the last one is for verification:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets
xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet
Format="1.0.0">
<Header>
<SnippetTypes>
<SnippetType>
Expansion</SnippetType>
</SnippetTypes>
<Title>
Typemock Verify</Title>
<Shortcut>
tv</Shortcut>
<Description>
Verfiy a call was made</Description>
<Author>
Lior Friedman</Author>
</Header>
<Snippet>
<Declarations>
<Object
Editable="true">
<ID>
Method</ID>
<ToolTip>
</ToolTip>
<Default>
fake.DoStuff()</Default>
<Function>
</Function>
</Object>
</Declarations>
<Code
Language="csharp"><![CDATA[Isolate.Verify.WasCalledWithAnyArguments(() => $Method$);]]></Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>

Tuesday, 16 December 2008

New Mocking Frameworks (C++ and Java)

Over the last couple of months (maybe half a year) there's a big discussion whether TDD/AUT is here to stay or is it just a passing fashion.

I cant predict the future and as much as I believe in these concepts, only time will tell. However, since I'm paranoid by nature, I'm always on the lookout for indications that TDD is here to stay. A strong indication for me is the creation of new tools to help and simplify the writing of unit tests.

I don't know if this is a pure incident or if someone up there is orchestrating all these but during the last week I was introduced not to one but to two new tools out there. Both of them are new mocking frameworks.

The first one is a a mocking framework for C++ released by no other then Google! (named GoogleMock) this framework complete the unit testing framework Google release not too long ago (GoogleTest).

The second framework is a really cool mocking framework released for the Java language - PowerMock. Like JMockit and the .NET counterpart Isolator this framework is based on the principle of Interception (achieved by bytecode manipulation/CLR code injection)  and will allow mocking any (and I mean ANY) kind of method, including Static, Private and Final methods.

For me this has been a productive week for tool developers.

Sunday, 14 December 2008

Windows 7 - Testing Aid.

Automating GUI testing still represents a big challenge for us. In fact I haven't seen a good affordable solution that will help in fully automating them. And where there is no automation what we left with are manual tests.

Sometimes however help comes from places you least expect it, during a preview session for the upcoming Israeli Developer Academy III, Alon has demonstrated some of the new features that will be included in the new Windows 7 OS. What caught my eyes was a little application that Microsoft has included in as part of the OS which is called "Problem Steps Recorder". This application focuses on helping users produce detailed reports about steps taken which resulted in a defect they wish to report.

now what is the connection?

Simple, part of the problem with manual tests is that someone has to sit down and write the test scenarios down. The person needs to write down, step by step, the things he is doing, and their expected outcome. This however takes effort and time.

The "Problem Steps Recorder can help in this, I have only got a glimpse of the tool output, but basically its a zipped html that describes the user actions and gives a screen captures of the output. one can also add some specific info to describes the various steps he is doing. So instead of writing this manually, what you just need to do is turn it on, perform the actual test and you get everything in a very nice format which can be shared by everyone.

Thursday, 11 December 2008

If its too hard - do it more often.

During a panel in the latest Scrum gathering, a question was raised regarding how deliver a potentially shippable product each sprint if it takes 3-5 days of stabilizing the product to get it to a release level.

Its a relatively common question which has various answer, however Scott Ambler has given it a gem of an answer(in my opinion at least). His answer went something in the spirit of:

if it takes you that long then you must do it more often, in fact keep on doing it until you learn how to reduce the time that needed for stability.

This somewhat relate to a previous post of mine,  Cost of Change – The Fear . Investing the effort to fix pains that we learnt to live with is always a low priority. In fact the bigger the pain is, its harder to fix so it slips down the list. After all, if it was easy, we would have done it already.

So Scott gave a good way out. Basically he advices to enhance the pain! If its a scratch cut it with a knife. if its a twisted leg, break it completely. Make it hurt so bad that ignoring it is no longer an option, and the only course of action will be to fix it. A drastic approach but one which works.

Sunday, 7 December 2008

Distributed Card Meeting

I'm a big fan old low tech tools when it comes to meeting and information sharing. There's nothing more informative then a plain white board and nothing more useful then a bunch of sticky notes when trying to plan something.

There are times when these tools are not optimal, usually this happens when all the participants are not physically present. In such cases try using CardMeeting, its a "whiteboard sharing" application that give imitate the behavior of a board and notes just done on a virtual wall that can be seen distributed places.

On the up side the setup is very easy the use is very intuitive and it does keep it very simple. Also, the data can be exported into an excel sheet for future usage.

Monday, 1 December 2008

Scrum Master Certification

I'm proud to announce that I have finished my formal Scrum Master training and I'm now a full pledged Scrum Master. Its a big deal for me since being in the job of helping other integrate agile practices into their development process, the training really helped me sort things out and put them in the right prospective.

Here are some pictures from the training session.

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons