5 steps to “better” bugs

by garyg 11. June 2010 11:07

While I’m sure we’d all rather avoid defects in our software all together, in a sufficiently complex application bugs (or regressions as we also call them) are as inevitable as death and taxes.  As an old mentor used to tell me, if you aren’t failing some of the time, you aren’t trying hard enough. The trick of course is catching them before the risk they present is fully realized, i.e. in front of the end user in a production environment.  Finding and remediating bugs falls under Project Quality Management in PMBOK (Project Management Body of Knowledge, Chapter 8).

So as long as you have them, you might as well get your moneys worth out of them.  Here’s how.  A “bug” in your software system represents a defect that needs to be remediated in some way, as effectively as you can, and without breaking anything else in the system.  So how do we achieve that ?  Well we need to find them early first with good testing in a well managed development cycle, but that's the subject of another future post.  Once we have located them we need to properly assess them.  At a minimum you want to know:

  1. What the defect is and what it impacts in the system.  This begins with a thorough description of the problem observed.  We are looking for a well written observation here, more than just a “its broken” but shorter than your system specification.  A paragraph should be about right.
  2. How do you reproduce it.  If the developer cant reproduce it, likely it will get closed as a “non reproducible” bug and will be a complete waste of time for everyone involved.  Be as exact as possible with clear steps and any particular data needed.
  3. Screen Shot or Video.  Window 7 has the built in Snipping Tool, but there are a lot of them out there.  The idea is a visible representation of what you just described.  Full motion video is even better for complicated issues. Microsoft has Expression Encoder 4 available for free , but there are many out there.
  4. Priority and Impact.   I’m a big fan of two level assessment of defects.  The first level, Priority should indicate how bad the problem on a numerical scale.  P1 meaning there is no way you can go forward without releasing it, down to P4, an inconvenience.  Impact should indicate what the financial or effort based impact of this error is (I-1 to I-4).  Will it take 5 weeks to fix or do we just need to comment out a line.  Often the original tester will not be able to assess the Impact, but this should be done by the person triaging the defects.  In a project management capacity this really represents Qualitative and Quantitative Risk Assessment.  More on this two level system concept in a future post.
  5. How did we fix it.  This is a critical step.  After a resolution is developed and verified, you need to detail it right in the defect document.  While we don’t need the source code here, you should link or reference the change set that fixed it.  Also, always be on the lookout for a best practice or new design pattern that worked well in approaching this defect or one that didn’t.  This is about building up your knowledgebase.

One last parting thought on defects.  While there are hundreds of theories and best practices on Software Quality Assurance and reducing bugs (and certainly worthwhile).  I like to remind people of a famous quote from Thomas Edison on the thousands of failed attempts to create the light bulb: “I have not failed. I've just found 10,000 ways that won't work.”  As long as we keep that in mind and learn from the mistakes we make during the creation process, we can indeed extract value from them rather than just writing them off as just being a costly byproduct.

Charter your way to a new project

by garyg 26. May 2010 11:43

I’ve gotten a lot of questions from people lately on what a project charter is, and what elements they should include in one to create a good one.  Created under the Initiating Process Group under PMBOK (Project Management Body of Knowledge), it is the one of the first steps performed once you have the initial concept for a project nailed down.  I’m going to cover the basics here of what it is, key features, and just as important, what it is NOT.

The “official” definition is a document that formally authorizes a project or phase of a project (for larger ones) and captures the initial requirements that satisfies the stakeholder expectations.  This can also be an iterative document that further defines or validates the decisions made in previous phases.  Items that are used to build the charter include:

  • Statement of work
  • The Business Case
  • Enterprise Environmental Factors  (corporate culture, government regulations, infrastructure, stakeholder risk tolerances, etc.)
  • Organizational Process Assets (standard processes, templates, historical info, financial data, etc.)
  • The Contract (may not have one if you are an internal team)

The main thing you want to keep in mind while building the Project Charter is that it is not a replacement or extension of the contract.  You need to things in plain business speak as much as possible.  We will undoubtedly be pulling items from the contract, but it needs to readable and tell a fluent but brief story that clearly conveys the business value.  You will also want to cover any significant risks, and  the costs of course.  The goal we are aiming for is authorization to proceed with project as described.

One question I from internal project teams working within a larger company is what to do about a contract.  Most of the time it wont exist and getting one signed isn’t going to happen.  The PMBOK doesn’t really cover that situation except for the obvious, if it isn’t there you can’t use it.  I would suggest that you could refer to your groups charter (if you have a long standing and well written one) at this point and make specific references to it in your Project Charter.

Lastly you need to consider a signature section.  For projects with an external group I consider it a must.  For internal groups you need to let your company culture be your guide.  If your company requires signatures on PO’s and other internal agreements they you’ll want to make sure that you are gathering them on the Project Charter as well.  If not, a simple acknowledgement of receipt (i.e. email) by all authorizing parties may suffice.

Are You Pitching Your Project Based on Burger Capacity?

by garyg 27. April 2010 11:29

I’m in Wal-Mart over the weekend shopping for a gas grill for my camp.  Now I’m not really into this at all since I mainly burn things on the grill, but the last one up and died on us so I had no choice if I wanted anything grilled this summer.  So here I am looking at the display of grills, about 10 if I remember.  They are all presented in much the same way, listing number of burners, square inches of cooking space, and in one case a gas consumption rate.  All except one, which happened to list burger capacity.  That’s right, burger capacity. I laughed until I thought about it a little more. It was advertising a capacity of 22 burgers.

Now you are probably thinking no one in their right mind needs to make 22 burgers at a meal.  I didn’t either, but I was definitely hungry (never buy anything food related when you are hungry), and I know one of my pet peeves is how long it takes to get all of them cooked when we do a cookout.  Everyone is done eating by the time you get to enjoy one.  With that kind of capacity I could eat with everyone else, and make up for my low yield count (sounds better than saying I can’t really cook).  So what does this have to do with pitching a project to a sponsor or review board ?  Stay with me on this.

Every one of those grills was giving me stats and data I couldn’t care less about.  All except the one, which directly addressed the one core need I had.  The point to this is that in this highly competitive environment, your project is likely competing for funding in a crowded portfolio.  They are all completing ROI in one year and “green”.  You need to find and address your project sponsors key needs beyond these.  We can’t afford to simply present the requisite ROI data, you need to find a differentiator in either escalating business capacity, increased order rates per day, more visitors per hour, etc. Whatever your businesses core need is, find it and align your project to it.  If you can’t, find a project that can because projects that can will get consistently funded.

7 Tips on Managing Virtual Project Teams

by garyg 16. April 2010 03:01

Its a Team, Virtually

One area that I never seem to see covered enough in Project Management literature is Virtual Teams, or more specifically how to manage them without it consuming your entire life.  Virtual teams are defined as teams whose members operate across space, time, and organizational boundaries and are linked through information technologies to achieve organizational tasks (or in your case, project tasks). Unlike conventional teams, virtual team members are not co-located, so they are more dependent on information technologies rather than face-to-face interaction.

So what does this mean for you, the beleaguered Project Manager who has just been told your new project team is scattered across the ends of the earth rather than down the hall?  Well unless you manage communication carefully you can loose control of your project faster than you ever thought possible.  As Project Managers we know that we manage more by influence than direct authority.  This will never be more clear to you than when you can’t realistically gather your team in a room and look everyone in the eye.   In some cases asynchronous communication (email, news group postings, voicemail, etc) may represent the majority of your communication.  Just don’t let it be the sole method you use (see below).

It CAN be a Competitive Advantage

The bulk of the press of virtual teams goes to off-shoring but the tips here can also be successfully applied to teams on this side of the pond as well.  Also depending on the nature of your project you may be able to benefit by extending the workday into different time zones (international teams may even be used for “follow the sun” style planning). 

Some Tips

So your probably saying enough already, on with the tips.  Here we go:

  1. Do not rely solely on email or other asynchronous communication methods.  This may seem obvious but I’ve seen more than one junior PM and a few senior PM’s who should have known better fall into this trap.  If you are forced to use it for the bulk of your communication due to time zone differences, ensure you are scheduling regular good old live synchronous communication (i.e. a conference call) at regular scheduled intervals.
  2. Accountability is key.  Insist on frequent detailed status updates indicating progress on key milestones.  It isn’t enough that your getting task updates out of MS Project, you are looking for complete, transparent, and ongoing understanding.  I typically require stoplight style (look for a discussion on this in a future post) for any of my direct reports to make sure we both understand what’s expected and needed to keep things moving.
  3. Embrace Video Conferencing.  This technology used to be outrageously expensive but now with a web cam and and headset anyone can look like a pro.  There are some really high quality proprietary services out there but at very least Skype is free and easy to set up.  Just test everything before the “big call”.  Eye contact is invaluable and you’ll wonder how you ever got by without it.
  4. Multiple Mediums.  Use every communication method available to you.  I’m especially fond of Microsoft SharePoint team discussion sites where communication is threaded and can be easily referred back to by all stakeholder.  Some people just seem to respond better to some mediums than others so this will keep misunderstandings to a minimum.  This is especially important in multi-cultural teams.
  5. Get face to face.  This also sounds obvious but sometimes you need to go to the mountain.  Ideally having everyone in a big room for a “kick off” meeting would be ideal, but if you can’t do that make plans for occasional face time even if its one on one.
  6. Get to know your team.  This is a tough one for some of us in the IT field.  Get to know and be interested in your people.  Spend time bonding (even if just over the phone) on non-work items.  People are much less likely to let down someone they have a personal relationship with than that antiseptic PM who is only interested in the project status.
  7. Keep the option open to co-locate.  If possible this can be a lifesaver.  I always try and negotiate this in my contracts or charters.  If things start to go wrong on a critical project you want the ability to relocate people to the same work area if it seems misunderstandings are mounting and getting in the way of progress.  This can be enormously expensive so you need to account for this in your Risk Management Plan.  I find just knowing I have this option can keep things moving along.

I hope at least one of these can help you out in a future or current project.  In a follow on to this post I’ll discuss potential effects of Virtual Teams on your Communications Management Plan and my theory on how it effects the Communication Channel formula used in the PMBOK (Project Management Body of Knowledge).

Can you be both hands-on technical and a good Project Manager?

by garyg 10. April 2010 10:05

This has to be one of the most heated debates I’ve ever seen play out in recent memory.  Recently someone asked this question on a LinkedIn PMP only discussion (later deleted by LinkedIn) group.   This is sort of one of those Red vs. Blue questions and  your ability and experience tends to shape your opinion in this area. 

In a perfectly executed large 250+ resource project following the PMBOK (Project Management Body of Knowledge) processes you should be able to rely solely on the science, process, and SME’s (Subject Matter Experts) while you concentrate on the business of Project Management.  Actually you’d be foolish to think your individual technical contribution would even put a dent in the plan in a truly large scale multi-year project.  Lately however, these ideal situations and projects are less the norm and more the exception as organizations are more likely to be concentrating on the smaller, rapid ROI projects in the portfolio.

More often than not some balance needs to be struck.  Either you can’t completely rely on your SME’s, your teams knowledge ends up light in an area you are strong in, or the project is just too small and fast moving for you not to be a little more “hands-on”.  In these cases as a PM your ability to jump in along side your team (as long as you aren’t losing sight of your primary role as PM) could only be an asset. 

Also if you are Crashing or Fast Tracking  (schedule compression techniques) a project, and requiring your team work into a holiday weekend, you’d better be prepared to put in some work product yourself or risk being compared to the Pointy Haired Boss ;-).

So do I think we’ve settled the debate here ?  Not by a long shot.  However if we can generate some lively and useful discussion (especially among our stakeholders) than it is worthy of engaging.

Preventing multiple plug-in request calls with IsRedirectFollow()

by garyg 10. April 2010 10:01

Figured I'd share something I found valuable.  Did you ever make a call to a request level plug-in in a Visual Studio 2008 WebTest and get multiple calls to the same plug-in because of a 302 redirect?  Well I did and took me a little bit to find out a way to prevent it.
When you are making the call in your code, decide if it should run based on IsRedirectFollow property (http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.webtesting.webtestrequest.isredirectfollow(VS.80).aspx)
As an example:

  1: namespace MyAppTests
  2: {
  3:     public class GetSomethingPlease: WebTestRequestPlugin
  4:     {
  6:         public override void PostRequest(object sender, PostRequestEventArgs e)
  7:         {
  8:             if (e.Request.IsRedirectFollow == false) //only want to run this on on a primary, not a redirect
  9:             {
 10:                 //do something here
 11:              }
 12:          }
 13:       }
 14: }

Anyway, I hope this helps someone else a little further along.  It works in VS2008 and VS2010 as well.  I'm sure there could be a more efficient way, but this worked in a pinch ;-)

Using Visual Studio 2008 Web Test Request Plug-In to Check results in a SQL DB

by garyg 10. April 2010 06:12

Some of my regular readers said they wanted to see more "technical" content, so here is one that perplexed me a while.

While assisting a client with setting up an automating testing environment using Visual Studio 2008 Web Tests (among other things) we uncovered a need to check the results of a transaction halfway through, then when its complete to verify the results of the test.

Now I know what experienced testers and SQA people are thinking, "why didn't you just use an Extraction rule from a results page and validate that?". Yes, that's the first thing I wanted to have done as well and that works quite well under most circumstances.

Unfortunately on this particular application there is no real "confirmation" screen that displays the results of the transaction, just kind of a yeah I did or no I didn't kind of page. Not good enough in our case where I wanted to have real transaction results.

Since time was very short and I'm still working with the group to adopt more "test friendly" designs we needed a sure way of verifying the results. I though that this check DB feature would be a native feature in the VSTS2008 Web Test, but the only DB connectivity included out of the box was binding to a DB for data driven testing (which is very useful as well).

So our option was a to create a request level plug-in to go out to the DB and check the transaction results, and write them back to the test results.

My goals here were:

  1. Connects to an SQL DB.
  2. Builds a query string using a Context parameter
  3. Puts the value pulled from the DB back into another Context parameter for use in follow on requests.

Here is how I did it (in a plug-in 101 type format), complete with code snippet I used to create this:

1. Create the following in a class library in your test project (that part is covered in detail in MSDN), compile, and reference it:

  1: using System.Text;
  3: using Microsoft.VisualStudio.TestTools.WebTesting;
  5: using System.Data.SqlClient;
  9: namespace Test1
 10: {
 12:     public class MyRequestPlugin : WebTestRequestPlugin
 13:     {
 15:         public override void PostRequest(object sender, PostRequestEventArgs e)
 16:         {
 18:             base.PostRequest(sender, e);
 20:             int CustomerID = 0;
 23:             // this is my connection string
 24:             String connectionString = "Persist Security Info=False;Initial Catalog=dbname;Data Source=machinename; User Id=dbuser;Password=somepassword";
 27:             // select statement getting just the field I need.  Note that if this is;
 28:             // messed up it may throw an error saying is cant open the db.;
 29:             // This is misleading, its probably your select; 
 30:             SqlConnection connection = new SqlConnection(connectionString);
 32:             string queryString = "Select CustomerID from Orders where OrderID=" + e.WebTest.Context["OrderID"];
 36:             SqlCommand command = new SqlCommand(queryString, connection);
 38:             command.Connection.Open();
 40:             SqlDataReader reader = command.ExecuteReader();
 42:             while (reader.Read())
 43:             {
 45:                 CustomerID = Convert.ToInt32(reader[0]);
 47:             }
 49:             e.WebTest.Context.Add("CustomerID", CustomerID);
 53:         }
 57:         public override void PreRequest(object sender, PreRequestEventArgs e)
 58:         {
 60:             base.PreRequest(sender, e);
 62:         }
 64:     }
 66: }

2. Insert the Request Plug-in (if you compiled and referenced it, it will be in the list.) AFTER the Context parameter you are using (in a production test you'll need error control, errors in a Plug-in are ugly and will mess up your results).

This whole exercise made think that a "data check" validation rule of sorts really should be part of this product.

Anyway hope this helps someone else a little further along some day using web tests. This same method also works in Visual Studio 2010 as well.

Are you learning from your Lessons Learned?

by garyg 9. March 2010 10:17

I'm always happy to see an organization I'm working with recording "lessons learned" documentation from multiple iterations of the same product, or successive project engagement.  The real key however is taking this information and turning into action items that help you get further along.  Too often I see teams committing items to Lessons Learned documents more like a confessional than a plan to not make the same mistake, or repeat a successful technique.

There are some simple steps we can use to help ensure a learning experience:

  1. Document collaboratively.  This will avoid personal attacks and maximize the effort. I find it best to conduct several short meetings to get this done than one long one (again no confessionals here).
  2. Successes and Failures.  Too often people are quick to point out failures but its just important to make sure we don't miss the things that worked well the next time.
  3. Everyone Participates.  These sessions aren't just for the PM's, get everyone involved in the project involved.  This would also include your outside vendors if the relationship allows.
  4. Rinse and Repeat.  Take your list of Lessons Learned and put them into documents used in every project Initialization phase.

Thats about it.  Hopefully we are all a few short steps away from the next level of productivity.


About the author

Gary Gauvin is a 20+ year Information Technologies industry leader, currently working as the Director of Application Lifecycle Management for CD-Adapco, a leading developer of CFD/CAE solutions. Working in both enterprise environments and small businesses, Gary enjoys bringing ROI to the organizations he works with through strategic management and getting hands-on wherever practical. Among other qualifications, Gary holds a Bachelor of Science in Information Technologies, an MBA, a PMP (Project Management Professional) certification, and PSM (Professional Scrum Master) certification.  Gary has also been recognized as a Microsoft Most Valuable Professional.

LinkedIn Profile: http://www.linkedin.com/in/garypgauvin

(Note: Comments on this blog are moderated for content and relevancy)


Month List

Page List