Nishant Verma

I keep hearing this term through out the day and wonder if there is anything called QA velocity. How we measure QA velocity? Is it just by the number of points signed off by QA team in an iteration or averaged over few iterations . Or is it more of a expectation setting? Just to inform that QA team doesn’t act as a barrier. Testing and Development are no separate process. Generally the QA team is involved in a series of activity like writing test scenarios, preparing test data, doing dev box testing, build deployment, system testing, integration testing, exploratory testing, bug filing and regressing. As the number of activities increases it introduces a potential barrier too with itself. Some of the potential barriers are unstable build, lack of preparation while doing dev box testing, finding bugs in the later phase of testing, improper bug filing. All these things potential acts like a barrier or halt in signing off a story. Some of these issues should be addressed as a part of

As Shiv Khera says “ if you are not part of the solution, you are Problem ”. I admit being a part of the problem because I gave bribe once to an Inspector for getting my passport. I was seeing news on one of the channel which was flashing breaking news ; LK Advani talked about corruption in Congress Regime and Pranab Mukherjee hit back saying don’t forget your regime. Wow, these things have become breaking news ! I pity news channel. “Corruption” is not a relative word that I can say I am least and you are more. It’s a disease. It’s an individual responsibility to remain honest and promote honesty and educate others about honesty. All I see on news is corruption, scams, people hiding their faces on camera and politicians barking and biting at each other. Whether it is by a Telecom Minister at Central level or Karnataka’s Chief Minister retaining office after so many land scams, it’s a shame for the whole government and a country of 1.15 billion people. Are these corrupt people so hun

I talked about importance of regression testing some time back where I pointed out why we should have one and how to drive it effectively. As I spend more time doing testing and going through releases, I am realizing that we need something bigger than regression ( when not on happy path) . The idea of regression is to uncover most of the bugs in the application and get it fixed based on Triage parameters. Happy Path: Bug fixing rate is higher than the bug finding rate (in case of less buggy application). Sad Path: Bug fixing rate is constant and the bug finding rate is on a rise (in case of a buggy application). A project in either of the state can easily be identified by looking into the bug logging rate. Projects on happy path don’t need much attention and can easily be managed through regression phase. But for the project on sad path I would suggest to have a Stabilization phase instead of Regression phase. The notion behind Stabilization phase should be to be prepared for rele

I will introduce one tool here which I used to use frequently for verifying a website for any broken link - Xenu's Link Sleuth. It’s a simple and powerful tool. It is easy to use and provide a cool well formatted reports. Some of the prominent feature of this tool are: A Freeware tool Checks website for broken links Link verification done for         Normal links, Images, Frames, Style sheets, Script and Java applets Simple UI, better error reports Re-check of broken links Detects and reports re-directed URLs Supports HTTPS Nothing to install I will put one screenshot to which demos the same. More information you can find here .

We do Stand up or Scrum meeting to update : what I worked on what I plan to work today what is stopping me to achieve my goal It is like a synchronization point for the whole team, allows each member to know what others are working on. It gives a sense of sharing the commitment towards achieving a common goal. It helps to set direction for the whole team. Moreover it’s a ‘virtual’ team building exercise. It also acts as self check for individual to track their own progress. As stand up is attended by people from different background like project management, testing, development, it doesn’t really add value when we go too technical in explanations or when we pick up any discussions. Updates should be kept simple and straight and discussions should be parked for tech huddles.

I wonder how many of us are asked to stretch a little more, deliver a little more, work a little more; I guess almost all of us. I am not pointing anyone but I regret that no one told me to do better. I have interacted with many managers (or above) in my career till now but one thing which I found in common is “they expect us to do more”.  I don’t remember any instance where they asked to do better than just do more. I don’t know why but it’s strange that no one ever told me. Is it because that it is the easiest way to get things done and that too in a faster manner. “ Doing better ” comes at the cost of training, patience and sometimes a reduced pace which may not get accommodated in the today’s fast paced software delivery practices. This post is inspired by the Seth Godin’s blog .

I have been in Boston at client location from past few weeks for UAT Sign-offs. It was a good learning period. I learnt a lot in terms of what Client wants, how do they see their application coming up. I also noticed why they want few pieces to come up fast. I also notice how frustrated they feel when we didn’t match their expectations or try convincing them on something which we have messed up. I also learn that few things are logical and should not be explicitly the part of acceptance criteria or story. I remember an example when one of my QA manager (I admire him a lot) gave that to me. e.g. When you go to restaurant and order for ‘Dosa’ you don’t explicitly order the ‘chutni’ and ‘sambhar’. So few things are understood. And the same needs to be applied to other things as well. I learnt that standards has no boundaries. These examples can seamlessly be used from one field to another. I also learnt that its very clear to them that points is just for you (IT guys) and all they both

In a typical IT Outsourcing scenario, people  who will use software is different, people who give requirements are different, people who will develop the software are different, people who will test the software are different. So there are bunch of people from different background and skills working together to achieve a common goal – to deliver the software. So the most difficult task is how these people will be in sync. How the developer and tester will know what users want? “Business Analyst” are the ones who paint the application in a developer and tester mind. Let’s quickly take a look into Business Analyst role. Generally people like developers and testers need not be an expert at every aspect of software development, but one skill they should definitely posses is the art of analyzing. One need not be an analyst but should possess some analysis skills. A software development team needs an “analyst” who can translate the stake holders requirement into something which a develop

Neither bugs are purposefully introduced in system, nor any test case targets to find a bug. A good testcase is always written to test the functionality and it should be encouraged. A tester should always intend to test the functionality. Bugs are small mistakes and some times result of not properly analyzed stories/scenarios. Moreover each level of testing whether unit or dev box or regression tries to uncover these bugs at different level. So the skill of a tester should lie in writing efficient test cases and he/she should be intelligent enough to prioritize which test cases to be executed earlier. It’s important for a tester to give feedback early. Two sides of test executions are : 1) blindly executing tests which are not likely to find bugs neither developing any confidence in the system 2) executing a set of prioritized test cases which will uncover the functional bug as well as create a confidence in the system. So a tester should be intelligent enough to decide between the

It’s a general perception that manual testing is not a challenging and tough job. Anyone can become a manual tester, I don’t agree! Automation testing can never replace Manual Testing. Manual Testing is an un-paralleled activity in software development life cycle.  With my exposure to this field let me put down some characteristics which I feel a manual Tester must have: Focus: When an application is given to a tester, it happens quite often that he will slip from one feature to another before completely testing one. So a manual tester should be focussed and shouldn’t get drifted easily. Analyzing Skills: A tester need not be an analyst but should possess some analysis skills. He should be good at analysing the application behaviour. Apart from the application, a manual tester needs to analyze the failures/errors and impact of the failure on the system. He also needs to analyse the features before testing and come up with varied set of data required to test. Prioritizing: A

As a QA I have been logging bugs since 5 years. But what do we do with that ? A typical flow: If this is the only thing we need to do then why taking so much of pain to have a defect tracking system . To log a standard bug (Standard Bug= Broken Functionality), we need to write steps to reproduce, pre-requisites (if any), expected result, actual result, priority, severity, snapshot (if any), Test environment details and finally save it. This takes around roughly 3-5 minutes to log a bug. To say truth, I have never seen any report coming out of defect tracking system which is of use in analyzing the pattern of bug or finding out any trend in them. All I have seen apart from tracking usage, is the summary of bugs with count based on Priority and Severity. Is that the only purpose of Defect Tracking System? If that is the case then why not use a Google spreadsheet rather then investing money of the company and time of QA in a bug logging system. I am sure if we mine the data which i

I was reading an interesting discussion on some Testing website (discussion thread) which was about commercial testing tool versus the open source counterparts. Just to name a few and revising my own knowledge, some of the prominent software test automation tools are : QTP, LoadRunner, Rational Robot, Silk Performer, TestPartner etc. On the other hand the open source tools are: Selenium, Watir, Sahi, Cucumber,Frankenstein, SoapUI, Watin etc. No offense to the tools which I haven’t mentioned here. :) So when we have such a huge list of test automation tools, the question is how do we decide the test automation tool? It’s a very good question and should be asked always before finalizing the Test Automation plan. Depending on the project, a good test tool is the one which has: Support project’s Technical Requirements Multiple Environment Support Programming language: Easy to learn and use Allows Test Data Management Easy and structured Repor

When I think of Performance Testing, the response time is not the only thing which comes to my mind. Performance Testing should not be done alone to capture the response time. Based on the nature of application and it’s usage, minimally we should run two types of test. One to find out how many concurrent users the system will support for a given response time.  I have really seen a decline in the need of performing these kinds of test. Application Performance is not always about the response time of web service. As a part of Performance Testing, one should also run Soak Test. Soak tests are long duration tests on the system with a static number of concurrent users that tests the overall robustness of the application. The intention of this test is to identify any performance degradation over time through memory leaks, increased GC or any other problem in the system. To get the memory footprints of the application, we need to set up some specific counters in the server where the ap

I consider human brain as a self learning robot which has the capacity to imagine, to think, to compute and to do many more things which are just unimaginable. But to my surprise I have even find out many times brain couldn’t cross a little boundary. What is that little boundary? I am talking about “Assumptions” as those boundary which is a passive creation of brain without consulting anyone. I felt that whenever my brain gets a problem to solve, it creates the so called “No Entry Zone” surrounding the problem and that “No Entry Zone” is nothing but the assumptions. Something like the one below. Assumptions not only limits the way we think but also hinders the creativity and innovativeness of the brain. Some times we just can’t see what is obvious. Let me give one such example which I encountered while reading a book. It will be interesting if you don’t know the solution. Problem Statement: You have to draw 3 straight lines to connect the 9 dots. Now the moment we finish re

Being involved in Software Testing field for quite a some time,  I felt like blogging on what makes a software tester life easy ! It can be anything depending on the projects you are involved in and the typical activities you carry out in your day to day testing life. I have always felt a little pressure on the testing team specifically in the agile methodology; a constant pressure of catching up with QA velocity or story sign-offs, planned regression cycle in between the Iterations, writing test scenarios, writing automated regression suite, continuously improving the smoke test (in terms of coverage and execution time), planning customer showcases. Oh God, so much to do in such a less time !!! I felt that there are few things irrespective of project which will make the life of a tester easy. Tester spend a lot of time deploying application (Unless they are using a Continuous Integration tool) and doing general sanity (in case the regression suite is not sufficient). Few things whi

When I searched for the word ‘ similar ’ on the website http://dictionary.reference.com , I was shown the below result. Well it’s not that I was not knowing the meaning of the word, but just wanted to see if any new context has been attached to the word. Thankfully I am not out dated. How it happened: I was browsing online to buy a book ‘ iWoz ’ on the Flipkart website, searched for it and got the result in positive. Nice! To people who don’t know Flipkart, it’s an online book buying shop launched in 2007 but has gained popularity recently due to it’s nice organized structure, easy payment system, good customer Service. Now when I searched for the book, in addition to the book result, it also displayed a section ‘Purchase Similar Books’. The books listed under that heading forced me to look out for the meaning of ‘similar’, it was show confusing! You must be guessing what all books were displayed, let me show you the snapshot. Take a look at it and let me know if you can find a

I am a normal internet user accessing Gmail, Facebook, Google Reader, Google Talk and many more public facing websites. Like me there are many more users using the same application, same features and infact pressing the same key. This blog is to to share my views on how actual Usage pattern of application should help in optimizing the Testing activity.   In any application, there are some features which is used heavily by the users. This not only applies to software application but also to hardware devices like keyboard for example. “Enter”, “Space”, vowels key etc. So knowing in advance that which features gets more load (in terms of usage) and which will get less load will actually help us in planning the testing around that area. It will also help in prioritizing (among list of features) the testing activities. Those areas should be majorly focussed while testing and (from a tester point of view) any bug left or ignored in that area has a higher probability of getting caugh

When I started my career in Testing, I was given a 40 page RDD (Requirement Definition Document) and was asked to understand it and start writing test cases. Sounds crazy isn’t? Anyways I am not discussing here how to write test cases, rather on the way of writing test case. Test case writing is not an easy job! It reflects the testing style of a tester. Intent of a test case is to discover more information about the system. So the way we understand test case is : some set of goal oriented steps, accompanied by test data (if any) and the conditions or pre-requisites followed by the expected result. If we give the same feature to different people for writing test cases, we will see a different pattern. Those patterns differentiates a tester. Almost all will have a mix of Happy/Sad/Bad test case but the proportion will vary from tester to tester. The intent behind writing a test case is to make sure the intended functionality works. Also we have a mix of negative test cases to assu

Software Product is a bunch of functionality assembled together and tied within the boundary of business rules. Each line of code which is written to implement a functionality has a potential bug in them . And each valid bug raised requires a change in the code written . Are these forming a vicious circle ? Let me explain. In a typical agile methodology, we write the Unit Tests first and then the actual functionality. So that means we actually know how the system would be tested (to some extent). But after writing the functionality, the developer calls a fellow tester to do a Dev Box Testing. Dev Box Testing is generally done on a developer’s machine with a very minimal set of test data (Thanks to developers laziness ! :)). It’s done to ensure that the intended functionality is properly developed and there are no major bugs. It also gives developer the chance to debug the application in case of any exception (if encountered). So till now we have done Unit Testing and Dev Box T

Folks ThoughtWorks is organizing a Quality Analyst meet on 2nd September 2010 . Hope you guys are aware of the event. Do register and attend in case you are looking for some good discussion and talks on Testing. Hi, We are delighted to invite you to a Quality Analyst Community Meet at our Koramangala office in Bangalore. This conference is a platform for our peers in the software testing industry to strengthen the QA community by sharing and learning new practices and ideas. 'QAConf' offers a unique opportunity to interact with people who are equally passionate about software testing and continuously strive to better the art. The format of 'QAConf' is scheduled such that each speaker will have 25 minutes to present followed by a couple of minutes of Q & A with participants. The topics covered in this workshop will be appropriate for any level of testing experi

“Cool nice symbol” , these were my first reaction when I got to know that Indian Rupee has finally got it’s symbol. Even though the party was not over, the problem was how to put that into keyboard. Sunday Morning –> Times of India –> First Page Bottom Section, we have the problem solved (even though temporarily). Nice ! Some company Foradian Technologies has done it by creating a font called Rupee-Foradian. Superb Job ! If you want to use it straight way in your word documents, then this is how you can do it. Step 1: Download the font from here . This will open the Foradian’s page. Step 2: Copy the font to folder “ C:\Windows\Fonts ” on your PC\Laptop. Step 3: Map it to the least used key ‘ Tilde ’ on your keyboard. As suggested by the Foradian CEO, use the one above your Tab key. Step 4: Open Window Word. Enter the Tilde key. Select it and right click and from the options available click “Font”. Step 5: The first drop down ‘Latin Text Font’, scroll to find ‘Rupee Fora

Showcase is very important in agile product development. It lets the product development team project the work they have done so far in front of the stake holders or the potential end users or business users. Primarily showcase is done to take early feedback and reduce the last minute surprises. It’s also done to find out if the Product Development team is building the product right. Why some of the show case results in too much of feedback/comments or sometimes creation of some other story cards or Change Requests? This blog article is to share my views and opinion on the same. Ideally when business analyst (BA) write down the narratives or story, they generally get it reviewed by the client. I suppose the BA do their homework before presenting the narrative to the client. So the question is even though the narratives are approved by the clients, why the showcase fails (a harsh word to use) ? There could be many reasons but as per my understanding I feel there are only 2 prominent

It’s almost been a months time since I wrote any blog. I am happy to share that I stepped into a new phase of my life, I got married. In this almost one month of vacation I spent a lot of money on buying jewellery, clothes, gifts and random shopping. After coming back to Bangalore, I am again in touch with blogs and articles and I was just glancing through an article on “customers, buying patterns, brand value” etc. Then I started thinking how do I choose what I have to buy? Do I get influenced by brand name? Do I get influenced by what my friends/colleagues are buying? Do the advertisement creates enough confidence in me to take a chance in buying a new brand? So basically how do I choose? These questions applies to a range of products varying from stationary item like a pen, household items and even to electronic items. I believe all product companies create products thinking the customers will use them, either it is Reynolds or Rotomac  or Maxwriter making pen or Nokia,Samsung,L

Why regression testing is important in Agile methodology? Agile testing requires me to test iteratively the newly developed code and at the same time making sure the old implemented functionality is intact. Following TDD or writing unit test just helps in achieving an automated low level regression test suite. But it cannot be used alone in Agile. After every 2 or 3 iterations there should be a regression planned, I believe. During iterations, testers mostly focus on the story testing and the edge scenarios remain untested sometimes (primarily due to pending story development).  So how do we do regression testing effectively. Regression testing is not just about selective re-testing, it’s also about achieving the test coverage. So the big question is how do we go about it. In my previous post I have written about how do we segregate test cases in happy, sad and bad path test cases. So what all to be picked up in regression testing? Should we target testing all the test cases? Can we

Looks like weird title but true for me! I remember my life some 3 and half years ago when I was happy with my Sony Ericsson mobile phone. It was a routine activity for me to get ready, go to office, do some testing and come back home. I was not an avid reader that time, mostly I used to read non fictions. Then one fine day I was attending a business presentation which was about booming mobile application industry. The last slide was of a guy who was sleeping on bed and there were lots of mobile hanging on top of him (trying to convey that think and dream only about mobile, that’s the future). It was an impressive presentation which talked about mobile world. As a result of that eye opening presentation, I started reading few blogs and some mobile related websites. After some months time, I realized that the actual culprit is iPhone. Before iPhone there were mobiles phones which people primarily used to make calls (STD or Local) or send SMS, listen music, take pictures. Apple guys

Morning when I get up, I have Times of India newspaper thrown up in my balcony. And as I start reading through the pages of newspaper I get frustrated. Though not all the news are sad but some are really so much frustrating. I really feel frustrated and pissed off.  When can I get to read about the positive things which government do, works they do to make our lives better. I hardly read any such news.My news paper is full of scams, scandals, across the border talks and nothing which actually evaluates the work of government and last but not the least full page advertisement. Some news which just puzzles me are: Welcome to Front Page of TOI [ Brothers & sisters from Pak ] We are eager in making peace from neighbourhood but not really addressing what is happening with in our country. “Aman ki asha”, Finance Minister addressing it, IT czar addressing it and many more to the list. Then is the news of Naxals killing innocent people. “We are ready for talks with them”. Why talks a

I generally hear a lot of noise when it comes to Performance Testing. “Big word” but mostly used with utmost carelessness. What is Performance Testing? Why do we do Performance Testing? How it should be done? What should we capture? What will be the outcome? Well I am not going to exactly answer each question, but assure that by the time you finish reading this blog I will give you a clear picture of Performance Testing. I hope all my reader friends are aware/heard of Performance Testing . Performance Testing may be done on components or on the whole application. When I say component I refer to the web services, window services, etc. But before diving straight into the world of Performance testing, we should ask ourselves few basic questions. Do we have any SLAs (Service Level Agreement) to be met? Do we need to identify and fine tune the bottle necks? Do we need to find out the scalability of the application? Do we need to find out any memory leakage? Is the app

While doing testing I often found some bugs which gives me some clue about why it occurred in the first place. Being a tester do we just need to find an issue/bug and report it or should not we do some initial investigation on the bug (homework) before logging  it. As per my understanding bugs are a result of misunderstood functionality, edge scenarios which was not thought of during development, improper data handling and finally the border issue (integration point with some other story). So being a tester we should not only find bugs but rather give inputs in such a way that it helps the developer figure out the fix in a faster way. Implementation of logging in the application is one such attempt where we can guide the development team for more informative logging. Exceptions should not be suppressed while logging also it should not be overloaded. In case of Data handling issues, QAs should be  proactive enough to put some effort of playing around with more varied set of data so as

Agile Testing ? When I looked up dictionary, I found that agile means “ moving quickly and lightly ”, and the whole crux of Agile methodology lies here. To re-iterate agile focuses on building smaller chunks (Story), getting it tested, showcasing it to client, implementing feedbacks/suggestions and moving to the next story. In this rapid development environment, testers role are a little bit different. Agile testers are required to test the product from client’s perspectives rather than doing ad-hoc testing. Generally we (as in typical tester) hold the product too tightly. Typical goal of a tester would be to stick to the Software Requirement Specifications (SRS) or Requirement Definition Document (RDD), prepare test cases with a constant mix of positive and negative test cases and finally execute them. In agile testing, we have a little diversion in each and every phase of STLC. While writing test cases we have a mix of “ Happy, sad and bad ” path test cases. So if all the happy test

“ Testing shows the presence of bugs and not the absence of them .” I read this somewhere and I understand it otherwise. When I am assigned on to the task of testing any module I make sure that I leave not even a single bug. I take pride in saying that “once I test it, you will not find even a single bug”. This is my perception of testing. So the question is how do I motivate myself for this task. To many testing sounds boring and un-challenging (views from some of my colleagues and some online data), I don’t see it that way. Testing to me actually requires a high level of aptitude skills , ability to think through and above all make decisions . One need not be proficient in C# or Java or QTP to be good tester. In my point of view, Testers should have the ability to “comprehend”, the desire to go an extra step to uncover things but unfortunately I don’t find these things in any of the interview. Testers should not only test the application but should guide the way an application i

Story as we know in agile is a light weight requirement. It is characterised as independent vertical slices of functionality which can be estimated and tested. So a typical story has a business scenario wrapped up in limitations and acceptance criteria .  Acceptance criteria are the happy path test cases , which ensures that when a tester signs-off the story, it delivers what it is intended to. So as a tester what should we do, just limit our testing to the story? Generally, bug is not in the standalone system, it generally gets discovered when a system interacts with another. Whenever I think of story testing, first thing which comes to my mind is the Pepsodent advertisement. Sounds weird? Let me explain, I consider story as a tooth and when given a perfect piece to you, one may not find any germ (bug in this case). But when a tooth is next to another or let’s say when a story interacts with another story, there is a chance of finding potential bug. Germs always hide themselves

The backbone of agile methodology is the fragmentation of a complex task into a small components. As a result those development of small components leads to iterations . So a typical project of 6 months is replaced with 12 iterations of two week projects. So we finish one iteration to measure what tasks we achieved. Now agile is a Software Development methodology with many methods and set of good practices, Scrum is one of such agile methods. In scrum, we generally have Sprints which is the name given to the iterations.  A sprint could be of 1 week to 4 week long. One thing which I forgot to mention is that the success of project execution using agile methodology largely depends on the team. Few words which would be typically used to describe those teams are cross functional, self organized. It’s a very much disciplined team. The team should not have a typical PM who decides who has to do what, rather this call is taken by the whole team. BA’s and scrum master though play a sign

It’s been more than four and half years since I am involved in QA activity and have executed quite a lot number of projects varying from 6 months duration to 2 months. Most of those project execution was based on Waterfall model and Iterative model . One question which keeps coming to my mind is why different companies follow different software development models? Does it really matter to the end users or Client or Stake holders, if you have followed typical waterfall or a fashionable agile model? Why would they even bother about that as long as you are giving them what they want (Quality Software) and on time (satisfying their “Time to Market” clause)? They might be interested in the success rate of the projects which followed “A” methodology or surprised by the “X” amount of overhead some company is charging which follows “B” methodology (which is based on some of the best engineering practices for rapid and high Quality Software Development). Software is an evolving field and so

How much automation coverage we should have? Why to automate something when we are not going to modify it in the next 2 iterations? Why not automate only regression scenarios? My automated tests do not catch bugs ! It’s a very complex manual testing stuff and takes me a considerable amount of time to execute it, so I want it to get automated ! Well these are the typical questions which I always get to listen in any meeting which talks about “Automation Coverage”. Why such a bug fuss around it? I have worked on several project which ranges from pure manual testing to pure automation testing. So before starting to create automated test we need to answer few questions. Why are we automating? Is it a deliverable to client? Is it to create a “Safety net”? Is it to ensure sanity of the application before the build formally comes to QA? Is it to reduce manual testing effort? Is it to catch bugs? All of the above Once we answer these questions before rolling out the automatio

I came back from the background of writing test cases which were categorized in either Positive or Negative test cases. Positive test cases were business flows which may or may not give any result but they will certainly not give any exception or error. Negative test cases are those test cases which were bound to result into some exception or better expressed as error causing scenarios.  Then those positive test cases were prioritized as High/Medium/Low . Finally it used to result in quite a comprehensive test case document. Then it will go through the process of review and few more updates or change of priority etc. Certainly it is a tedious process. Here in ThoughtWorks I got introduced to different way of categorizing test cases called “ Happy/Sad/Bad ”. A test case which results you in a positive result is a Happy path , for e.g. entering proper username and password on login page. A test case which yields no result like entering invalid username and invalid password on a logi

It’s quite some time since I  am learning the process, terminology and environment here in ThoughtWorks. When I entered the company one thing which I found very weird was postcards on wall or board. These walls are called Story walls . There would be some heading and few postcards under them in yellow or red or pink colour. Then around 10 am in the morning I see bunch of people standing next to the wall and speaking one at a time and then they would move some card from one column to another. I wasn’t understanding what is going on ???? But then during my boot camp session I was told about something called stand up meeting and those postcards are nothing but Story cards . To those who are pretty old enough in Testing field and very new to Agile methodology , Story card is a way of representing a small implementable unit of a feature . Even a bug can be a put up in a form of card on the Story Wall under proper column (probably Testing). I have put down a image at the bottom of this art

It’s been 2 weeks into my new office ThoughtWorks Inc . One thing which I felt was the core of  each and every discussions or seminar is Agile and how we practice. Many people across the company with various exposure and experiences spoke on agile with their thoughts and view. I noticed that there is no fixed rule or set of guidelines. I would say agile methodology is still evolving; there are some guidelines which people follow and adopt over a period of time by experimenting and then filtering out the best, which suits the project and easy to adhere. One things which people emphasize here is to read which hardly we do being in IT as we have done enough reading of books (in 4 years of Engineering or 3  Yrs of MCA) which has get us to this platform (Just a joke :P ). But I seriously feel one should read a lot and practice to sustain in this industry. I am sure if not many atleast few techies are doing it and practicing what they have learnt. I will keep on posting things mostly a