This is the final blog in a series that I started nearly 8 weeks ago.  As a brief refresher, my goal has been to write a blog on one habit per week, and I’m very thankful that I’ve been able to do that. As I’ve mentioned in the previous habits, the content for this series has been developed over many years and hundreds of client projects.  In fact, in addition to applying the habits to all of our client projects, we often speak on these habits as part of a larger session we call “CPR”, where we discuss project rescue and how projects can avoid having to be rescued.  The ultimate goal here is to present these habits in a short and succinct manner, so that you can have clear takeaways to immediately put into practice on your projects. 

I hope you have enjoyed reading these habits, and more importantly I hope that you found value in them and will begin to apply some, if not all, right away.  If you have not yet read habits 1-6, I would encourage you to start there.  I have provided links below to the first six habits that that we have looked at so far.

Habit 1: Chart Your Journey

Habit 2: Stay The Course

Habit 3: Invest In The Unseen

Habit 4: Avoid The Silver Bullet Syndrome

Habit 5: Live In The Past

Habit 6: Build It and They May Not Come

So, without further ado, let’s jump in to the final habit. 

Habit 7: Build Once, Test Twice

You’ve heard the saying, right?  “Measure twice, cut once.”  Having many carpenters in my family, I certainly heard that saying a lot throughout my life.  For this final habit, I wanted to take that saying and use it to illustrate a phenomenon that we often see in technology  projects – lack of testing.  I call it a phenomenon, because it often defies logic.  Regardless of the desire or the knowledge that “testing is important,” quality assurance (QA) seems to be the first and often the largest area affected when budgets or scope are reduced. 

In this blog, I would like to propose a few practical examples of QA, ways to make QA a part of every project, and provide a case for why it is critical that all projects have the proper QA and testing.

First, never underestimate the importance of testing.  If you've followed us for any length of time, you will know that we are big proponents of leveraging platforms to solve real, business problems.  However, while adoption of these platforms has increased, the perceived need for testing has decreased.  What we often find is that organizations dramatically reduce the amount of QA that is taking place on platform projects.  This is an interesting notion, because in theory the more of the platform that you leverage, the less “custom work” there is to test, correct?  Yes, but…while leveraging platforms will absolutely reduce some of your testing and QA, it will not eliminate it.  Please allow me to explain. 

One of the benefits of leveraging a platform such as SharePoint, Dynamics CRM, Salesforce.com, or any other platform you can dream up is that it provides much of the foundation and framework that you need in order to develop very robust, scalable and specific solutions to today’s business challenges.  Because of this, we do see the testing for foundational items such as database connectivity and the security model (just 2 examples) reduced quite a bit.  That’s one of many powerful benefits a platform – the core functionality does not need to be tested to ensure it works; you simply expect it to work!  However, while testing of these components is reduced if not eliminated, testing the integration of these components with your customizations does need to be tested.  In addition, even if you are utilizing many of the out-of-the-box (OOTB) functionality of the platform, it too should still be tested against your specification document (or user story / requirements) to ensure that it actually does satisfy the requirement(s).  As a simple example, if you were implementing a custom SharePoint view within a document library, while this is native functionality for SharePoint, you should still fully test the view to ensure that it shows what it should, groups as it should, and fully meets the requirement.  Again, there are many examples such as this where you should plan to test the OOTB functionality, even though it isn’t custom development.

Second, always leverage a dedicated QA team.  Let me first say that this is a best practice, we also realize that not every organization has the resources  to have a dedicated QA team.  The main point here is to have a team outside of your core project team that can test the functionality using test scripts, requirements and/or user stories.  In addition, if you can pull it off, it helps tremendously for this team to have varying skill sets and backgrounds.  We all know that our end-users are very creative and will find a way to do something that we did not expect them to do, so it helps to have various users on your team that can approach the functionality from different angles.

Last, but certainly not least, go back to user adoption.  We have seen very little that hurts projects more than a deployment that is riddled with errors and functionality that simply doesn’t work.  Once your end-users have lost trust and faith that projects will be delivered as close to error-free as possible, it is extremely difficult to regain that trust.  As I said at the start of this blog, measure twice and cut once – I promise, it will pay dividends.

I certainly hope this final habit - and this entire series - has been helpful and relevant for you.  The goal has been to keep these short and sweet, so my desire is that you will be able to take away a few nuggets of wisdom and experience from this series.  We’d love to hear from you on this habit or the entire series, and how you are beginning to apply some of these habits to your projects.

For more information on C5 Insight or this blog entry, please Contact Us.