In today's fast changing world we cannot escape from the fact that business requirements change very often. If we use the predictive, heavy weight methodologies for developing software it is very difficult to incorporate the changing business needs of our customers. Light weight software development methodologies, which appeared in the late nineties "embrace changes". The disciplined adaptive nature of these methodologies helps us to easily accommodate changing business needs of our customers, even in later part of the development cycle.

Many software development organizations in India have started moving towards agile development methodologies as it helps the organizations to respond to changing business environments very quickly and provide better customer satisfaction. In today’s business environment it is not really the big that win the battles rather it's the fast that win the battles over the slow. Time to market is very important in today's fast changing world. Agile development helps us to deliver the value to the customer rapidly through a divide and conquer approach and prioritization. The right 20% of effort will yield 80% of the value, so we do a lot of those in agile development and extreme testing.

Introduction to Agile
In Extreme Programming (XP) the whole development is divided into different increments/milestones. Top priority user stories are covered in the initial increments. In XP the unit tests are developed first. Then the code is written to ensure that 100% of unit tests pass. This is done in an incremental way. The developers write unit tests and 100% of Unit tests are automated. This will help in executing the tests repeatedly and also simplify the reporting of results.

There is one more important type of testing involved in Extreme Testing, which is called Acceptance Test/Customer Test. These tests are written, based on User stories. They are formal tests conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. Test engineers write the Acceptance tests with the help of customers. In some organizations customers themselves write the acceptance tests for some of the top priority features. It is very important to understand the customer perspectives while writing the acceptance tests. The big mountain acceptance tests are automated using an appropriate tool and executed on all the builds. Extreme testing creates confidence that code is complete and it works; catches integration defects when they are first created, and, most importantly, provides confidence that a maintenance change did not introduce a regression error.

Extreme testing is the best way to survive extreme change. Basic values like open communication, tight feedback loop in the features teams, simplicity and courage are the key in extreme testing. On an XP project, Testing isn’t a final hurdle it is a journey along the full development cycle.

Areas to Focus
While building an Extreme Testing team in India we need to consider multiple factors. If we don't build the right test team for Agile it is going to be very tough to get the results. Open Communication is one of the key values in agile development.

Individuals and Interactions
If your existing team is to be transformed into an agile testing team the most important step is to evangelize the agile concepts and benefits in your team. Management and Development teams also need to be educated on the ROI(Return On Investment). When we were implementing Agile in our organization we used to conduct talks by practitioners on agile, play agile dramas depicting the outcome from monumental methodologies and light methodologies. Once the platform is set we can start implementing agile practices and values. We need to identify and prioritize which are the areas to focus on first for the team. We may need to refactor the team. If there are team members in your team with negative attitude or having an attitude to resist changes, then proper guidance need to be given to them to bring in the change. If there are no improvements, it is a good idea to move them to a different project. Agile talks about "tossing off" the code at end of the day if it doesn't serve the purpose. This is applicable for team members also. Don't try to patch it up too much...

While recruiting new members to an agile testing team we need to ensure that they have the right set of attitudes and skills in line with the agile way of working. Openness, ready to give and accept feedback, simplicity, courage, adaptability, good in communication, right skill mix ...these are some of the attributes we need to ensure in a new hire. If you are planning to hire it is a good idea to have a brief discussion about agile practices you follow in your organization during the interview. Once they are hired we need to evangelize agile among them. In India agile has not become that popular. We may not get engineers who worked in agile earlier. Transforming an engineer who has been working in monumental methodologies to an agile environment is not that easy. It's a big paradigm shift. There may be resistance to change. We need to plan our inductions in such a way that the returns of Agile are communicated to the new hires appropriately. Once they understand the synergy it gives to customers and the organization employees will start believing in this new model. Once this milestone is covered it is easy to evangelize the other agile practices we follow in our organization.

Like the "pair programming" concept in Agile mentoring also can be done through pairing. A new hire is paired with a senior test engineer who is in the team for more than 1 year. A high level introduction about the product is given to the new hire. After that during test case design and test execution the new hire pair up with other team members according to the plan laid out by the Coach. The mentoring plans always focus on big mountain functionalities first.

When Group of people works together in internationally distributed locations, there is great need to communicate with each other, share data and share expensive resources. Building a good communication mechanism is very important for the success of agile testing. Conversation with developer, customer, and feature team leads and product manager is frequent. Daily Stand up meetings with the feature teams helps to build the relationships among the feature team. All the Agile feature team members including developers, test engineers, documentation experts, product managers assemble near a white board in the morning (usually on a planned fixed time like 10am) for a short stand up meeting of 5 to 10 minutes duration. Plan for the day and top priority issues from the previous days work is communicated to the feature team. This meeting is not for resolving the issues or detailed discussion. Resolutions are taken later after the meeting. If we are working in a distributed model where the development is happening in US and the testing is in India or some part of the feature team is in a remote location like India and China, Communication and the feedback loop get badly affected. Tailored agile for these kinds of offshore development can be called as "Distributed Agile". Collaboration among testers, programmers, and other stakeholders is more highly valued on agile projects than details of process, practices, or tools. Test engineers are part of feature teams. Agile methods ask teams to continually evaluate how to improve group interaction, for the benefit of the project./p>

Once we have decided the members of the feature team building the team is the first priority. We need to plan for internal and external team building activities initially. We can also do lot of informal interactions and get together ... like all feature team members having evening snacks together in the snacks parlor.

Chat, email , wiki , telephone etc.. can be used for constant communications. We need to plan for weekly meetings with members of the feature team who are in the remote location. It is a good idea to have all the feature team members participate in this meeting. Frequent chat conversations between the development engineers and the remotely located test engineers is a good practice. This will help us to build the relationships. We need to agree up on the overlap timings when the chat interaction can happen as most of the time one of the engineers will be at home because of the time zone differences. Monthly Video conferencing is another good practice for improving the interactions. Engineers traveling in both directions frequently (2-3 travels per quarter) and working with the remote team for 3-4 weeks will enhance the relationships. This will help us for better culture sync. These ambassadors ensure there is enough osmosis within the distributed feature team.

Working Software over Comprehensive Documentation
Jim McCarthy said that, "The regular build is the single most reliable indicator that a team is functional and a product is being developed." This is very much true in the case of a distributed agile team. We need to ensure that we have a good build mechanism in our organization where the latest builds are easily available for the test teams. This will help the test teams to run their test on the latest code. We need to automate the big mountain acceptance tests using appropriate tools. This will help us to test often and communicate the progress to the feature teams.

Frequent demos of the current status of the features to entire feature team is very important. It is a good idea to have such demos weekly once. Demos can be arranged for remote teams on Fridays and we can have a group test after that where the entire feature team tests the latest build with a focus on new features. These demos can be recorded using WebEx and uploaded to a common repository. Later if some of the team members want to go through the demo they can always replay it from the common repository. During the initial milestones where the top priority features are developed we can use build mechanisms like "sandbox" where the developers check in their new code as and when the unit test pass into a sandbox build maintained by the feature team. Test engineers can always use this build for testing the new features. As we are going to give feedback on working software rather then on design documents or requirement documents the feedback inputs will have more value. Development engineers can incorporate the feedbacks back into the sandbox next day. At the end of the week the all the new code checked in by feature team in the sand box (which is tested and feedbacks incorporated) can be checked into the main line code. If we are working in distributed agile we may need to document some of the important changes. Use wiki for maintaining these kinds of knowledge bits.

Summary
To build an effective testing team for Distributed agile we need to focus on individuals and interactions over processes and tools. We need to ensure that the latest code is available for testing in the all the internationally distributed locations. Feedback based on working software helps to build confidence in the feature teams.

References
Agile Manifesto