Testing at start ups

Testing and beyond at startups from Mona Soni

Effective BDD with Cucumber

After attending couple of events in last few months I came across the reality of our BDD world. Most of the teams that use cucumber or any other BDD tool have adopted them as QA tools. There developers or business or product people never look at these tests and are sole responsibility of QA team. Does this sounds familiar? do you do it the same way? is cucumber killing you?

        BDD is an evolution of TDD and by definition it aims to help focus development on the delivery of prioritized, verifiable business value by providing a common vocabulary that spans the divide between Business and Technology. There are various tools and frameworks that can be used to implement BDD and cucumber is by far the most used.

Before you decide that cucumber isn't the right option for you, lets analyze different reasons that make  using cucumber less effective:

1. Test written by QA team only: The biggest advantage of BDD is in enforcing more collaboration amongst different roles in projects. When developers are not writing a single feature test, then there is no behavior drive development and the collaboration is not achieved. The tests in this scenario will be regression tests and not inline with the system design. 
2. Test written only by Developers: Again we loose the collaboration aspect here but what we lose more is the user intent. QAs bring the user aspect to software testing, with QAs input we can avoid writing scenario that end user will never face and hav better user experience implemented in our system.
3. Product Owners: In an ideal scenario in BDD world we expect BAs or Product managers to write feature tests with QAs. But I haven't seen this model being successful anywhere. I haven't seen any product manager buying this idea ever. The best option to get the business intent into our tests is to have clear deliverables and acceptance criteria in our user stories. These can then be translated into feature tests by QAs and developers.
4. Regression suite: Cucumber tests are very valuable in providing feedback and they majorly serve the purpose of testing various integration points in your system. Using them as regression suite by testing all possible negative use cases will not be fruitful. The well known test automation pyramid recommends the amount of integration tests should be around 5-15 % of entire tests and this applies to cucumber tests as well. 



Automation Pyramid

5. Java script testing: With the ever rising popularity of selenium-webdriver the amount of java script testing in cucumber testing is also very much in practice. I have even seen team duplicating there entire tests to run against IE. Just because the tool supports these features doesn't guarantees return if used at large scale. Java scripts test in selenium have been historically brittle and will continue to be. The effective way is to use a Java script testing framework like Jasmine and few end to end tests in Selenium to test the UI.
6. Test Case documentation: While writing BDD tests we don't add comments to our tests as the feature tests serves the purpose of documentation. Doesn't this applies to your manual test cases? Teams use test case management systems to document there test cases, with BDD you should get rid of that as well. Cucumber features are very effective way to manage test cases that are regularly updated without any extra effort.

BDD is a great practice to make your development cycle effective and cucumber is an amazing framework for writing tests and collaboration. You just need to do it right.

Brush Strokes

I have been in love with colors since my school days. In school it was more for the competition and prizes. There was a time when these prizes got annoying as there was not enough room to display them in our living room, given I was sharing the space with my sister's trophies. Eventually all those trophies landed up in a box packed nicely to be never opened again. After school it was college functions and I still remember the 10'*10' painting that we made it was incredible.Wish I had a pic of it with me. But now after all these years painting is now a means to relax and calm down. 

  I am happy that I was able to paint few pic in recent years unlike my sister who is better than me in painting but busy enough with her cute daughter. I am not that good to paint something imaginary but good enough to take inspiration from a click. I have experimented with what I have been painting and the results are interesting.

This is my first attempt on canvas and I loved doing it. I wanted to add some bright colors to my living room and what better than your own work. 

This is a pic of girl performing Rajasthani dance Ghoomar

I have painted a lion face and a tiger separately when I was in school and really wanted to do them again. Although these Lion and Tiger look kind of cute than wild!

This scene is from a hilly area in northern India and one of my friends posted this on facebook and I liked the snowy mountains the most and tried to create the same effect here.

This scene is again from a facebook share, the dark forest view seemed quite challenging to create and was tempting enough to try.

This scene of a village in Punjab, India was from a wall hanging in my room. I have always drawn village scenes since school and are my favorite.

Being a Rajasthani I have grown up with these scenes but missed them while I was away for work. Trust me women carrying these pots for mile to get water is still part of daily life in Rajasthan villages.

As much as I love wearing traditional clothes I enjoy painting women with these dresses and the fall effect I get to create in their skirts. This was form a 2010 calendar and depicts the pre historic era of central India.

Choosing to be a tester!!

          During interviews I have always come across candidates who wanted to be developers but landed up in QA somehow or they started with QA considering it to be an easy job and want to move to development as they gain experience. I have always been supporter of changing profiles, trying different roles but this one not so much. As those I have seen taking this path are mostly doing this because either they think developers have better roles then testers or they think development is too difficult. According to me if you are working as a tester and believe in any of these two then you probably don't know your art well enough.

          I didn't chose being a tester or would say that was the only road I had seen in my initial career. And I am happy that it out to be the right choice. But what about those who have choice? Given that the average developer to tester ratio is around 4-5 developers per tester, there are good number of testing jobs in the market. And the testing community is definitely in need of people who are passionate about their work. I am highlighting some points that I like most about being a QA:

1. The Role : I prefer to be a QA then tester, here is a great article by Alan S Koch on Testing vs Quality Assurance. All the projects that I have worked my role was never limited to software testing. As QAs we are responsible for varied tasks ranging from software testing, writing automation code, creating test systems, data analysis, requirement analysis, release planning, risk mitigation, iteration planning, reporting, training and many more that varies with teams. We are the gatekeepers, our role is to assure quality of the whole product which is not limited to navigating through the application and writing code.
2. The Work : As a QA my daily work involves both manually testing the functionality and writing automation code. I was once working with a business analyst who had recently moved from QA role, he confessed that he missed writing code. QAs understand the functionality and usability of the system, sometimes more then the business analysts. I have always been excited about exploratory and manual testing as much as automation aspect. I have seen people jumping to automation in the first week of their job, which always wonders me that how in the world can anyone do automation without understanding the application? These are the people who say that manual testing is boring but because of their lack of application knowledge are not able to get good code coverage. 
3. Quality : I have never been a bug hunter, not that I don't find bugs. My aim of testing had never been finding bugs but to assure quality of the system. For me bug count has never been the metrics for evaluating the performance of testing team. Instead how early the testing team can provide feedback once the work is done is the true performance measurement. This approach works really well and dramatically reduces the number of bugs found close to release or in production. Earlier the issue is found and fixed lower is the cost incurred and better is the quality of the system.  
4. The Team : I have always enjoyed working in collaborative teams where I can talk to anyone at any point during my work. Creating protocols for communications reduces the work throughput. QAs always seek answers for their never ending questions to developers and product managers. Teams where QAs are supported well tend to perform better and are more efficient. But its the responsibility of testing team to make sure they are not bugging people with irrelevant question s which can affect the trust in the testing team in long run.

 My experience as QA/tester had been amazing and it's definitely a great role with lot of opportunities in the software industry. Its the responsibility of us who have been in this profession for long time to help and encourage new talent to learn the art of software testing.

CAST 2012 - Day 2

Another day full of learning, fun and meeting amazing people. I have never been around so many smart people where every body is talking about testing. Talking to different people coming from different countries with completely different ways of working but the same goal - how as QAs we can help our organizations and people around us? These conversations have helped me clear my thoughts and re-affirm that the way I am working in my projects is the right approach. 

          Day 2 had more of workshops lined up then day 1, which makes it more difficult to chose which sessions to attend. I was introduced to Anna Royzman the day before as she also is based out of New York and she told about her workshop on Thought Provoking Leadership. I decided to attend her workshop for the first half of the day. In this workshop divided in different groups we used the Empathy maps from Game-Storming principle to understand the stake holder for a product and his needs as a stake holder. 

         We used the travel ads product that we have at IntentMedia to draw the empathy map in our group and we considered the customer who sees the ads as stake holder. I learned about our actual end user here more than I could in more than a year that I have been working at IntentMedia. 

           Post lunch and post the iPad draw(I didn't win :( ) the keynote was delivered by Elisabeth Hendrickson. She talked about the theme of the conference 'Thinking Tester' and I couldn't have agreed to anyone else more than her on the topic that testing is dead. She started by explaining the testing in current perspective as  'Any activity that yields empirical evidence about the extent to which our intentions, our implementation and the actual business needs are aligned'. Most of the people think that testing is just checking but a code is tested when its checked and explored. Exploratory testing is a very important aspect of testing. Therefore a 'Thinking Tester' has following traits: analytical, relentlessly curious, observant, skeptical, empiricist, critical thinking, investigator. The next point that she mentioned was very true with how I think of my work and have been doing it for past 5 years. We in our jobs as tester are not only testers, we play different roles of Product Owner, Programmer, Architect, Project Manager and many more. She closed her talk which I believe explains how the testing community can continue to grow and play that important role in organizations: Testing is not Dead. But the Context continues to evolve, and so do we. Great close to one of the best talks I have ever attended, here are her slides for reference.

            The second part of the day was again a workshop that helped me understand better my work as a service to various stake holders. Lynn Mckee held the workshop on topic Thinking about Testing as a service. During this workshops in our group we brainstormed about what we think Testing and Quality Assurance are. Often the terms that we used daily in our lives are often misunderstood and continue to be ambiguous. Next steps was to understand various stake holders for testing service in a project. These stake holders as we discussed usually are Programmers, Project Manager, Product Owner, Fellow QAs, Share Holders, Customer, Operations and many more. As QAs we directly or indirectly offer our services to each of these stake holders and this makes our job more crucial and important. Lynn has a great website which provides huge resources that would be helpful to any tester to improve his daily activities.

         During CAST welcome note on the first day it was mentioned that in all other conferences evenings are very dull and everybody retards to their rooms but at CAST they have to ask people to go back to their rooms as it was late at night. Through tweets I found that even the first day there were people till 1:30 AM playing testing games. Therefore I decided to stay back the second day to find out more about these testing games and was there past 11 PM. 

We played different games for more than 4 hrs, it was fun and yes there was so much learning from these games.

CAST 2012 - Day 1

The day started with a quick introduction and welcome note. Other conferences that I have attended  the Q&A time is always around 5-10% of session time but at CAST after each talk speakers are given 25 minutes for Q&A. The total time for a session is 75 minutes and if groups wants the discussion can be further extended. This made all the sessions very interactive and led to great discussions.

 The next surprise was facilitators role,  I haven't come across any conference with such an amazing session facilitation. I always thought facilitators job was to just introduce the speaker but today that belief was shattered. At CAST delegates are given three different colored numbered cards which they can use to ask questions. During a session they show a red card if there is an emergency for example speaker cannot be heard or a green card for any explanation but no questions. In the Q&A session when a green card is shown facilitators notes down all the no.s in the order hands are shown and takes the questions in that order. If someone has a question or comment on current thread a yellow card is shown. This helps a lot and conduces a healthy and consistent discussion without any one hijacking the thread and gave everybody a chance to talk in depth about a topic.

  First half of the day I attended the workshop Brainstorming for Testers by Karen Johnson. This was a very interactive workshop with interesting exercises and was based on the Game-storming principles. Game-storming is a set of practices for facilitating innovation in the business world. A facilitator leads a group towards some goal by way of a game, a structured activity that provides scope for thinking freely, even playfully. Karen talked about Beautiful Testing her book, mental locks to overcome as a tester, the importance of notes taking, how mind mapping is helpful in brainstorming process and the importance of asking questions in software testing. We did few exercise which were fun and learning, let's brief these:

1. First exercise we were given a piece of paper and each one wrote whatever they could think of work related or personal stuff. This exercise helped us to align our thoughts and gave a clarity about each topic. I would recommend  doing this whenever you feel you have too much in your head as this definitely helped me clear my mind before other exercises.
2. For second exercise we divided ourselves into groups and had to come up with a testing problem.  After this we were given a deck of testing heuristics. Test heuristics are kind of cheat sheet to use any time during testing, for example : cidtestd = Customers, Information, Developer relations, Team, Equipment & Tools, Schedule, Test Items, Deliverables. James Bach has been advocating use of these mnemonics in testing and recommends writing your own. We used these mnemonics to apply to our testing problem and come up with a prospective solution.
3. The third exercise was using Phoenix Checklist to solve our testing problem. Phoenix Checklist which was originally developed by the CIA is a thinking tool that gives you multiple creative options for problem solving.  Following are a few examples of the questions on the checklist:

           * Why is it necessary to solve the problem?
           * What is the unknown?
           * What is it you don’t yet understand?
           * What isn’t the problem?

Post lunch was the key note on 'Re-Thinking Management…Re-thinking IT' by Tripp Babbitt and few emerging topics. Next session was Foundations of Facilitation and the Tester’s Environment by Chris Blain & Ben Kelly. They talked about how as a testers we can facilitate the team in such a way as to allow the team to solve their own problems. Few points to be considered are:

Positive Environment: Always emphasize on improvements rather than blaming for an incident in the team. Create an environment free of fear and encourage people to try new things without being scared of failures. John Cleese talk on closed and open mode is very helpful in defining the working environment for maximum creativity : 

• Closed Mode: Purposeful, highly productive, but not creative. Good for getting things done. Usually the default Mode at Work. Should be the right approach when you have a specific task with high priority to be completed in a constrained time.
• Open Mode: Playful, curious, fun, humorous, relaxed, contemplative without goals. Relieves the team of pressure and provides opportunity for creativity and innovation.

   Difficulties faced when driving change: Credibility, hierarchy, power dynamics, Apathy and fear. Changing the physical space brings a big change, in our own office having more open space and our little dogs running around relieves the tension and creates fun environment. Now I will get some sleep for the next fun filled day at CAST.

CAST 2012 - learning spree

I was sure this would be the highlight of this year and its getting exciting. I am here at San Jose CA to attend the 'CAST 2012 - The Thinking Tester' which starts tomorrow July 16 2012. 

I expected the Sunday to be a lazy one but it gave a glimpse of what next three days would look like. After breakfast we joined the #TestCoachCamp team for a small session and I am glad we did. Wish I could have attended the full session. We talked about the burn out among testers and how we can help others to get over it. Being a sole QA on a team of around 10 developers I can understand how an unmotivated burn out tester can never deliver best on projects. We discussed various approaches used by other delegates to get people going on their team and I agreed to each of them as I pretty much use them in my work daily. Here are the few that would help any QA on their teams:

1. Most of the times cause of burn out among QAs is repeatedly testing the same piece of software over and over again. Rotating people among various teams and modules on a regular basis will bring new energy and ideas.
2. This one is very prevalent in big teams and organizations. Testing teams during testing files bugs on a piece of code but they never get fixed because the development and product teams think that they are low priority bugs or they are labeled as invalid or not reproducible. This leads to demotivation among testing team and they often don't feel empowered to drive the quality of the software. QAs should be more specific in filing bugs, provide detail steps to reproduce the issue. They should work with product owners in advocating the priority and impact of bugs for a release.
3. Learning new technologies and automation tools & techniques is a great way to regenerate the energy in any engineering team. I have personally tried this and having regular learning session within the team could give a completely new direction to your burned out testing team.
4. Stand ups, tech huddles, retrospectives are the key to success of agile projects. But even the teams with considerably large QA members tend to ignore the issues testing team faces. Providing QA team with testing huddles and QA retrospectives gives a great platform to bring out and resolve the issues test engineers face on daily basis.

I would look forward to reviews of other discussion and learning that can be gained on other topics.

In the evening CAST celebration started with reception. Got to meet other delegates and Speakers, had some interesting discussions. Looking forward to the first day at CAST 2012....

Success - First encounter

    Yeah this is my first article that I wrote in Oct 2006. I had almost forgotten that I have ever written something like this. I found this article in my mailbox last week and had written this for an essay competition organized by CSR India. I would not lie but was impressed that I wrote this 6 years back and can say it was well written since I was among the top 20 writers in this event.

     Success comes with Ability, Boldness and Courage

              We were born to succeed, not to fail-- Henry David Thoreau

      These words are the basic underlying fact of growth of human civilization. Every step in evolution of man is a result of success in his constant efforts to survive. From the primitive wheel, to the pyramids, the epics, man’s first step on moon and to the genome engineering, mankind has made the best of what nature has bestowed upon us. Although we use only a fraction of our brains but we use it more than any other living being on this earth. Our constant efforts for a better standard of living have led us to explore each and every field and we continue to do so till we succeed. But to achieve success is not easy, success is coupled with failure. People get disappointed by failures but one should learn that failures are not accidents. Successful are those who learn from their failures. We owe a lot to Thomas Edison if it wasn't for him, we'd be watching television by candlelight. He failed a thousand times but his constant hard work led him to invent bulb. 

                So what success is all about? With growth of man definition of success has changed ever since. If we look back through 200 yrs of writing about success a startling pattern emerges in the content of literature. The success literature of past 50 yrs is superficial filled with social image consciousness, technique and quick fixes .Whereas the literature in the first 150 yrs focuses on the Character ethic as the foundation of success i.e. integrity, humanity, fidelity, temperance, courage, justice, patience and others. But today success has an altogether different meaning. One can not be successful just by following the foot steps of great people or by following certain ethics.  But we can certainly learn a much about success from history, from life experience and from myths. We can ascertain that success lies in our ability to access our personal talent, energy and to attain satisfaction and happiness. Success requires the courage and the honesty to unleash the awesome power of our natural talents and to illuminate the purpose that we were meant to fulfill. Thus the orthodox definitions of success have changed as our society has evolved from agrarian, to industrial, to knowledge-based. In today’s world the heart of true success is a sense of personal satisfaction. It is an accomplishment that is nourished and grows with purpose, vision and action. To summarize “Success is that old ABC-ability, boldness & courage” these words of Charles luckman define the modern secrets of success. 

 Ability: Success comes to the door step of that person who acknowledges his talent and focuses on true utilization of his skills. Narendra who was a boy next door until swami Ram Krishna Paramhansa enlightened him that he is able to make a difference to the sufferings of people around. Later known as Swami Vivekananda he said that the greatest sin is to think of yourself as weak. One should overvalue what they are and undervalue what they are not. Henry David Thoreau said that there exists no more encouraging fact than the unquestionable ability of man to elevate his life by conscious endeavor. Successful people are definitely not all-rounder but they discover what they are good at and try to furnish those traits. Sania Mirza is a successful tennis player, she is best at it but she cannot play cricket or any other game. True talent creates its own opportunities it lies in the person how he avails these. Successful businessman is one who has the ability to motivate his employees as motivation almost always beats mere talent. As motivation is about driving people and friends towards higher levels of efforts. Ability is what one is capable of doing and motivation determines what he does.

  Boldness: Skills are of no use unless one is bold enough to take a crack at them. Often talent faces a setback in shadow of criticism owing to timidity. Ramanujan was expelled out of his school on grounds of poor performance in studies but he continued his passion of playing with numbers and emerged as a legendary mathematician of all times. Boldness is having faith in your ability to do a work and being forthright to bring your talent in lime light. In order to succeed, we must first believe that we can. Yet being blind, deaf and dumb Helen Keller always believed her ability and continued with her zeal to become a graduate. Many a time’s brilliant students fail to achieve their goals on account of apprehension and fear a propos to skills .Nowadays many of the students commit suicide on failure. It was in news that a girl ended her life when she couldn’t find her roll number in the results of a competitive exam. It was later found that she had topped the exam and her name was there in the merit list that’s why she couldn’t find her number in the first list. Psychologists say that number of these kind of instances are growing and the main reason for it is lack of poise among students. Thomas Edison said that many of life's failures are people who did not realize how close they were to success when they gave up. Try until you succeed. 

 Courage: “Success is not measured by what a man accomplishes, but by the opposition he has encountered and the courage with which he has maintained the struggle against overwhelming odds” - Charles Lindbergh. 

       Any one can travel a road which is smooth and clear but great men are those who opt for difficult path, take a risk and strive to hit the highest point. One must have the courage to remain original, face odds and take reasonable and calculated risks to win success and stay in the lead. Henry Ford went bankrupt in his first year of automobile business and two years later his second company also failed but he didn’t gave up and continued with his aim and established his third company which is among one of the leading automobile companies in the world. His courage and right attitude helped him to achieve global success. Failures are part of life but successful person is one who goes from failure to failure without loss of enthusiasm. Abraham Lincoln failed in his business at the age of 21,defeated in a legislative election at the age of 22, lost his wife at the age of 26, lost congressional races at the age of 34 and 36, lost senatorial race at the age of 45 and again later at the age of 49, lost the race of presidential post at the age of 47, and finally became The President of United States at the age of 52. It was his doughtiness to  win that made him one of the unsurpassed personality of history. For him his failures were stepping stones to a future that he dreamt of.

 The world stands aside to let pass the man who knows where he is going. Thus to achieve success realize your skills, be bold and courageous. Face the situation, however difficult, with courage, conviction and boldness and you are bound to succeed. One should remember courage conquers, boldness pays and timidity fails. 

testing the Intent

      'You are the 97 percent guys!!!', sounds weird but I was delighted to hear this when one of the candidates at a job fair came to our booth and told me that he has heard about IntentMedia and wanted to know more about the company. He was also astounded like many others when I explained in detail that what as a company we do. If you are interested to know more about Intent Media visit www.intentmedia.com

            I have been working at IM for last 14 months as a quality analyst. Before IM I have had varied experience as a tester; testing the trading applications, web applications, CRM applications with diff integration points but the testing at IM is challenging. I believe a yearn to do something different as a QA has landed me here. IM like many other startups of NYC has a great culture and amazing set of people to work with but what I like the most is the problem that we are trying to solve here 'What to do with the other 97 percent?'

          We are an e-commerce advertising company. We work with advertisers to show their ads on publishers websites : Orbitz, Expedia and Travelocity. I would not go more into the products or the advertising details, instead would prefer to talk more about what I do at IM. 

         

           In any usual project as a QA we would test the website or the software designed but for us the software designed is ads not the website where the ads are shown. Hence the quality assurance would involve ensuring that our ads appear correctly on publisher websites. Now that would be the case for all the online advertising companies but where we are different is we need to match our ads with the publisher websites. Here the complexity of the system increases. Since we show ads on multiple websites we cannot have the same ads across the board, hence all the ads are designed and maintained with changing publisher websites.  I have always heard that in Agile projects also QAs complain that requirements change too often and its difficult to keep track of new functionality. At IM since we don't have control over different sites we have to be very flexible in what and how we do things. 

• We initially started with mocking the publisher sites to test the ads but that never gave complete and true feedback. To solve this problem we wrote simple tools that would enable the production ad call requests routed to our local servers. By doing this we could see our ads served from development environment on publisher's production website locally. Which would give a true picture that how ads would look like once released to production.
• Considering the underlying fact of web testing that there are multiple browsers used, cross browser testing is imperative.Then the tools were extended to support ad serving on Virtual machines to test on IE. With almost 5 different browsers and 4-5 publisher sites to be tested the manual testing task is definitely huge. Manual testing of new features cannot be ignored but for regression it would not be very productive and automating every thing is also not a viable option. We instead opted for system monitoring tests and capturing screenshots from live sites after our daily deployments to assure that things are up and running.
• Being an advertising company we do lot of AB testing and Multivariate testing around our ads and which adds more load to our manual testing efforts. This is one of the main reason we don't automate everything. With so many variables automation tests are not very effective, given that those features will change again after a short period of time.
• We do have our admin website through which we manage advertiser and publisher accounts. It is also used for accounting and billing purpose. The regression testing of this site is taken care by our integrations tests written in Cucumber + capybara + WebDriver  running on TeamCity.
• We have been deploying changes  to production every day since last 8 months and for this we need to make sure that our master code branch is always deploy ready. Initially all the changes were directly merged to our master branch and then the changes were tested both automatically and manually. Any issue introduced with a new change could possibly hold the production release. Maintaining multiple version of the same master branch was also considered a bad idea. We then started using git pull requests which enabled the developers to review the code and QAs can test the changes before merging to the master. Any failing tests would not make the master build red and can be fixed earlier without the need to run the entire tests suite locally. This approach has reduced the deploy risks and production issues significantly.

        As I said before we are a growing company and have testing related challenges that we are trying to deal with while exploring smart innovative solutions. Few worth mentioning, which I believe are faced by many teams are: Java script testing, brittle and flakey tests, long build times and definitely IE testing as always.

     

Why do I need Testing Team?

      In an Ideal software development world there would be no QA team or a testing team, but we all know all the processes including software development are prone to human error. With an increasing demand for better software there is a rise in Quality Assurance jobs.

       But most of the business or stake holders consider the QA team as an overhead and whenever their is a slump period the axe falls first on the testers. The development team as well often finds it difficult to fit in the testing team into their development phase and the teams usually end up on two poles of the process. And I can imagine the poor Project manager at the centre somehow managing and trying to get work done to get his billing correct. Facebook doesn't have any software testing team but they do as well test their software through beta testers before launching a feature to the world.

       How and where exactly does the testing team fits and can they really improve the software industry 

Well the answer is difficult but certainly not impossible. Its not the business or the developers who need to change as they are not necessarily wrong. Mostly its the test engineers who can change this attitude, what's needed is some retrospection into the QA role.

      Given that we are still not into the 100% agile mode most of the testing teams in traditional waterfall model work in post development phase. Where the opportunity of change is almost zero and even the defects fixes turns out to be long process. Testing teams are often divided into manual and automation teams.

• Manual team who consider there job limited to writing manual tests and executing those tests. These tests often run into thousands and updating them is again a huge effort. At times these tests are written years ago and the person executing them hardly understands the business goal behind a given step. More the number of bugs they find is a metric of how well the job was done.

   Our client once said why does your team total bug found was always less, the QA team doesn't seems to be working well? The team was working way better as we had zero bugs in production, isn't that the ultimate target?

• Automation teams on the other hand don't care at all about what's in the test cases they simply automate them line by line. Their performance is measured on the number of test cases automated (you can leave the test script "to do" to improve your performance, your manager is never going to open the test case and verify it? Yeah many people actually do that !!)

    What's the problem with above structure which is pretty much followed by more than 50% of the software teams?

   Wiki defines Software Testing as "Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test"

The ultimate aim of testing is to provide feedback on the software to the stakeholders before its being released to the end user. The problem with above stated structure is the missing feedback, both the teams are trying to get their job done but no one is focussed on providing quality feedback.

Let's see how we as QAs can get this whole cycle right. Testing team is the representative of business to the development team and vice a versa as they get their hands dirty on the software before anyone else and continue to do that through the life of the project. They often know more about the functionality then anyone else if not then they are probably not doing their job right. With my experience below are the certain points that seemed to be working and can help anyone who wants to improve upon:

• I haven't seen the concept of different manual and automation teams working but given the limited availability of required skill set this model is the only choice in certain cases. But even with this model both the team should work more closely to get the automation priorities right and manual team should use the feedback from automation results in manual verifications. A testeer who has understanding of business can definitely test extensively and write better automation tests.
• Testing team should work with Product team to understand the business goals and be more flexible in their manual testing to incorporate the business aspect.
• The projects where testing teams work closely with development team are more successful as the feedback loop for any defect/ bug is shorter. Even for offshore models the development and testing team for a given module should work next to each other.
• There is no way the performance is proportional to the number of bugs found, seriously? This is the biggest myth of testing world. The job of QA is to uncover issues in a software but higher the number of bugs higher is the cost. QA should discuss the edge cases with developers before building the functionality or raise the risky area ahead of time to the product managers so that the bugs can be avoided as early as possible.

   The above points are very much useful and applicable to agile projects as well. Given agile testers are not born they are the same testers who have worked in the waterfall model at some point of there life as a tester like me.