The power of writing tests in the Given /When/ Then format (GWT)

Having been a tester for nearly a decade I was always very unhappy at the way test cases were written. Especially when they were written in the form of Click button X , pop up should appear click on OK and so and so page should appear.

I found it extremely painful and boring to write tests in this format, step by step detailed and extremely action focused.Unfortunately the only reason everyone would give me for writing in such format was "they should be executable by any person regardless of his knowledge of the application under test". This in itself is something I don't agree at all but that's for different post itself.

Then I started to make some changes in the way test cases were written by adding precondition for tests , data required for tests, actors who can execute the tests and so on , but even that was very painful , boring , and repetitive from a documentation perspective.

But this was only until I learn the Given/When/Then form of writing tests.I first came across this form of writing on my first agile project 4 years ago.And ever since have stuck to that pattern.

How is it different : Just the fact that you can start writing tests with a set of "Givens" provides a jump start to writing meaningful and valuable tests. So instead of writing tests in a way that describe how user will navigate to a certain page and interact with the controls to trigger a feature/functionality putting a set of Givens allows the tester to reach a certain place/point in the app and then interact with the application to be able to verify the functionality.

Why is it good : This format helps to build a very clear and focused set of precondition before a test can be executed thus making estimating effort for setup and execution very clear and apparent.Also the fact that the Givens are should be met before a test can be executed allows one to sequence logical tests together and get a better sense of coverage and completion of tests.

On a recent project a minor story had to be played where , only the field labels on a certain form were to be changed based on at least 6/7 business rules to comply with the new regulatory requirements. Since I was new to the project the BA quickly showed me where the form is and how to get to it via various menu items.That was the easy part. The hard part was to make sure that the even though only the form labels were changed and format and display based on the geographic location of the record , there were loads and loads of Givens that needed to be in place before I could actually reach that form.While sitting with BA it was very easy to see how he could get to that part of the app but when I started testing it myself by resorting to the GWT format I found that I had to satisfy 7 givens before I could execute a when condition and then verify the screen and format. By being able to identify the Givens I realized how complex a small piece of functionality was because of its dependency on other factors such as data, transactions, access controls and various permutations of status, other transactions etc. Also I was able to articulate the amount of time and effort required to test the supposedly "minor change".This is how my GWT format looked like



Given when a investor has invested in X funds
AND the funds declare a dividend
AND they are part in cash and part in form of UNITS
AND the user has the option to reinvest X percent of the cash dividends
AND the funds in which the investment is done allows for X percent of investment in fund Y
AND the reinvestment happens in the first quarter of the financial year
When a Income transaction on the fund is processed
Then X amount of dividend accrued by the investor should be automatically allocated to the fund Y and the remaining amount is displayed as 'Cash at Bank' in the balance sheet.

Interestingly there were at least 5 such GWT tests that I had to write to ensure that label changes on a given form are correct for each Test Case.

Also this format helps me easily communicate with developers while we are writing automated tests for the 'minor change'. Since the givens are already mentioned it automatically becomes a part of setup for the automated tests which can be injected / manipulated / or engineered via DB creates/updates statement or searching for correct data records or mocking data. Also as the givens are assumed the tests are focused only to verify the When and Then of the tests thus making the execution of automated tests faster in speed and smaller in size - in terms of line of code.

Trust,Camaraderie and Teamsmanship

One of the basic tenets of Agile methodology is the mutual trust among the team members , the camaraderie among them and a general sense of "sink and sail together attitude".

I recently presented to a group of audience around the topic of "successful agile teams " and what are some of the common things  these teams had which make them successful. I was lucky to have a very receptive audience in them. Even though some of the points were rather simple and straightforward and really did not need  a mention there were some slides were very radical in thought and content. The interesting part was when everyone among audience agreed to the content but found it  a little difficult to put in practice.So often I have come across people who really come up and say "this was a great thought I wish I could do that or I wish my team understood the same " and then once they get back into their routine they simply cannot or do not want to risk the implementation.One of the slides mentioned "Only send email to those who are not invited else everyone else is invited". Very radical, very uncivil, very harsh but now put the same in the context of a team which has great camaraderie, have been working long enough to understand each other, are very very informal in their daily business and are really a great bunch of people doing their daily work and churning out production like code every two weeks with consistency and success. Now give them a message that...Only if you are not required you will be sent an email else as  a team you are allowed and invited('not required') for every meeting. Whether you want to come for meeting or skip is your choice but in general the thumb rule is that you "can " come along for meeting which are within the team. Now when I was doing my presentation the audience was not as much a mature agile team as i mentioned in my example. But then it becomes a question of chicken and egg. Can we lay such rules only once the team is matured and well oiled machinery or whether we should introduce some different rules and practices to MAKE the team matured and well oiled system. The question is where to start from and who to start with?

This discussion went for a couple of minutes and some one made a very valid point that such things can be introduced only if there is enough trust among team members. People should feel comfortable telling someone that you are not required or people should feel comfortable to walk into any meeting regardless of wether it is their area of expertise or domain. So in a team a person has to gain the trust of others and build the trust for himself. Just being successful in one of these is not enough. How do we do this ? This was the question some one asked me. Obviously I did not have a direct answer or a silver bullet to this question. I mean , how does one do it ? I don't know! But then how did it happen in some of my teams. Yes now I can answer that question. How did people create trust among themselves in a team. I believe that in order to create trust and  camaraderie the members can do the following.
A) Volunteer to share the pain of delivering. Many a times we see that in a team a certain team member is having problem getting his task done. This I believe is an opportunity for another team member to step and help the person being challenged and facing the tough task of finishing across the line. Regardless of  whether the task is eventually done on time or not you have at least got two person sharing the same problem and working as a team on it. Rather than each of them doing the work and the team still failing because of one person unable to do his stuff.
B) Be successful as early as possible regardless of the quantity of work then. A successful team is a happy team. And a happy team is willing to take on more and more difficult work and increase the output,  so if you are in a position to direct your team make sure you take small work and become successful as quickly and as early as possible. As soon as the people in the team believe that they can be successful they will start believing that each of them has a reliable and trustworthy teammates and once that is the feeling among the team they will quickly start breaking their boundaries and give more and more contribution and output.
C) Have FUN. Having fun in my opinion is most difficult yet the most important aspect to build camaraderie and trust among team members. Its not easy. Its an art. There is no direct way of having fun. Having fun doesn't mean just having lunch together or going out for drinks every friday night. FUN means being involved in team building activities, driving them , doing things without being under the pressure that you will be evaluated for everything you do, things such as rotating the the facilitator, some fun at beginning or end of standup, different ways of having retros, allowing a new person to take charge of team activities such as team dinner, show cases, or just having some fun toys in the team room , celebrating sports victories,bdays, anniversaries,  having cartoons around the walls, mimicking,  are some of the things that should happen naturally in a team. Such things should ideally happen impromptu and without any specific direction but there have been instances when I have started them , held on to them and someone finally made a fun of me and eventually it became viral among the team . Goal MET :)

There are also many agile games outdoors as well as indoors which can be played for  team building.

Some sites worth referring to for such agile games  are  :
1)Team Building Games
2) Agile Games
3) Thoughtworks' very own Lego Game :)

The art of running a good retro :lessons learnt

Until now I have participated in a number of retros but usually as a participant of the team. Today I got a chance to actually facilitate a retro. No bones about the fact I was a little nervous to start with. Having around 20 people it was a tough ask also because the retro was with a team of SMEs. Strangely enough I did not prepare at all about what I should be doing. But the things I did just came to me as if it was a natural way of doing it. I guess the secret is that I have been learning a lot from people who have facilitated retros previously. Also I think than when I dont volunteer for something but either get picked up or get thrown into I perform much better. Okay so enough about me...let me say more about the retro.

Over all I think it went pretty well , partly because the audience did not know what to expect and partly because I was able to prick the right cords in their brain. They really wanted some one to facilitate the whole process with no vested interest in the outcome and I guess I was pretty good at that. Seemed to me that they always sensed some achievements as a team of SME but could never really put a finger on it. They lacked beleif in themselves, the courage to share the mistakes and the willingness to fix it.And I had gotten into this retro with exactly these 3 as my objectives. Bring out all their feelings , knowledge and capabilities out and display it to everyone in the team. Sometime we do retros with a very clear objective of Fixing somethings that went wrong...and that is exactly what I did not intend to do with this retro. I just wanted everyone to feel relieved after the retro that they could get the thoughts right and to everyone in the team . This objective then quickly turned as a goal for the team to even take a stab at fixing some of the  points they had identified.

They way I started was to ask everyone to just make a wish list of how the IDEAL case would be as per them. Put each point on a card and leave it. Don't worry about constraints . possibilities, practicality of the wish list and once they did that pretty much everyone got some burden off their shoulders instantly.

This quickly then segued into categorizing the wish list based on certain themes.

And once the themes were evident on the wall these people were smart enough to then pick the most relevant and throw their suggestion on how to try and fix them.

So in that sense I feel happy. But what did I learn?

1. I learnt that even though I want the team to come up with solution, if I know it I should guide them towards it without disclosing to them that I am actually driving it. Tricky but interesting. So I actually lead them but they do not realize it.This brings and maintains the team spirit.

2. I had the card wall very badly organized. I need to ask people to put their respective cards on the wal instead of me doing it which takes some time and allows distraction of audience. Esp if I have already identified the broad categories the card will fall into.

3. Effective use of Parking lot concept.This will help me to time box the topics to be discussed and also give everyone a feeling that not each item can be covered but also that not each item is important in relevance to the other...


Overall very learning and enjoyable experience.....

Sometimes asking the right question is enough

Very often I see people falling into a common trap - of trying to solve problems based on personal understanding and interpretation of the problem. Its difficult to put this thought in the right perspective but I will still try....being a consultant for most part of my career I have experienced how easy it is to sit far and away from the problem and give a rational opinion on some things.One of the reasons, I believe, a consultant can do that is because he does not have any vested interest in the success or failure of the project. There are no budgets to manage, there are no political games to be followed, there are no egos to be satisfied and there are no pink slips to be handed out. But one big trap of being a consultant is that you are expected to always provide a solution/answer to a given situation. And this is exactly what I think is not fair. Sometime even asking the right questions is enough. Many times i have seen that a  consultant looks at a situation , analyzes the possible causes, looks at available options to the problem and thats it ...he has a list of potential solutions. But I think that many times even though we do our usual checks to come to a conclusion we should let the client/customer define the solution and pick the options. Presenting the problem without mentioning the available potential solutions is very useful way of driving the customer to solve their issues.Objectively appreciating the situation and constraints is one thing and providing a solution is another. Many times in our capacity we should not really do both the things . Very often we should guide the customer to make a decision and in fact sometimes not even provide him with the answers....Make the problem so obvious to the customer that he chooses the most appropriate solution. This helps in 1) giving customer the authority and confidence that they have made a correct decision and 2 ) let them carry the ownership of the decision and its implementation. Its very easy to provide solution and then help client implement it but then what we are doing is creating / making ourselves as accountable and responsible for customers actions. As long as customer holds consultants accountable for their actions it seems fine but execution should not be a responsibility of the Consultant, in my opinion.

crAgile - Now I know what my first iteration manager meant by that

Currently I am working at a client site which basically invited Thoughtworks consultant to help them improve their testing area as they beleived that they need to "agile up" their testing department / practices. Pretty common concern thrown by clients..."Seem QA needs to be Tidied up"...This is not the first time I have come to the conclusion that usually when an organization wants its testing dept / testing practices to be beefed up its actually something else that is a root cause of the problem. But since Testing usually throws a spotliglight on the problem it itself is considered a problem instead.The place I am working currently we are trying to implement , encourage adoption and preach that developer write acceptance tests for the cards they develop. Needless to say this seems to be the first step of grief for the development team.Initially I was very disappointed that developers had to be justified the need for doing so but really the issue was that the team was being asked to do points driven development. This is the worst form of Agile implementation I have come across yet...It essentially means that no matter what the capacity of your team is in terms of velocity the team still has to complete X number of points every iteration. If that means starting to work before the cards are completely elaborate or if devs have to skip unit tests or acceptance test so be it. As long as by doing so team is able to meet the points already decided by higher ups. I have started calling is "Waterfall in iterations". Given this deadline /drawback there is absolutely no incentive for the devs/BA to write the acceptance tests such that they become a apart of the done criteria. Infact if the estimate on  a card increases if the acceptance cases have to be written it is totally OK to skip that. I have seen many twists of agile principles in the name of agile itself but this twist is absolutely pathetic.I am sure this is just the tip of the iceberg and I will see many more such twists on this project but the start itself is so nightmarish I wonder how bad its going to get further down the road. This brings me to the title of the post crAgile. My first iteration manager used a term called crAgile for all such twisted implementation of Agile projects. This is certainly one of the best crAgile I have come across so far :)

Agile Workshop Experience

Recently I was a part of a thoughtworks team which was to run a workshop for a client on agile. This was the first time ever I was on the other side of the table, meaning I was not listening to people talking aboout some topic but actually I was delivering this time. Great experience I must say. Part of the good experience was the fact that I already had 2 seasoned professionals working alongside me on this workshop. Both of them seemed very very good at this kind of stuff so I was not too much under pressure to "do the right things". It was a very learning exp given that the audience were from very different profile and background/experience/and business. We have everyone from a developer to a tester to a qa manager to VP of development in the organisation attending the workshop and it was truly awesome to be facilitating for this workshop. More than the actual workshop what I liked was the preparation we did the previous night for the workshop. The 3 of us had gotten together just 12 hours before the actual show was to begin and still we came up with concrete plan deliverables, definite objective, execution mechanics and finally during the workshop it seemed so seamless as if we have been working together for last 2 years. The workshop seemed very well orchestrated and there was no hint that these are a bunch of people coming together in last 12 hours and cooking up stuff for the workshop.
Personally I enjoyed one of the sessions called Trends in which we tried to map our experiences to the pain points that clients have been facing in the organization. I was quite wired up during that session and actually took a lot of questions and did a lot of talking. One of the feedback I got was that I always tend to talk in in first person when narrating any experience. May be sometime I should talk in 3rd person. OK will keep that in mind.Apart from that I feel after my Talking experience to MS on agile Testing this was yet another step for me to broaden my work scope into non testing related function. Thanks to Rajeev and Jack who took me in the time despite me having zilch experience on any such activity previously.TOTALLY LOVED IT!!!

Defect Driven Test Cases

Recently I was reading something around test driven development and how it has been further extended to behavior driven development. I started to understand the philosophy behind behavior driven development pretty quickly. The Given,When,Then format for writing a scenario is an straightforward and easy input for developers to build their code around.

Now I am thinking that similarly we should also start doing defect driven test cases. So the current practice for a tester is , generally, look at the requirements , analyze the testing aspects from a story card (I think only agile projects now), identify testable items and write them as acceptance cases. This is good and required but what about System Level test cases, integration test cases should they be written upfront ?. Now if the quality of test cases are so good that you get at least 30 percent of defects from executing your test cases then I think writing test cases before doing actually testing is worthwhile but if the objective of writing test cases is to create more documentation to cya , or to be able to create an unnecessary deliverable from the testing team then really its futile. Instead what we should do is "Exploratory Testing". Do Exploratory testing on the in system and integration phases and then based on whatever defects found during system testing or integration testing and create test cases for that particular defect for future testing and regression. This will do two things for the tester. 1 - Invest less time in writing useless test cases and 2 Write test cases which are more specifically targeted to previously found issues on the application in a given module/part/application.

I will continue on this thought further but for now...I think defect driven test cases is the way to build your test repository from a test case/scenario/test data/and app issues perspective.