Agile Methodology In recent years we have been witnessing the agile movement gain momentum.

Out of the various principles inlaid in agile methodologies, treatment of the product quality during its lifecycle stands out as one of the key aspects in every agile process. In fact, considering the many innovations introduced by agile practitioners, one can point out quality. One can say that one of key success factors of agile development is the incorporation of quality into every step and stage in the entire process. Introduction What is agile Methodology? Agile Methodology is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. The key point is that the agile technology development focused on the innovative edge of the clients business rather than an emphasis on the backend processes. Agile methodology is an approach to project management, typically used in software development introduced by Dr. Winston Royce. Agile Methodology was built upon the foundations of the traditional waterfall sequential methods of the 1970's. Sequential development was first outlined by Dr Winston Royce. His theory was that software systems development could be equated to a production line, where each phase must be planned and carried out before moving onto the next. This means all of the planning must be done before any code or database is even written, therefore the system can be outdated or even obsolete by the time it is finished. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. Agile methods break tasks into small increments with minimal planning, and don't directly involve long-term planning. Iterations are short time frames ("time boxes") that typically last from one to four weeks. Each iteration is worked on by a team through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. Agile Development The needs of business often change. It's therefore important the technology supporting your business is flexible enough to withstand such change, but robust enough to satisfy your day to day needs. In Agile approach the key challenge is to overcome the fear of knowing exactly what the final system will do and what it will look like. Since this approach is incremental this reduces the time spent upfront in doing analysis. Whilst the need for documentation is lower the great benefit is that getting actual working code is faster. The choice not to do detailed functional requirement upfront is that so often it tries to capture future requirements when the details are difficult to predict. 'Agile methodologies' are Scrum, XP, and Crystal where code is cut quickly to deliver working piecemeal systems to the end user quickly. Being Agile means implementing solutions quickly to your current needs & is adaptive & can change as per the exact needs. Why Agile? Organizations report that their main reasons for considering a switch to an Agile Software Methodology are: 1. Enhanced ability to respond to changing priorities. 2. Improved software quality. 3. Increased developer productivity. 4. Accelerated time-to-market. These business drivers closely correspond to the actual experience of organizations that have implemented Agile methodologies. In a survey of nearly 1,700 organizations that implemented Agile methodologies, more than half of these organizations report at least a 25% improvement in productivity, time-to-market and software quality.

The 4 main business impacts of implementing Agile methodologies for software development are in the areas of: 1. Predictability 2. Flexibility 3. Suitability 4. Testability

What is Agility? Agility is a dynamic, content specify, change embrace and growth oriented. Agility is more than an effective response to change. Change is what software development is about Changes in the software being built, changes to the team members, changes because of new technology, changes of all kinds that may have an impact on the product they build or the project that creates product. It encourages team structures and attitudes that make communication among team members and other stakeholders more facile. It emphasizes rapid delivery of operational software and de-emphasizes the importance of intermediate work products. Agile methods are people-oriented rather than processoriented.

The agile Alliance defines 12 principles for those who want to achieve agility. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements even late in deployment. 3. Deliver working software frequently (couple of weeks couple of months with a preference to shorter time scale ) 4. Business people and developers must work together daily throughout the project. 5. Build projects under motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. Most efficient and effective method of conveying information to and within a development team is face to face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity the art of maximizing the amount of work not done- is essential. 11. The best architectures, requirements, and designs emerge from self organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then turns and adjusts its behavior accordingly.

Agile Methods address three key assumptions about the majority of software projects It is difficult to predict in advance which requirements or customer priorities will change and which will not. For many types of software design and construction activities are interleaved (construction is used to prove the design) Analysis, design, and testing are not as predictable from a planning perspective as one might like them to be.

An agile process therefore must be adaptable. It must adopt incrementally. To accomplish incremental adaptation, an agile team requires customer feedback. Customers cannot effectively produce all requirements in high enough detail for implementation to occur at the beginning of a project. Customers may not want to make decisions about the system until they have more information. Agile values a high visibility and customer involvement. The frequent demonstration and release of software

common in Agile approaches gives customers a chance to try software periodically and provide feedback. Agile helps companies produce the right product. An iterative approach allows customers to delay decisions as well. Decisions can be delayed to some future iteration when better information or technology is available to optimize the choice.

Difference between traditional development and Agile Methods

Agile Project Management 1. Focus on Customers satisfaction and interaction. 2. Customer prioritized, time based delivery.

Traditional Project Management 1. Focus on Plans and artifacts. 2. Manager Negotiated, scope based delivery.

3. Response to change, adaptive action.

3. Change Controlled via Corrective action.

4. Collaboration on self-disciplined and self-organizing 4. Top_Down control. team.

Agile Project management Traditional project management involves very disciplined and deliberate planning and Control methods. With this approach, distinct project life cycle phases are easily recognizable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. Today, business processes are more complex, interconnected, and interdependent and interrelated than ever before. For projects involving a significant software component, traditional project management can be somewhat ineffective since the requirements are elusive, volatile and subject to change. An alternative approach, Agile Project Management (APM), is emerging in the industry. APM is a highly iterative and incremental process, where developers and project stakeholders actively work together to understand the domain, identify what needs to be built, and prioritize functionality. Agile methods are used when these conditions are present: Project value is clear Customer actively participates throughout the project The customer, designers, and developers are co-located Incremental feature-driven development is possible

Agile Development model Initial Requirements and Architecture Models

Iteration #1 Review lessons learned Iteration #2 Review lessons learned Iteration #3 Review lessons learned

Iteration #4

Iteration #N

Lessons learned Close Project

The Agile approach consists of many rapid iterative planning and development cycles, allowing a project team to constantly evaluate the evolving product and obtain immediate feedback from users or stakeholders. The team learns and improves the product, as well as their working methods, from each successive cycle. After a streamlined planning, requirements, definition and solution design phase is completed to get the project underway, iterations of more detailed planning, requirements, design, build and test take place in waves. This approach allows for immediate modifications of the product as requirements come into view. APM requires a dedicated full-time project team that includes a customer or end user, where team members work from the same location. Agile Process Models There are many Agile process models with unique characteristics, mentioned as below: Agile Unified Process (AUP) Crystal Clear Dynamic Systems Development Method (DSDM) Essential Unified Process (EssUP) Extreme Programming (XP) Feature Driven Development (FDD) GSD Kanban (development) Lean software development Open Unified Process (OpenUP) Scrum Velocity tracking

We will take up Extreme Programming(XP) more elaborately: Extreme Programming is one of several popular Agile Processes. It has already been proven to be very successful at many companies of all different sizes and industries world wide. First paper on extreme programming was published in 1999 by Kent Back at Chrysler while working on a payroll project as a member of a 15 person team. Beck continued to refine and improve the XP methodology after the project was completed until it gained worldwide acceptance.

Extreme Programming is successful because it stresses customer satisfaction. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle. Extreme Programming emphasizes team work. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming improves a software project in four essential ways; communication, simplicity, feedback, and courage. Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology. Extreme Programming uses an object-oriented approach. It encompasses a set of rules and practices that occur within the context of four framework activities. 1. 2. 3. 4. Planning Design Coding Testing

Planning The first phase of Extreme Programming life cycle is planning, where customers or users meet with the development team to create user stories or requirements. The development team converts user stories into iterations that cover a small part of the functionality or features required. A combination of iterations provides the customer with the final fully functional product. Members of the programming team then assess each story and assign a cost measured in development weeks to it. If the story requires more than three development weeks, the customer is asked to split the story into smaller stories and the assignment of value and cost occurs again. New stories can be written at any time. The programming team prepares the plan, time, and costs of carrying out the iterations, and individual developers sign up for iterations. One planning approach is the critical path method, grouping iterations essential for project progress in a linear fashion, and arranging for completion of other iterations parallel to the critical path.

Designing An iteration of XP programming starts with designing. The guiding principles of this stage are:

1. Thrust on simplicity by expressing a thing only once and not adding functionality in anticipation. XP design rigorously follows the KIS (Keep it Simple) principle. A simple design is always preferred over a more complex representation. In addition, the design provides implementation guidance for a story as it is written nothing less, nothing more. The design of extra functionality is discouraged. Keeping a design simple is hard work 2. Using systems metaphor or standards on names, class names and methods, and agreeing on uniform styles and formats to ensure compatibility among the work of different team members. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system. 3. Using Software Class Responsibilities and Collaboration (CRC) Cards that allow for a departure from the traditional procedural mindset and make possible object oriented technology. Such cards allow all members of the project team to contribute ideas, and collate the best ideas into the design. CRC Cards allow entire project teams to contribute to the design. 4. Creating spike solutions or simple programs that explore potential solutions for a specific problem, ignoring all other concerns, to mitigate risk. The intent is to lower the risk when true implementation starts and to validate the original estimates for the story containing the design problem.

Coding Coding constitutes the most important phase in the Extreme Programming life cycle. XP programming gives priority to the actual coding over all other tasks such as documentation to ensure that the customer receives something substantial in value at the end of the day. Standards related to coding include: 1. Developing the code based on the agreed metaphors and standards, and adopting a policy of collective code ownership. 2. Pair programming or developing code by two programmers working together on a single machine, aimed at producing higher quality code at the same or less cost. Each person takes on a slightly different role. Ex: one person might think about the coding details of a particular portion of the design while the other ensures that the coding standards are being followed and the code that is generated fits into the broader design of the story. 3. Collective Code Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs. 4. Strict adherence to 40-hour workweeks with no overtime. This ensures the developers work in the peak of their mental and physical faculties. 5. Frequent integration of the code to the dedicated repository, with only one pair integrating at a time to prevent conflicts, and optimization at the end.

Testing Extreme program integrates testing with the development phase rather than at the end of the development phase. 1. Create unit test framework: All codes have unit tests to eliminate bugs, and the code passes all such unit tests before release. Unit tests are one of the corner stones of Extreme Programming. The unit tests that are created should be implemented using a framework that enables them to be automated. This

encourages a regression testing strategy whenever code is modified. Unit tests are released into the code repository along with the code they test. Code without tests may not be released. If a unit test is discovered to be missing it must be created at that time. Once universal testing suite is created, integration and validation testing of the system can occur on a daily basis. This provides the XP team with a continual indication of progress and also can raise warning flags early if things are going away.

2. When a bug is found tests are created: When a bug is found tests are created to guard against it coming back. A bug in production requires an acceptance test be written to guard against it. Creating an acceptance test first before debugging helps customers concisely define the problem and communicate that problem to the programmers. Programmers have a failed test to focus their efforts and know when the problem is fixed. Another key test is customer acceptance tests, based on the customer specifications. Acceptance test run at the completion of the coding, and the developers provide the customer with the results of the acceptance tests along with demonstrations. 3. Acceptance tests are run often and the score is published: Acceptance tests are created from user stories. During iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works. Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release.

Agile Testing While the given application under test is still evolving depending upon the customer needs, the mindset of the end user and the current market condition, it is highly impractical to go for the usual standard SDLC Models like Water Fall, V&V Model etc. Such models are most suitable for the Applications that are stable and non-volatile. The concept of Time-To-Market is the key word in todays IT Business that compels the Software vendors to come up with new strategies to save the time, resources, cut down the cost involved and at the same time, deliver a reliable product that meets the user requirements. In this case, a reasonably good amount of end-to-end testing is carried out and the product could be acceptable with known issues/defects at the end of an intermediate release. These defects are harmless for the Application usability. To adopt such a process in a systematic way, we have a new concept called Agile Methodology. This methodology continuously strives to overcome the issues of dynamically changing requirements while still trying to maintain a well-defined process. Reasons for Agile Testing methodology to test an Application The testing wouldnt be 100% complete in this case before the finished product reaches the hands of the end user. This is true especially when the target audience and its system structure are unknown. Different users have their own set of ideas and unique problems. Given this fact, it is hard to say that it is 100% bug free software when it reaches the customer. Hence, taking into account the constraints involved in using the standard SDLC Models, it is worth adopting an approach such as Agile Testing, which is more suitable for the dynamically changing requirements.

Scope of Agile Testing Context Driven Testing: This type of testing is what usually the Agile Testers incorporate. Context Driven testing is the one where the test scenarios are not known before hand. It mostly comes from the context in which the application is being executed. In our case, it is constructing the UDMs (User defined model ) based on a given use case from the targeted end user and test it for the scenarios that are explained by his system configuration. It also includes constructing the UDMs based on any trouble-shooting discussion arising out of defects pointed out during the Customer acceptance and testing. Rapid Testing: Rapid Testing is a process of defining our own strategies to test the Software, not necessarily following any specific Process or a Model. It focuses mainly on identifying the defects as quickly as possible rather than focusing on the end user requirements. Heuristic approach is used in such cases. The tester uses his common sense and previous work experience to test the application at various levels in order to figure out where the application stands. Challenges in Agile testing Agile de-values documentation as discussed earlier, so testers on Agile projects often receive insufficient test oracles. Even with adequate test oracles, two Agile principles keep the challenges alive. 1) Agile requires team to embrace change. 2) Agile advocates conveying information face to face conversation. Test oracle problem impose the inefficiencies around 20 to 30 percent, test oracle problem reduce the bug-finding effectiveness. Some projects team change the definition of correct behavior after tests execution starts, and sometimes change the definition of correct behavior in a meeting without involving the test team. Test strategies will not solve this issue, change management is required. Good test strategies support Agile methodology, Risk Based testing supports increased quality, increased productivity and flexibility. Reactive testing allows testers to explore areas that risk based testing and automation regression testing might miss. In Agile lifecycles, code that worked in previous sprints gets churned by new features in each subsequent sprint, increasing the risk of regression. So we need combined risk based testing with maintainable automated regression testing at the system test level. Reference.. http://www.agilemodeling.com http://myopendraft.blogspot.in/2010/01/12-principles-of-agile-methods.html www2.selu.edu/Academics/Faculty/galkadi/285/notes