Agile testing Vs Traditional QA

 

Exploratory testing   : Business requirements on an agile project may not be as concrete as requirements on a traditional project; agile methods accept that change is a healthy and real part of software development. This means that test case generation may not be as cut-and-dried as it was in the past. Exploratory testing is an essential skill to uncover additional considerations for the product owner to evaluate.

Automation

Agile emphasizes automating as much as possible, but many teams struggle with when, how much and what tools to use. While continuous integration (CI) is an accepted developer practice, agile testing takes the lead on incorporating automated acceptance tests and creating regression test plans as part of CI.

Communication

Traditional QA engineers tend to rely on documents. Agile testing QA engineers don’t get a big requirements document as a basis for test cases and don’t get three months to write test cases before they see a working piece of code. They jump into the communication stream, which may be verbal, written or virtual, and assimilate the information they need.

Challenges with Traditional QA:

· Significant delays between when software is written and development receives feedback

· Defects found late in the process can have major implications when changed

· Changing business requirements affect test cases that have already been developed

· Siloed communications create risk that different groups may have different expectations of the final product

· Quality suffers and many QA activities get left out when testing is the last activity before a fixed release date

Benefits of Agile Testing:

· On-going feedback to developers allows testers to ask the right questions at the right time.

· Early identification of dependencies, technical or testing challenges and roadblocks.

· Embraces change as a healthy and real part of software development.

· Team collaboration helps everyone work together toward a common goal.

· Quality comes first because final acceptance criteria are established prior to the work beginning.

Learn more about Test First programming, and how to transition from traditional testing to agile testing.

Agile and Post-Its

For many,  Agile projects and Post-Its are synonyms, and do you agree this is a misconception ?.
This misconception has gone to such an extreme that, some believe that if you are not using post-it notes then you are not Agile. This looks funny for many Agilists, but this belief is true with many newbies.  One might be interested to understand the origin of this misconception.  Let us start with Information radiators.

Information Radiators

Information radiators are not a new concept. Lean thinkers and Toyota teams have been using this from many years. This concept was popularized in the Agile world by  Alistair Cockburn through his book Agile Software Development.   Since Post-its are handy and easy to use they became popular as information radiators across the globe.

In my opinion, Information radiators are just like any other tools. As the Agile manifesto says,
“Individuals and interactions over process and tools”.   So, one needs to be cautious of using the tools appropriately.

Now we know that Post-Its are just like any other tools. One should be cognizant of their usage in Agile projects. Even though, I have taken the example of using Post-Its here, this is applicable to all tools. Let us see some uses of Post-its.

Teams use Post-It notes to display

• the status of User Stories (Analysis, Design, Build, testing, etc)
• the quality stats
• Impediments/Risks/Issues
• etc.

My experience says that teams reject tools or the tools become unusable if

• wrong tools are used even in the right context
• If the right tools used in a wrong way

Especially, tools play a key role in large scale and long term Agile projects.

Large Scale and long term Agile projects

In the long term projects, over use of Post-its leads to what I am terming as “Post-It Noise”. The wall not only gets cluttered, but people will stop updating the walls.  There are a few who have reported stress due to the cluttering of wall due to unplanned growth of Post-its on the wall. 


I am not against using the Post-it notes  however one needs to be cognizant of  maintainability of them on the walls.  A wall with a beautiful display of Post-it not only adds value but gives a pleasant look.


  http://ericlefevre.net/wordpress/2007/11/17/reflecting-on-our-open-space-technology-event/

Summary

• Use Post-It notes based on need. If the teams are comfortable using flipcharts, White boards, let them use it. Don’t force people to use Post-It notes for every task.
• Arrange Post-its or cling on sheets in a pleasant way
• If you find the teams not updating the wall, do a retro and see if the wall is really adding value

Useful resources

• Visual Display of Quantitative information provides an overview of communicating the data effectively in a graphical way
• Visual Management of Agile Teams
• Trusting a yellow sticky ? Good luck with that
  
  
  
  

Velocity : Myths and Misconceptions

Velocity is one of the simplest but powerful tool to predict the future completion date of the project.

What is Velocity ?

Velocity is the capability of a particular team to deliver certain set of requirements within a specified duration.

It is very important to note that, this is true for a particular team with a fixed duration.  If the team and duration changes then the velocity changes automatically.

Based on my past experience interacting with several teams, I found that following misconceptions misguide the teams.   As an Agile coach or Scrum Master, it is very important to help the team to understand the true meaning of Velocity and drive away the myths and misconceptions.

Myths and Misconceptions 

Wrong	Right
Velocity is productivity	Remember,  Velocity is not productivity.  Productivity is how busy your team is. When some one is measuring productivity, they don’t measure the value generated out of it. Productivity is also measured against a standard.  However, Velocity is for a particular team, particular context and in a specified duration.  Velocity could be tied to business value.
Velocity Standardization	Many leaders think of standardizing velocity across multiple projects and sometimes throughout the organization.  This is totally wrong. As said before, each team is different, trying to enforce velocity of one team on another results in increased stress, loss of morale, productivity and finally loss of value to the customer.
Converting Velocity measured in Story Points to an absolute number in Person days	I have seen many Scrum Masters trying to convert the Velocity measured in Story Points to Person days. For example, 80 Story Points = 60 Person days.  Again, this is wrong. The above conversion basically freezes the delivery capability of the team upfront.  If the team is new to a technology or a business domain, the capability to deliver would be less. By freezing the story points upfront, the new team would struggle a lot and will get stressed out.
Comparing Velocity among teams	Since Velocity is specific to a team and within a context, it does not make sense to compare the velocities between teams.  A team comprising of Oracle Experts working on Oracle technology obviously will fare well as compared to a team of  fresh out of college put on a similar Oracle project.  Velocity of both the teams would be different. Never compare velocity between teams