Automating with Agile

31 12 2013

Agile is not a new word to the world of Information Technology. Automation has been said to be one of the key practices to making an Agile project possible. This in many ways may be considered true. I have been going through some good established practices of Agile, where most have been based on some basic level of automation, which helped in making a success of the project. I have penned down some thoughts on what it means to have test automation along with Agile practices.

There are many schools of thought which have gone into the agile way of doing a project and managing the various components that finally lead to the delivery of the project. When we consider Agile and its various derivatives, we come to realize that each Organization has their own way of dealing with the complexities that come with it. There is mention of starting with a session to discuss and elaborate on what the scope of the project is and how it can be broken into smaller pieces which then become the initial requirements. These can then be distributed to the team and made into story cards, attached with t-shirt sizes and put up on the scrum board to be picked up in batches by the team and worked on. In this fashion, a project progresses with the minimal of friction  and gets completed within the estimates provided by the t-shirt sizes. Most of the time this might not be entirely true, but this is how some Organizations perceive Agile and practice it; in the process giving negligent time for the automation, as manual tests take up the majority of time to complete.

When we talk of automation in Agile, it not only consists of the testing component, but an overall ‘continuous integration’ component. From the check-ins, build, unit tests, defect handling, integration & system tests to the final deployment on the ‘test’ server for doing the User Acceptance Testing (UAT).  Agile shops majorly miss out on this flow which should be the first thing to be completed for a Project to perform smoothly through its life-cycle. There are a multitude of tools available for making these tasks simpler and more robust, to name just a few which I have used – Jenkins/AntHill, Maven/MSBuild/make/Ant, SVN/Git, JIRA/FishEye, Crucible, TOSCA/QTP/

In the path to Agile, we forget that we need to do the planning for automating our complete build-deploy process also and that includes the crucial part for integration & system tests. A thoughtful planning would be to make the initial framework using stubs for the interfaces and when these get built, replace them with the real thing. Often what I see is the perception that automation should be started when a clear and stable build is provided; yes, in a way this might be true, but not for Agile, where you really need to be agile and think on your feet. Start by implementing a strategy, wherein you have stubs ready and a CI platform available to make sure that testing can be done without code. This was the first lesson I was taught, we were to create test cases based on the ‘pseudo-algorithm’ and  the interfaces that we have written. The tests need to be developed in a way that all fail initially and as and when the code is delivered they start to pass according to the requirements provided.

If you have done this then you have taken that crucial step towards Agile automation, that will take you a long way in making the project a success for you and your Team.


What does testing require?

26 09 2010

Testing is not an easy job. In India, software began in a big manner due to the test capabilities that were advertised for gaining a ground in the software field. That does not mean that we were not making good software, but test capabilities were the ones which catapulted us. It is not as simple as just writing a few scripts in shell or for the GUI. As James Whittaker has written, in his article on testing, it takes skill and a good knowledge of the domain that you are testing for. It is tougher than development of the same. Developers need to know the technology and they know the domain. Testers need to know much more. They need to know the workings of the application and the domain, along with how the user will use it.

From the viewpoint of the tester, it is never just a small portion of the feature that is being done work on. He has to know what all inputs can come into the product/feature and what kinds of output are expected by the downstream/next to make it to work. I learnt it that way, and that is why I love the profession of test. I know the product from the user viewpoint and also from the viewpoint of the Dev (the inner workings). Along the way, I made a lot of learnings. Although I would say that I lost the ability to program in any specific language; I learned a lot about logic and analysis of a problem.

Along with the above, testing also requires a lot of understanding of the tools that you need to use to implement the tests. This may be in the form of commercially available tools (Mercury QTP, SilkTest, Rational, WinRunner, etc.) or open source tools (Selenium, Watir, Fitnesse, etc). You can create your own using scripting languages or regular languages. After testing for a few years on different technologies and platforms, you should be able to shift from one to the other, which is not as easy for the developers who are working on a particular technology, but they find it easier to shift domains. What do you think…?! 🙂

Coding continues…

7 03 2009

So continuing from the last logs position, my main work composed of jut running an already created test suite and manually checking various parameters and locations [myriad ones for the various products and pipelines] for the aggregated logs and aggregations based on business logic. The work was mostly labour intensive. And somehow I forgot in all that meddle that there is something known as coding too. Then came the mentoring part, where 2 more people were added under me and I had to inform and train them on the Logs and Stats products. There I entered into my passive mode more, as those two started taking up more work. I started entering into a state of procrastination.

The realization dawned on me when I came into the next project for Prediction of advertising came up and I was stil in this state and something important got missed by me. It seems I was not getting motivated enough and the innovative streak in me died with that.

My coding exercise!

3 03 2009

So I have embarked on a journey to find my coding skills and try to find where and how I lost them. The journey does not seem to be too long, as I can remember the last time I had coded something was around the time I left my last Organization. Coming into the new atmosphere, I think I somewhere along the line lost the charm to code and that took its toll on my coding skill and brought me to this space.

The exercise began with me trying to understand what was going on under the hood of something which we call the collection of logs from users and their analysis and loading into the databases. The data is then given to the strategic data services, who do the data mining and get to work on analysis of how to make things better for our customers so that their ROI goes up and becomes better.

My main duty was to take care of this pipeline (or various pipelines for the different ways in which we collect the logs) and make sure it keeps flowing and garning more data about the various activities going on, in this somehow I lost the interest to code and innovate on things… [i think the right word was inovation]

HR Woes

27 12 2006

The major thing with HR in every Organization is that they are very vindictive. I have encountered HR and had major tiffs with them in almost every Organization and the only place where I found them to be accommodating was Macromedia and then later on in Solidcore. Here, the major reason was that all our activities were taken care of either by the Administrative Staff or by our Managers, who went by what we had to offer in our skills and not what we did in our previous companies and why we left and why and why… !!
The basic premise of the HR these days is to find out more on a psychological manner as to what is the nature of the person they wish to recruit. They have forgotten that the person might be more interested in getting his work done than to cater for their regular laments on the person not having a good degree or a good company name behind him. Now, I ask these people, do they think that their own company has such a good brand name? Why most of the companies these days are just coming up in their space and are almost unknown; why then do they go about seeking people who are coming from good brand names? The work being done is and should be the main concern and not the lure of a big brand name.
Then again there are those HR who do not even seem to care about what is going on with the people they have to get recruited. I encountered a similar fate in AMD, where the HR after informing me that I had got through and the offer was ready for me to sign on the dotted line, never got back to me. All he could say was – Oh! I was on leave [ok, you were, but atleast inform the next person that this candidate needs to be informed] or the MD is not available and I have to check with him [even when the last time he had said that the MD was on his way back the same day and he would give me a ring as soon as he came in]. Now this is not what I call professionalism, is it??!!

Then these people ask us as to why we are leaving the previous company, well! you are the guys who are keen on making me leave by offering a new post and better money??!! Why not leave? And then when we want to leave your company, you make all sorts of fuss about it and don’t even allow us a decent exit. You want us to join the next day, but while leaving we need to give a thousand days advance notice and even then you create so many hurdles in the way that we are unable to peacefully and amicably exit. Why! That is all I wish to ask you guys!!

What we do!!

2 04 2004

I have started work on a new concept in the development arena. It starts with developing something which inspires you to create something which just kicks ass!! I have gone through that experience and have regretted that… 😦
My Manager is a real good disciplinarian and I give him full credit for making me into what I am. I have been brought up in a sheltered and disciplined environment by my parents [especially Dad] and till I don’t have someone to force me I tend to slip. In work, my Manager came to know of my this tendency fast enough and got me in the right track fast enough. I have realized that in Software documentation is the first thing and then are the logical and analytical abilities which come out in the form of comments to the code. Code should be the last thing in a developers mind. If he gets his basics right in comments, code will be a breeze!!
Do/Will I follow his principles when I advance??!! I sure hope I do…