My blog has moved!
You should be automatically redirected in 5 seconds. If not, visit http://samueladesoga.wordpress.com and update your bookmarks.
Showing posts with label BDD. Show all posts
Showing posts with label BDD. Show all posts

Friday, 3 September 2010

A tester's reflection on kanban plus BDD

So i have just finished an engagement with a client where the development process used include
kanban and BDD. Kanban for us meant that we give priority to work on the right side of the board.
So as a tester, I would rather spent my time doing some manual testing on a story that is in the QA queue, than writing automated acceptance tests for a stroy in the queue for Accetance Tests.

Maybe it would be worth while to draw a representation of the way in which work flows through our kanban board

Analyis > Queue > Accetance Tests in Progress > Queue > Dev in progress > Queue > QA in progress > Smoke Test > Queue > UAT Deployment in progress > Queue > UAT in progress > Queue > Live Deployment in Progress > Deployed.

The good thing is that everyone in the team has a visibility of work up till deployment. For more information, read up kanban

The BDD framework used was Cucumber + Watir + Rspec, and developers would only start developing software when the tests have been written for the acceptance criteria. (Acceptance criteria is written by Analysts in a text editor in the cucumber format). The acceptance tests is jointly owned by developers and testers. If as a tester i am busy doing some other tasks further down in the work flow, the developers were happy to write the failing automated test for the acceptance criteria before development commences.

As a result of these good practices:

1. The team was always in good spirit and which improves the effectiveness
2. The number of defects raised was low, this was achievable because for a developer to move a story to the QA queue, the automated acceptance criteria must have been passing.
3. There wasnt a defect management system because testing is carried as close to the development time, and if the business believes the defect is critical to the functionality, the functionality of story does not progress further in the kanban board, but it is blocked until fixed and verified.

One downside is that because we wrote acceptance test for virtually every functionality that is testable, the acceptance test grew so quick that the time taken increased from about 20mins to about 1.40mins and this time kept growing. A side defect of this is that feedback time increased and as a result developers would not run the complete test suite before checking their code in. This was however managed by doing some exploratory manual testing around the functionality being developed.

All in all, it was a good experience for me and i just hope i get to work on more projects such as this.

Wednesday, 10 March 2010

Blank cells in step tables in cucumber 0.3.11 is represented as nil

In my current job, I have been doing a lot of acceptance test using Cucumber, Watir and RSpec, obvious all in Ruby. I have been using Cucumber 0.6.x, in which blank cells in the step table are represented by empty string (""). This was okay for me until today when i had to use a previous version of Cucumber 0.3.11 due to reasons including compatibility with other projects in the CI build. And my tests start failing because blank cells are represented as nil.

There was fix put in the current release of cucumber to change blanks to be represented as empty and not as nil(for whatever reason, which i don't really care, as both nil and "" has got its own arguments.)

Some code to explain this, Assuming i have a step table as below:

Given that i have the following detail in my app
|Header1|Header2|Header3|Header4|
|Body1 |Body2 |Body3 | |

Notice that the last column of the second row is blank, this would be represented as nil in cucumber 0.3.11 while it is represented as empty string "" in cucumber 0.6.x

In my step definition file, I have fixed this by converting every nil value to empty ("")

Given /have the following detail/ do |table|
table.rows.each do |row|
row.map! {|value| convert_nil_to_empty_string(value)}
# do some other stuff with row as every nil object has been converted to empty string
# The map! method for Array, allow you to invoke the block for the array and it amends
# the existing array
end
end

The method which i call to convert nil to empty is below:

def convert_nil_to_empty_string(test_string)
if (test_string.nil?)
return ""
else
return test_string
end
end

There might have been a better way to do this but this surely worked for me in this scenario and the reason i decided to use a method was that the map! method would only allow me use the variable "value" only once in the block. I am sure there are some rubyist out there, that could advice me on some shorthand for this ....... Hope it helps you too