Test Methodology & Agile Testing

What is a Software Methodology?

A methodology is a package of methods. In simple words , it's a bundle of  practical ideas and proven practices which help in efficient software project management. 

Software Test Methodology : The important Software Test Methodologies are discussed below...

 

Waterfall model 

 

What is it? 

In the waterfall model ,software development progress through various phases like Requirements Analysis , Design etc -  sequentially. 

In this model, next phase begins only when the earlier phase is completed. 

What Is The Testing Approach? 

The first phase in waterfall model is the requirements phase in which all the project requirements are completely defined before starting the testing. During this phase , the test team brainstorms the  scope of testing , test strategy and drafts a detailed test plan. 

Only once the design of software is complete, the team will move on to execution of the test cases  to ensure that the developed software behaves as it expected. 

In this methodology, the testing team proceeds to the next phase only when the previous phase is completed. 

  

Advantages 

This model is very simple to plan and manage. Hence, projects where requirements are clearly defined and stated beforehand can be easily tested using waterfall model.  

Disadvantages 

In the waterfall model , you can begin with the next phase only once the previous phase is completed. Hence , this model cannot accommodate unplanned events and uncertainty. 

This methodology is not suitable for projects where the requirements change frequently. 

 

Iterative development 

 

 

  

What is it? 

In this model , a big project is divided into small parts ,  and  each part is subjected to multiple iterations of the waterfall model. At the end of iteration, a new module is developed or an existing module is enhanced. This module is integrated into the software architecture and the entire system is tested all together  

What is the testing Approach? 

As soon as iteration is completed, the entire system is subjected to testing. Feedback from testing is immediately available and is incorporated in next cycle. The testing time required in successive iteration can be reduced based on the experience gained from past iterations. 

  

Advantages 

The main advantage of iterative development is the test feedback is immediately available at the end of each cycle. 

Disadvantages 

This model increases communication overheads significantly since at the end of each cycle, feedback about deliverables , effort etc must be given. 

  

 

Agile methodology

  

What is it ? 

Traditional  software development methodologies work on the premise that software requirements remain constant throughout the project. But with increase in complexity , the requirements undergo numerous changes and continuously evolve. At times, the customer himself is not sure what he wants. Though iterative model addresses this issue, it's still based on the waterfall model. 

In Agile methodology   , software is developed in   incremental, rapid cycles. Interactions amongst customers, developers and client are emphasized rather than processes and tools. Agile methodology focuses on responding to change rather than extensive planning. 

What Is The Testing Approach? 

 Incremental testing is used in agile development methods and hence, every release of the project is tested thoroughly. This ensures that any bugs in the system are fixed before the next release. 

  

Advantages 

It is possible to make changes in the project at any time to comply with the requirements. 

This incremental testing minimizes risks. 

Disadvantages 

Constant client interaction means added time pressure on all stake holders including the client themselves , software development and test teams . 

 

Extreme programming

 

 

 

What is it? 

Extreme programming is a type of agile methodology which believes in short development cycles. A project is divided into simple engineering tasks. Programmers code a simple piece of software and get back to customer for feedback. Review points from the customer are incorporated and the developers proceed with the next task. 

In extreme programming developers usually work in pairs. 

Extreme Programming is used in places where customer requirements are constantly changing. 

What Is The Testing Approach? 

Extreme programming follows a Test-driven development which is described as follows - 

1. Add a test case to the test suite  to verify the new functionality which is yet to be developed

2. Run all the tests and obviously the new test case added must fail since the functionality is not coded yet

3. Write some code to implement the feature/functionality

4. Run the test suite again .This time , the new test case should pass since the functionally has been coded

Advantages 

Customers having a  vague software design in mind could use extreme programming 

Continuous testing and continuous integration of small releases ensure software code is delivered is of high quality 

Disadvantages 

Meetings amongst the software development  team and  clients add to time requirements. 

What is Kanban?

Kanban is a new technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied. 

A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end. 

Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we'll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works. 

The Effect of Bottlenecks

A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck. 

Using our development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck. 

If the analysts and developers aren't aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.

The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by. 

Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity. 

If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation. 

But how do we know where the bottleneck is in any given process? And what happens when it moves? 

Kanban reveals bottlenecks dynamically

Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top. 

Limiting work-in-progress reveals the bottlenecks so you can address them. 

The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column. 

The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand. 

Worked Example

The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers. 

Notice that we've split some of the columns in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the "doing" and "done" columns. 

Once the testers have finished testing a feature, they move the card and free up a slot in the "Test" column.

Now the empty slot in the "Test" column can be filled by one of the cards in the development "done" column. That frees up a slot under "Development" and the next card can be pulled from the "Analysis" column and so on. 

Kanban for QA Teams

The Kanban method is widely used in the software world especially when it comes down to contexts with frequent priority shifts and change requests. One of the ideal use-cases for Kanban is QA and generally all sorts of quality activities. In this article we are going to explore a sample QA Kanban board structure and a few configurations that will help a QA person utilize the benefits of a great Kanban software system like Kanbanize.

QA Kanban Board Structure

 

 

Let us quickly go through the board and comment on the key points.

The stages of the board are as follows:

· Ready to Test – this stage of the process is for tasks/features that have been completed by the development team and that are ready to be tested. The WIP limit is 10, because there may be bursts of completed tasks coming from development. If the WIP limit of 10 is reached, the development team should not push more work to the QA Kanban board.

· In Progress – this is a global In Progress column with a couple of sub-columns.

· Regression Testing – the first stage of the process is regression testing. This is where a lot of automated tests are being run to ensure that no bugs have been introduced in existing functionality.

· Functional Testing – this is where new features are being tested. As tests for new features are not yet automated, this is usually manual testing or a combination of both manual and automated testing.

· System Testing – a step where end-to-end scenarios are being run. It is always a good idea to run end-to-end tests before releasing to production, as smaller test cases focused on a particular functionality do not always detect major integration issues.

· Load Testing – the final step in our process where load/soak/performance tests are being run. Having defined KPIs that your performance should never go below is a must-have for enterprise class software. Each release need to be certified and all regressions in performance must be detected/fixed.

The swim-lanes (horizontal columns) can be utilized to contain tasks for two different products or projects. Another application of the swim-lanes could be to indicate priority, person, classes of work, etc.

What to do with features that fail testing?

There are several strategies here. One would be that you keep the items on the board while you submit issues in the developers’ support board. Another would be to move the task back to the developers’ board and label it as failed. Later on you can get reports based on the number of retests needed before successful.

This is how your distribution chart could look like based on the number of retests a given feature passes through:

 

 

Which Software Methodology to choose  ?

There are tons of methodologies available for software development and its corresponding testing. Each methodology is designed for a specific purpose and has its relative merits and de-merits. 

Selection of a particular methodologies depends on many factors such as the nature of project, client requirement, project schedule , etc. 

From a testing perspective, some methodologies push for testing input early in the development life  cycle , while others wait until a working model of the system is ready. 

 

How to setup software testing methodologies?

Software testing methodologies should not be setup just for the sake of testing software code. The big picture should be considered and the prime goal of the project should be satisfied by the testing methodology. 

Scheduling 

Realistic scheduling is the key to the implementation of successful testing methodology and the schedule should meet the needs of every member of the team. 

Defined deliverables 

In order to keep all the members of the team on the same page, well defined deliverables should be provided. The deliverables should contain direct content without any ambiguity. 

Test approach 

Once scheduling is complete and defined deliverables are made available, the testing team should be able to formulate the right test approach. Definition documents and developer meetings should indicate the team about the best test approach that can be used for the project. 

Reporting 

Transparent reporting is very difficult to achieve, but this step determines the effectiveness of the testing approach used in the project.

What is Agile?

AGILE is a methodology that promotes continuous iteration of development and testing throughout the software development life cycle of the project. Both development and testing activities are concurrent unlike the Waterfall model 

I hope we got an idea of Agile!!! Now, we can step on to Agile Testing.

The agile software development emphasizes on four core values.

1. Individual and team interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Agile versus Waterfall Method

Agile and Waterfall model are two different methods for software development process. 
Though they are different in their approach, both methods are useful at times, depending
 on the requirement and the type of the project.

Agile Model	Waterfall Model
· Agile method proposes incremental  and iterative approach to software  design	· Development of the software flows  sequentially from start point to  end point.
· The agile process is broken into  individual models that designers  work on	· The design process is not broken into  an individual models
· The customer has early and frequent  opportunities to look at the product and make decision and changes to the project	· The customer can only see the product  at the end of the project
· Agile model is considered  unstructured compared to the  waterfall model	· Waterfall model are more secure because  they are so plan oriented
· Small projects can be implemented  very quickly. For large projects, it  is difficult to estimate the  development time.	· All sorts of project can be estimated and  completed.
· Error can be fixed in the middle of  the project.	· Only at the end, the whole product is  tested. If the requirement error is  found or any changes have to be made,  the project has to start from the beginning
· Development process is iterative,  and the project is executed in  short (2-4) weeks iterations.  Planning is very less.	· The development process is phased, and  the phase is much bigger than iteration. Every phase ends with the detailed description of the next phase.
· Documentation attends less priority  than software development	· Documentation is a top priority and can  even use for training staff and upgrade  the software with another team
· Every iteration has its own testing  phase. It allows implementing  regression  testing every time new functions or  logic are released.	· Only after the development phase, the  testing phase is executed because separate parts are not fully functional.
· In agile testing when an iteration  end, shippable features of the product is delivered to the customer. New features are usable right after shipment. It is useful when you have  good contact with customers.	· All features developed are delivered at  once after the long implementation  phase.
· Testers and developers work  together	· Testers work separately from developers
· At the end of every sprint, user  acceptance is performed	· User acceptance is performed at the end  of the project.
· It requires close communication  with  developers and together analyse  requirements  and planning	· Developer does not involve in requirement  and planning process. Usually, time delays between tests and coding

 

Methodologies of Agile Testing

There are various methods present in agile testing, and those are listed below:

 

Scrum

SCRUM is an agile development method which concentrates specifically on how to manage tasks within a team based development environment. Basically, Scrum is derived from activity that occurs during a rugby match. Scrum believes in empowering the development team and advocates working in small teams (say- 7 to 9 members). It consists of three roles, and their responsibilities are explained as follows:

Scrum Master

Master is responsible for setting up the team, sprint meeting and removes obstacles to progress

Product owner 

The Product Owner creates product backlog, prioritizes the backlog and is responsible for the delivery of the functionality at each iteration

Scrum Team

Team manages its own work and organizes the work to complete the sprint or cycle 

Product Backlog 

This is a repository where requirements are tracked with details on the no of requirements to be completed for each release. It should be maintained and prioritized by scrum master, and it should be distributed to the scrum team. Team can also request for a new requirement addition or modification or deletion 

 

Scrum Practices

Practices are described in detailed: 

Process flow of Scrum: 

Process flow of scrum testing is as follows:

->Each iteration of a scrum is known as Sprint 

->Product backlog is a list where all details are entered to get end product 

->During each Sprint, top items of Product backlog are selected and turned into Sprint backlog 

->Team works on the defined sprint backlog 

->Team checks for the daily work 

->At the end of the sprint, team delivers product functionality 

 

eXtreme Programming (XP) 

Extreme Programming technique is very helpful when there is constantly changing demands or requirements from the customers or when they are not sure about the functionality of the system. It advocates frequent "releases" of the product in short development cycles, which inherently improves the productivity of the system and also introduces a checkpoint where any customer requirements can be easily implemented. The XP develops software keeping customer in the target.

Business requirements are gathered in terms of stories. All those stories are stored in a place called the parking lot. 

In this type of methodology, releases are based on the shorter cycles called Iterations with span of 14 days time period. Each iteration includes phases like coding, unit testing and system testing where at each phase some minor or major functionality will be built in the application. 

Phases of eXtreme programming: 

There are 6 phases available in Agile XP method, and those are explained as follows: 

Planning 

->Identification of stakeholders and sponsors 

->Infrastructure Requirements 

->Security related information and gathering 

->Service Level Agreements and its conditions 

Analysis 

->Capturing of Stories in Parking lot 

->Prioritize stories in Parking lot 

->Scrubbing of stories for estimation 

->Define Iteration SPAN(Time) 

->Resource planning for both Development and QA teams 

Design

->Break down of tasks 

->Test Scenario preparation for each task 

->Regression Automation Framework

Execution

Coding 

Unit Testing 

Execution of Manual test scenarios 

Defect Report generation 

Conversion of Manual to Automation regression test cases 

Mid Iteration review 

End of Iteration review 

Wrapping 

Small Releases

Regression Testing 

Demos and reviews 

Develop new stories based on the need

Process Improvements based on end of iteration review comments 

Closure

Pilot Launch

Training 

Production Launch 

SLA Guarantee assurance 

Review SOA strategy 

Production Support

There are two storyboards available to track the work on a daily basis, and those are listed below for reference. 

Story Cardboard

This is a traditional way of collecting all the stories in a board in the form of stick notes to track daily XP activities. As this manual activity involves more effort and time, it is better to switch to an online form.

Online Storyboard 

Online tool Storyboard can be used to store the stories. Several teams can use it for different purposes.

Crystal Methodologies

Crystal Methodology is based on three concepts

1. Chartering: Various activities involved in this phase are creating a development team, performing a preliminary feasibility analysis, developing an initial plan and fine-tuning the development methodology

2. Cyclic delivery: The main development phase consists of two or more delivery cycles, during which the

1. Team updates and refines the release plan

2. Implements a subset of the requirements through one or more program test integrate iterations

3. Integrated product is delivered to real users

4. Review of the project plan and adopted development methodology

3. Wrap Up: The activities performed in this phase are deployment into the user environment, post- deployment reviews and reflections are performed.

Dynamic Software Development Method (DSDM)

DSDM is a Rapid Application Development (RAD) approach to software development and provides an agile project delivery framework. The important aspect of DSDM is that the users are required to be involved actively, and the teams are given the power to make decisions. Frequent delivery of product becomes the active focus with DSDM. The techniques used in DSDM are

1. Time Boxing

2. MoSCoW Rules

3. Prototyping

The DSDM project consists of 7 phases

1. Pre-project

2. Feasibility Study

3. Business Study

4. Functional Model Iteration

5. Design and build Iteration

6. Implementation

7. Post-project

Feature Driven Development (FDD)

This method is focused around "designing & building" features. Unlike other agile methods, FDD describes very specific and short phases of work that has to be accomplished separately per feature. It includes domain walkthrough, design inspection, promote to build, code inspection and design. FDD develops product keeping following things in the target

1. Domain object Modeling

2. Development by feature

3. Component/ Class Ownership

4. Feature Teams

5. Inspections

6. Configuration Management

7. Regular Builds

8. Visibility of progress and results

Lean Software Development

Lean software development method is based on the principle "Just in time production". It aims at increasing speed of software development and decreasing cost. Lean development can be summarized in seven steps.

1. Eliminating Waste

2. Amplifying learning

3. Defer commitment (deciding as late as possible)

4. Early delivery

5. Empowering the team

6. Building Integrity

7. Optimize the whole

 

Kanban

Kanban originally emerged from Japanese word that means, a card containing all the information needed> to be done on the product at each stage along its path to completion. This framework or method is quite adopted in software testing method especially in agile testing.

Difference between Scrum and Kanban

Scrum	Kanban
· In scrum technique, test must be broken  down so that they can be completed within  one sprint	· No particular item size is prescribed
· Prescribes a prioritized product backlog	· Prioritization is optional
· Scrum team commits to a particular  amount of work for the iteration	· Commitment is optional
· Burndown chart is prescribed	· No particular item size is prescribed
· Between each sprint, a scrum board  is reset	· A Kanban board is persistent. It  limits the number of items in workflow  state
· It cannot add items to ongoing iteration	· It can add items whenever capacity  is available
· WIP limited indirectly	· WIP limited directly
· Timeboxed iterations prescribed	· Timeboxed iterations optional

Agile metrics:

Metrics that can be collected for effective usage of Agile is:

-> Drag Factor 

Effort in hours which do not contribute to sprint goal 

Drag factor can be improved by reducing number of shared resources, reducing the amount of non-contributing work 

New estimates can be increased by percentage of drag factor -New estimate = (Old estimate+drag factor) 

-> Velocity 
Amount of backlog converted to shippable functionality of sprint 

->No of Unit Tests added 

->Time taken to complete daily build

->Bugs detected in an iteration or in previous iterations 

->Production defect leakage 

What is Scrum 
Building complex software applications is a difficult task. Scrum methodology comes as a solution for executing such complicated task. It helps development team to focus on all aspects of the product like quality, performance, usability and so on. 

Following are Key Features of Scrum- 

· Scrum has short fixed schedule of release cycles with adjustable scope known as sprints to address rapidly changing development needs. Each release could have multiple sprints. Each Scrum Project could have multiple Release Cycles. 

· A repeating sequence of meetings, events and milestones 

· A practice of testing and implementing new requirements, known as stories, to make sure some work is released ready after each sprint 

Scrum is based on following 3 Pillars- 

Lets look at the one by one 

1. Roles in Scrum 

2. There are three chief roles in Scrum Testing – Product Owner, Scrum Master and The Development Team. Let's study them in detail 

Product Owner Scrum Master The Team o He defines features  of the product. o He manages the  team and look after  the team's productivity o The team is usually  about 5-9 members o Product Owner  decides release date  and corresponding  features o He maintains  the  block list and  removes barriers in  the development o It includes developers,  designer and sometimes  testers, etc. o They prioritize the  features according  to the market value  and profitability  of the product o He/She co-ordinates  with all roles  and functions o The team organizes  and schedule their work  on their own o He is responsible  for the profitability  of the product o He/She shields  team from external  interferences o Has right to do  everything within the  boundaries of the project  to meet the sprint goal o He can accept or  reject work  item result o Invites to the daily  scrum, sprint  review and planning  meetings o Actively participate  in daily ceremonies

3. Scrum Artifacts 

A scrum process includes 

o User stories: They are short explanation of functionalities of the system under test. Example for Insurance Provider is – "Premium can be paid using the online system." 

o Product Backlog: It is a collection of user stories captured for a scrum product. The product owner prepares and maintains the product backlog. It is prioritized by product owner, and anyone can add to it with approval from the product owner. 

o Release Backlog: A release is a time frame in which the number of iterations is completed. The product owner co-ordinates with the scrum master to decide which stories should be targeted for a release. Stories in the release backlog are targeted to be completed in a release. 

o Sprints: It is a set period of time to complete the user stories, decided by product owner and developer team, usually 2-4 weeks of time. 

o Sprint Backlog: It's a set of user stories to be completed in a sprint. During sprint backlog, work is never assigned, and the team signs up for work on their own. It is owned and managed by the team while the estimated work remaining is updated daily. It is the list of task that has to be performed in Sprint 

o Block List: It is a list of blocks and unmade decisions owned by scrum master and updated daily 

o Burndown chart: Burn-down chart represents overall progress of the work in progress and work completed throughout the process. It represents in a graph format the stories and features completed 

5. 

Ceremonies (Processes) in Scrum 

6. 

· Sprint Planning: A sprint begins with the team importing stories from the release backlog into the sprint backlog; it is hosted by scrum master. The Testers estimate effort to test the various stories in the Sprint Backlog. 

· Daily Scrum: It is hosted by scrum master, it last about 15 minutes. During Daily Scrum, the members will discuss the work completed previous day, the planned work for the next day and issues faced during sprint. During daily stand-up meeting team progress is tracked. 

· Sprint Review/ Retrospective: It is also hosted by scrum master, it last about 2-4 hours and discuss what team has accomplished in the last sprint and what lessons were learned. 

  

Role of Tester in Scrum 

There is no active role of Tester in Scrum Process. Usually, testing is carried out by developer with Unit Test. While product owner is also frequently involved in the testing process during each sprint. Some Scrum projects do have dedicated test teams depending on the nature & complexity of the project. 

The next question is, what tester do in scrum? Following note will answer 

Testing Activities in Scrum 

Testers do following activities during the various stages of Scrum- 

Sprint Planning 

· In sprint planning, tester should pick a user-story from the product backlog that should be tested. 

· As a tester, he/she should decide how many hours (Effort Estimation) it should take to finish testing for each of selected user stories. 

· As a tester, he/she must know what sprint goals are. 

· As a tester, contribute to the prioritizing process 

Sprint 

· Support developers in unit testing 

· Test user-story when completed. Test execution is performed in a lab where both tester and developer work hand in hand. Defect are logged in Defect Management tool which are tracked on a daily basis. Defects can be conferred and analyzed during scrum meeting. Defects are retested as soon as it is resolved and deployed for testing 

· As a tester, he/she attends all daily standup meeting to speak up 

· As a tester, he/ she can bring any backlog item that cannot be completed in the current sprint and put to the next sprint 

· 

Tester is responsible for developing automation scripts. He schedules automation testing with Continuous Integration (CI) system. Automation receives the importance due to short delivery timelines. Test Automation can be accomplished by utilizing various open source or paid tools available in the market. This proves effective in ensuring that everything that needs to be tested was covered. Sufficient Test coverage can be achieved with a close communication with the team. 

· 

· Review CI automation results and send Reports to the stakeholders 

· Executing non-functional testing for approved user stories 

· Co-ordinate with customer and product owner to define acceptance criteria for Acceptance Tests 

· 

At the end of the sprint, tester also does acceptance testing(UAT) in some case and confirms testing completeness for the current sprint 

·  

Sprint Retrospective 

· As a tester, he will figure out what went wrong and what went right in the current sprint 

· As a tester, he identifies lesson learned and best practices 

Test Reporting 

Scrum Test metrics reporting provides transparency and visibility to stakeholders about the project. The metrics that are reported allow team to analyse their progress and plan their future strategy to improve the product. There are two metrics that are frequently used to report. 

Burn down chart: Each day, Scrum Master records the estimated remaining work for the sprint. This is nothing but the Burn Down Chart. It is updated daily. 

A burn down chart gives a quick overview of the project progress, this chart contains information like total amount of work in the project that must be completed, amount of work completed during each sprint and so on. 

Velocity history graph: The velocity history graph predicts the velocity of the team reached in each sprint. It is a bar graph and represents how teams output has changed over time. 

The additional metrics that may be useful are schedule burn, budget burn, theme percent complete, stories completed - stories remaining and so on. 

Automation Testing for Agile Methodology. 

In the last few years, ever since the agile methodology came on board with its founders shouting and willing to do away with the mundane and laborious realities of the traditional waterfall model, the impact of the same can be also felt when it comes to automation testing. 

 In the realm of the traditional process of software testing life cycle, automation testing is normally feasible when the application is stable, steady and the requirement is involving with a real considerable amount of time and in most cases involving a set of very skillful automation expert resources as well as a considerable amount of set-up costs. The basic purpose of automation testing is to reduce costs over long time and to ensure no new defects have been introduced as a result of existing test cases. 

Automation testing by the very nature of the technology is not exploratory in nature since the main role of automation testing is saving time and reducing costs. Automation testing is not meant to come up with new and innovative defects. Automation testing aims at mostly conformation of the already existing. 

Now by its very definition agile methodology talks about doing away with laborious and tedious documentation so that new and innovative ideas could be implemented and people could interact freely with each other so that more of these innovative and explorative ideas could be implemented. 

  

Thus we could see a contradiction between the basic fundamental philosophies of agile methodologies and automation testing. 

So we need to consider certain fundamental points here when it comes to evaluating the use of agile methodologies with respect to the automation testing methods and techniques. Thus we need to consider some fundamental points like time taken for design and coding, validation of the designed scripts with the existing test data and then adoption of the same for testing (whether the tests are of functional or regression purposes) So the real fact of all these events is that in order to perform all these facts, we need to ensure that a considerable amount of time is required for these tasks and in an agile environment where an average sprint takes an average 1-2 weeks to complete and thus it is obviously too difficult to contemplate affording so much time for automating scripts in such an way. 

Another significant factor remains here that the type of changes in requirements which come into picture when agile methodology is at play. Agile methodology by it's own very definition is a sort of technique which is very helpful for responding to quick customer induced change requirements and which thus lends itself well to frequent changes during the overall development of the application. 

In contrast automation testing is very useful when it comes to the more stable and less frequent types of requirements. Thus by definition automation testing does not lend itself well to various types of frequent changes in requirements which comes alongside the adoption of any agile methodologies. 

The selection of relevant automation tool is also a potentially very important factor when it comes to the adoption of automation testing within the scope of an overall agile methodology. Licensed automation tools for example impose strict security access criterion to different types and levels of users when it comes  accessing various important resources belonging to that particular testing automation framework.

In contrast agile methodology emphasizes upon mostly open collaboration and open ended interaction between team members and thus restrictive policies which directly affects how the users would have a negative impact in the overall cohesion within the team and thus may be leading into results which are neither very helpful nor very conducive to the overall success of the project. 

Therefore the primary importance of the process should be to ensure that in order to obtain the quality delivery of automation test scripts within a stipulated time as afforded by agile methodology; we need to choose our prospective test cases which would be automated in a more nuanced way such that these automated test scripts lend themselves well for future re-use as well as ensuring that they can be prepared within the proper duration of the allotted time (as required during the agile methodology process). 

After consideration of all the above factors we thus can realize that even while adopting agile methodologies, we need to bring into picture the types of tests like for example regression tests (since even during agile testing there is a considerable amount of testing work which is required to put into the job of agile methodologies for ensuring better quality of the overall product)   

Now let us look at the most basic situations whereby automation testing can be used and how we can adopt the same towards the realm of agile testing.