how to pull your favourite github project, fix something and push it to your own repository

There will be a lot of situations where you find some useful tool in github , then you start using it, in the middle of it, you hit a roadblock and the owners of tool aren’t ready yet to fix it as soon as you want, what do you  do ?

Do It Yourself

1. get the url of your project you want to clone and run this command  git clone git://github.com/<usernameofrepo>/<projectname>.git
2. cd <projectname>.git
3. the main project will keep on changing but if you want to fix something in a particular version then
4. git checkout <version of a tag> eg: git checkout 0.2.1
5. using vi or any edit and make all the changes you need, save the files
6. ‘git status’ command will show all the changes you have made
7. ‘git diff’ will show the diff
8. git add .
9. git commit -m ‘comment for your fix’
10. git tag <new version by tagging> eg: git tag 0.2.2
11. https://github.com/ and follow the instructions on first and second boxes
12. https://help.github.com/articles/generating-ssh-keys to add ssh keys so you can connect via ssh to your github a/c
13. open ~/.git/config and change url under “remote “origin”” to https://github.com/<username>/yourproject.git
14. add the following section to the config file
15. [remote “upstream”]
    url = https://github.com/<path/to/original/project.git&gt;
    fetch = +refs/heads/*:refs/remotes/upstream/*
16. git push origin master
17. git push –tags
18. Verify if the changes are reflecting in your github a/c

These are very basic steps that will help you clone a project , fix something, push the change to your a/c. Then you can send the project owner a pull request so they can review and merge your fix into their project. Hope this will help you take first step towards Git!

Thats all folks!

How do I get started with TDD ?

When one of our team is trying Test Driven Development, we were looking at ways to get us started. Because TDD is totally opposite to how we are used to doing things, when looking for some inspiration, my manager gave me this http://nsbrief.com/40-graham-lee

This interview with Graham Lee goes on for 1 hour 20mins, but it not just pure TDD, it has also about Objective C,etc. So , i thought why not extract TDD specific part plus some of my input, so not everyone has to sit and listen for so long.

TDD – There is no code to test, why are you writing the test in the first place?

it helps to make sure you understand the problem you are trying to solve

it is a useful design tool. Your unit test will be a blue print for the class you are going to write

You will start to feel like you are coding backwards

It forces you to think about how you are going to use this class in the first place before you write a line of code, its a different process

How to get into TDD ?

Its really practice that helps you to understand

‘It was taught as a training course, it didn’t make any sense , why i was testing code’ – more of hands on instead of training helps you get up to speed.

Try to apply on few projects, first it will slow you down, it will be frustrating because you will be thinking in a different way than you used to.

After you written some classes in test driven way, it starts to become more natural

Best way to start TDD is with a bug fix, when you finish, you got your regression test in place as well

Writing unit test before code

Write notes on empty unit tests based on the requirement,  write like a To-Do list inside the unit test class and it really comes down to fill in the blanks – turning each to-do items to java statements

Always have them fail, never make them just pass by default or skip

Don’t give up until you finish all of the tests

Starts to think about problems,  how do you prove that you have solved this problem?, how do you write a test that demonstrate that you have completed this task?

You unit test could cover only 80% of you class and still pass, how do you prove that it covers 100% ? Creating the above to-do list will be helpful.

Why TDD instead of BDD ?

TDD – you only write code that you only need

You could still write test/automation to cover this scenarios that you are going to write, so why still we need TDD ?

programmers are naturally lazy, while we can write cases for thing we don’t actually need to cover, its becomes useless

you don’t have to restrict TDD to unit test, using cucumber you can make it appear as TDD

To some level they have the same kind of philosophy

Committing code ?

Should you commit all your passing test or wait until it becomes green

With CD, only option is to check-in unit test which passes, otherwise it will break the build.

In case of more than one person working on related code, and one dependent on another, he/she may have to unshelve others’ code to test his/her code.

thats all folks!

How to setup Test Load Balancer in Windows

If you are using cucumber for automation, have hours worth of automation to run, TLB can reduce your automation execution time by optimising the parallelisation. In other words, if your automation takes 1 hour to run sequentially, using TLB you can make it run in 10mins if you want depends on how many partitions/balancer processes you use on same or different machines.

The real benefit is, if you are already doing or planning to do Continuous Integration and then Continuous Delivery so the  smoke/acceptance automation execution time after every checkin can be reduced phenomenally. This youtube video gives a clear picture of how to run TLB.

I’ll let you read the concepts and mechanics behind TLB at their project site and let me concentrate on writing how to make TLB work in Windows with cucumber.

Windows OS used in my case is Win XP Pro Service Pack 3.

Ruby version is 1.9.3

I did a Proof Of Concept that TLB works with cucumber automation on Mac Pro and it was seamless but when I tried it on Windows, there were many hurdles to pass and in this blog I’ll list out the steps to successfully make TLB (0.3.2) work in Windows. The work arounds/hacks mentioned in this blog will be available as part of 0.4 release of TLB so no need to hack around if you are using 0.4. All steps are applicable if you are using Ruby 1.8.7 and greater. If you are using JRuby, steps 5-13 are NOT necessary.

1. make sure you have JRE 1.6 –  java -version should give the status , if not you can get it from here
2. Download TLB from here – as of 11th July 2012, tlb-complete-0.3.2.tar.gz is the latest which comes with some examples cucumber projects as well
3. Install the following gems
4. gem install tlb-cucumber
5. gem install win32-open3-19 (tlb 0.3.2 documentation does not mention this)
6. gem install open5 (tlb 0.3.2 documentation does not mention this)
7. Edit <ROOT>\ruby\1.9.3-p194\lib\ruby\gems\1.9.1\gems\tlb-core-0.3.2\core\lib\tlb.rb
8. Add “require ‘open5′” to the top of the file (of course, remove the double quotes 🙂 )
9. Replace “@pid, input, out, err = Open4.popen4(server_command)” with
10. “input,err,out, @t= open5(server_command)” and
11. “@pid=@t.pid”
12. In the class “class ForkBalancerProcess” there is a method called “die”
13. in that method, comment the statement “Process.wait”
14. Edit <ROOT>\ruby\1.9.3-p194\lib\ruby\gems\1.9.1\gems\tlb-cucumber-0.3.2\cucumber\lib\tlb\cucumber\lib\run_data_formatter.rb
15. replace line 33 containing code < args[0].file > (in method feature_file) to read < args[0].file.gsub(‘\\’,’/’) >
16. Save the files, start TLB server <ROOT>\tlb-complete-0.3.2\server\server.bat start (or server.bat cleanup before start if server was killed)
17. run the balancers using run_balancer.bat files

Errors to look for:

When you trigger the automation via balancers if you see and error “fork() call not implemented in this machine” then you haven’t done some or all of the above steps correctly

Thats all folks!

Open Vs Close cubicle and its impact on QA in Agile environment

Open vs Closed cubicles and its impact on QA in Agile

Open Space & Closed Cubicles and its impact on QA in Agile

This post discusses about the pros and cons of a team working in closed/semi-open

or an open environment. is this a QA problem ?, will come to know shortly.

Since I graduated, I worked in different companies and each had their own working style and environment. In one of them each office space is a cubicle, which is not fully closed.Just raise yourself up by 4 inch from your seat, you can see the whole floor and at least people’s head. Stand up and you can confirm if the person at the end of the floor is at his cube or not. Lets call this type of cubes as semi-open.

In another company in silicon valley, the office space is cubicle as well, but the cubicles are almost like rooms with a narrow opening and you can’t see your neighbours even if you stand up and jump. To make matters worse, each cubicle has a movable metal shelf and some people arrange their shelf in such a way that its difficult to see them even if you stand in front of their cube entrance!. Lets call this type as fully closed. Another one, fully open environment as in my current company, lets call this fully open.

In fully closed type, the problem is, face to face communicate is hard if not impossible. As Agile is becoming the defacto model being followed for software development, where not just the communication but minute by minute communication within team members plays an important role in making this a super fast successful development model. Advantage is privacy to employees, but I think it was just like that from the beginning of the start-up era and continue to be like that until someone realised that its killing productivity. In a model where you don’t have a Product Requirement Document and functional spec, the frequency of communication between team members is/will and should be very high. In this way, closed cubicles and agile combination is like a train labeled as “super fast”, with a steam engine trying to pull loads of modern coaches. Last time I heard, the company I worked for, is planning to dismantle its close cubicles and replace them with open environment, one building at a time.

Quite opposite is the open environment, where same project related team members sit next to each other. Everything can be communicated by literally ‘giving a shout’. Well, the disadvantage is, people can be disturbed all the time and spreading of contagious diseases like cold and fever are very high as well.

Whatever the environment is, whenever there is a limitation in communication, whenever there is a wait before a communication can take place, the biggest impact is beard upon by the QA team. Before discussing the how part, I would like to give a pre-amble so that the reader can empathize with us. Lets take an average team, with 2 QA engineers, 6 dev engineers , 1 scrum master and 1 product owner. If you draw a one-to-many mapping within the team members, and imagine traffic flowing across these lines in both direction, the amount of traffic flowing from QA engineers to the rest of the team will be the highest. Why is this ?

During the period of an iteration, a scrum master’s communication with the team will be about helping them out from any blocks, most of the time its passive and equally it happens via email as well. A product owner’s role is to define the acceptance criteria and clear any clarification on that if necessary, again that’s passive. A CM engineer does where is requested from the team. A passive communication is when, instead of the main subject, the opposite member initiate the talk.  A developer works on one story at a time, and at most, he or she might have to talk to the product owner for clarification of the acceptance criteria. Most of these communication happens as part of the daily stand-up.

But a QA engineer will be working on more than one story at a time, say for example 3 which happens in agile. He needs to talk to 3 developers every time he finds a defect or want to clarify the way a feature behaves. If there is a defect every half an hour, then there is an active communication involved every half an hour with the corresponding developer and the product owner, in most cases. Besides that, there might be build and environmental issues that involves back and forth communication with CM engineer. Every time something needs to be tested in stage, a communication with CM engineer is a must. For every story, any addition/deletion to acceptance criteria involves communication with the product owner. Sometimes, it is necessary to communicate with marketing department as well.

Imagine if we have to wait and there is a delay involved in every aspect of the above mentioned communication, then we might as well move back to water-fall model. The argument here is, which kind of  setup  equip the team with the best environment for faster communication. One can argue that chat clients and phone are alternative to faster communication. It might be true to some extent, but they have their own limitations. The person you want to talk might not be online or not there to accept your call and not all type of discussions can happen via chat or telephone. But the open type environment encourage face to face communication which could happen at any time. You are always seeing the team and in touch with the team.

I think, for Agile, the environment should be open type to fully utilise the agility this model provides.