Quality assurance ideas in agile developement


Nowadays being agile is cool. All people is speaking about Scrum and agile development. There’s even people going far away and speak about Kanban. Agile development isn’t a new idea. Maybe it’s only setting up a name to an old one.Quality assurance activities should be designed to identify missing, ineffective or inefficient policies, processes and procedures used in the project. According to the PMBOK guide there’s a tool to perform quality audits called root analysis. Basically root analysis aims to find the source and the solution of the problem and helps to determine inefficiencies. Performed it regularly you can fine tune processes. The steps to perform root analysis technique: 

  • Define the problem
  • Gather data to describe the problem
  • Determine possible causes
  • Select the root cause
  • Develop a solution strategy
  • Test and evaluate the solution

Clients must bear in mind agile development means they must take actively part within the development process. Maybe some clients don’t like this way of work. Maybe they prefer to pay for the service or deliverable and let the work for us. But really it worth the effort. Work close to the client is one of the principles of agile development. One important action to obtain the commitment between both parts is give access to the customer to the Bug Tracker. With this simple step our customer can track our work. But there’s a problem. Our bug tracker is not only an internal development tool now. It has become also into a communication tool. That’s means developers maybe decide don’t report internal technical things because they don’t want to be read by the clients.

Bug trackers can help us in our agile developement. There’s a lot of bug tracking software over there. Open source software you can install in your host, such as Mantis or Track. You can find also hosted solutions, free or paid ones. Probably Jira is the most famous and widely used software(not a free software).

Currently I’m thinking about the bug life cycle. I’m trying to standardize the way we use to face the bugs. I’ve created the following flowchart:

 

What do you think about this flow chart? Do You think is it is up to your requirements?

About these ads

About Gonzalo Ayuso

Web Architect specialized in Open Source technologies. PHP, Python, JQuery, Dojo, PostgreSQL, CouchDB and node.js but always learning.

Posted on October 24, 2010, in Project Management, Technology, tips. Bookmark the permalink. 2 Comments.

  1. I think this diagram lacks some important steps that we added in my company.
    A fix process must be integrated within a support lifecycle and continuous improvement methodology.
    First there is the Error discovery, which can be a mail, a ticket in a tracker….one must then acknowledge the client contact or the product owner that the bug is effective or not and we will investigated by “this person” or “this team” and that we’ll be back in touch at 5pm today….

    Then your flowchart is perfect to me until “approve changes” where we must not forget to send back to the client when the bug resolution is scheduled if the change is approved.

    When the bug fix is delivered, one must now consolidate/track/note the cause of the error to improve the development process to avoid it to occur again. If it is not done at least on a quarter schedule, the only value a team is building is the sum of the person experiences…

    • Flowchart updated. I’m agree with you. Client must known if change is approved or not and he must known we are working on it (or not). In fact client must have access to the Bug tracker to follow the issue.

      The access to the Bug tracker normally is a source of discussion in the development teams. Sometimes when we open the bugtracker to the client, the Bugtraker becomes into a commercial tool instead of a development tool. For example if you see something really wrong within source code, will you report it knowing your client is reading? Or maybe you will solve the problem and later you will log it when it’s solved? I have seen teams who think open bugtracker to the client is mandatory, but another teams who think it’s a terrible mistake.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 990 other followers

%d bloggers like this: