Subscribe via E-mail

Your email:

published qa papers free

Browse by Tag

Posts by Month

Follow Me

NTT DATA Canada Discussion Room

Current Articles | RSS Feed RSS Feed

Agile Testing Methodology

 

Agile Testing Methodology

Your new company follows Agile Testing Methodology, what should you know?

Agile Testing resized 600

Written by: Paritosh Dave

The objective of this blog series is to highlight and discuss various Agile testing tips and techniques, learnt from both client engagements (working as part of Agile testing teams) and from learning done through reading on the topic.  

Although the focus of this article is to talk about software testing tips in an agile process, Agile Testing Methodology will be discussed.  None of the methodologies like Scrum or Extreme programming treat testing/testers as separate discipline/group. The idea is to create and maintain a self-organizing team with various skill sets, each person willing to contribute and helping other group members,   wearing different hat, as needed.

Agile development has caught worldwide attention in the last few years and is now the preferred software development methodology for most technical companies and SMBs. Organizations have made changes and adjustments to their existing development process, which have resulted in acceptance, usage and success of agile processes.  Many organizations have discarded the older waterfall model in favor of Agile.

There is no hard wired, prescribed way of determining or carrying out the agile process. It is up to the organization to make best use of it’s underlying philosophies. Some organizations claim to follow the Agile Process, but in fact, unknowingly, are really executing a hybrid of it with waterfall.  There are organizations who have tweaked the process successfully, to align it more with their internal process/work culture. There are some organizations who have already taken up agile for some of it’s departments/products but they feel that some other project/product are not suitable for agile processes.  These organizations are said to be following a Hybrid process.  In all these cases,  as long as they derive benefits and success of using agile methodology and in turn observe measurable productivity and quality gains, the purpose is served. One common result that will be observed in almost all the scenarios is that they have repeatedly provided incremental business value, with better quality.

The Agile way of doing things has ushered in an era of collaborative working, short feedback cycles, group thinking/working. All while improving quality and costs.

This is appropriate time to review the famous agile manifesto, agreed upon back in February 2001

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and Interactions over processes and tools

Working Software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value on items on the right, we value items on the left more”

The role of a tester in agile process has also undergone many changes. The testing is not compartmentalized but an integrated part of the group working and progress. In the next part of the series, I will condense the tips and techniques of agile testing into 10 points.

The opinions expressed on this discussion room are writer's and don't necessarily represent NTT DATA Canada's positions, strategies or opinions.

Comments

From Vikas Garg on the QuickTest Professional Group on Linkedin 
 
• Jorrit: I personally believe that if your company is following agility then you should be well aware of the requirements of the particular module that is going to be released in that release also you should be known to the zeitgeist of the event that will be going to take place. As the best part of agility is that you deliver module by module and need not to focus on the overall system requirement. But for the successful release of the module you will have to follow the time-line in the deadly manner. 
 
If you are missing a single deadline of any task then whole the project is going to be impacted. Also it may cost you more as delay means more time and time means more money. Which will gradually increase in proportional to the number of employees.
Posted @ Saturday, January 21, 2012 8:31 AM by JORRIT WIT
From MADHUSUDHAN KONDURU off Linkedin 
 
• Firstly strong communication. how to select stories (i.e, out of n requirements got to select few requirements) . we to select stories with respect to 2 factors 1: size of the function 2: complexity of the function. The project manager will give u some points say 2 for low 5 for medium 7 for high for size and same for complexity ...so now say we select 6 stories to develop n test in 2 weeks time so now the 6 stories will be given points ( how complex the story is n wat size the story is). once finalized 1st iteration is done ( the entire process above is called ITERATION). In agile max number of employees in a team should be 12 n iteration varies from 1 week to 4 weeks. everyday morning we have stand up meeting for 15 min, we discuss about the task completed, task performing today, task to be done and problems faced. if we have hurdles ( say if i am a tester if i doubt arises say a login page accepts more than 18 characters so now i need to approach the concerned developer i dont have to wait till stand up meeting i can just communicate on the spot for hurdle meeting). as a tester i do manual testing for the stories if all the test pass i automate for each story. if there is a bug i will log the bug to developer and wait until fix. at end of 2 week i.e 1St ITERATION we have retrospective meeting were project manager or scrum master , developers, testers, designers and business rep will conclude the task accomplished in 2 weeks number of stories completed number of stories to be fixed in next ITERATION and have to prepare a demo report for SHOW CASE OR DEMO MEETING the meeting will be held on same day evening were all the business heads will be invited and the scrum master show cases the stories completed and their functionality, the UAT people suggest some changes if need. the fed back will be rectified in next ITERATION.
Posted @ Saturday, January 21, 2012 8:33 AM by JORRIT WIT
From Anurag parmar off Linkedin - agile needs strong involvement of clients, main challenges faced during client communication, involvement of client in the decision making process of selecting stories. 
 
 
 
- some time company has to train them for agile.  
 
 
 
- in agile team members also need to be fine tune with each other on their methodology while working, problem solving. 
 
 
 
- agile model is majorly depend on nature of project and nature of requirements. some time agile can create magic and some time fail in time line. 
 
 
 
- agile needs experienced managers to handle the issues and challanges.
Posted @ Monday, January 23, 2012 9:47 AM by JORRIT WIT
Posted by Anshuman Duggal off Linkedin  
 
Agile says do a little bit of everything valuable all the time, get feedback and adapt continuously to deliver value just in time to a changing market. The organization is successful, and the team's work is valued.  
 
 
 
Twelve principles underlie the Agile Manifesto: 
 
Customer satisfaction by rapid delivery of useful software 
 
Welcome changing requirements, even late in development 
 
Working software is delivered frequently (weeks rather than months) 
 
Working software is the principal measure of progress 
 
Sustainable development, able to maintain a constant pace 
 
Close, daily co-operation between business people and developers 
 
Face-to-face conversation is the best form of communication (co-location) 
 
Projects are built around motivated individuals, who should be trusted 
 
Continuous attention to technical excellence and good design 
 
Simplicity 
 
Self-organizing teams 
 
Regular adaptation to changing circumstances  
 
Posted @ Monday, January 23, 2012 3:23 by JORRIT WIT
Very good topic Paritosh. Here are a couple ideas on this topic. 
1. Test as early as possible being consistent with the "test driven development” practice that is common in agile.  
2. For every functional aspect, involve clients as early as possible and assume they will change their mind about their own product when they see what the results.  
3. Trust your programmers and give them some time to build some partial automatic tests that can be done in a reasonable amount of time. (I said partial because normally is not practical to be 100% automatic) 
4. Make sure there is some sort of code review / architectural review practice in place that is always continually looking at the code you are writing. Truly agile projects ultimately rely on good architectural and coding practices that produces code for reuse, follow standards, etc. From a coding practice perspective, agile development is more technically demanding than waterfall.  
Posted @ Monday, January 23, 2012 3:51 by Pablo Elustondo
Madhusudan : Thanks for your comments about story estimation. I might add here that the retrospective meeting is conducted on last sprint day, after the review meeting. The team members makes analysis of the sprint and take the lessons learned to improve productivity, quality etc 
 
Anurag and Anshuman - Good observations. In the next part of the blog, I'll be talking more of what you pointed out. 
Posted @ Monday, January 23, 2012 11:48 by paritosh dave
Posted by Kumar Madduri off Linked in. 
 
There are a series of metrics and statistics I would look at starting from SDLC methodologies followed and what one is looking in agile as the testing alone can't go agile or Scrum, its the complete IT and Business that needs to be in Sync.  
 
 
 
Posted @ Thursday, January 26, 2012 7:37 AM by JORRIT WIT
Thank you for sharing your thoughts along with this post. Agile manifesto has been around for a while now; while it is no longer a new methodology and has been enforced in varied forms in various organizations, it still requires a lot of maturity in adopting it with the right balance.I will share it with other QA testing experts to see more comments.
Posted @ Thursday, May 17, 2012 2:05 AM by QA Thought Leaders
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics