Project Managers, Bake Testing in to all of your Projects!

Well, this week I'm going to jump back in on the topic of quality - more importantly the need to build it in from the start.  This is a topic that many teams struggle with - how much testing is enough?  When do you call it good enough to move code in to production and celebrate success?

While I can't give you a definitive answer, it is important for you to look at each project and assess the risk of failure.  More importantly, you need to look at the various functional areas and ask yourself - what if there is an error, what will the impact be?  How will the application be used?  What is the audience?  What if this error is impacting one user?  What if this error is impacting multiple users?  Can downstream processes within the application - or dependent applications - continue to operate?

One of the questions that I've been asked by various developers - why are you making me do all this testing?  Isn't that the job of QA (Quality Assurance)?  Well, I hate to burst your bubble, but everyone is responsible for the quality of the end product.  Depending on the structure of the overall team involved in the project, the level of effort of the developers dials up or down.  If the organization has a strong QA Team, the developers may only be responsible for unit testing and some level of integration testing.  In other organizations, development may be responsible for everything up to and including user acceptance testing.  In web facing projects, business representatives may be integrated in to the Agile team and test directly with the developers - with the developers making changes on the spot.

I'm not going to try and convince you to pick one methodology or paradigm over another.  Each organization is unique and your organization has built the test structure that is being used for some set of reasons.  What I am going to do is explain some of the things that need to be done along the way - I can tell you who within the project I think is responsible, but this probably won't match up with your organization.  (I'll let you in on a little secret - it probably won't even match up with the way that my teams handle testing.  We're reworking how and who performs testing, so some of this is still up in the air as I write this blog entry.)

Whew, now that we've laid the ground work, let's dig in to the details and see if we can make some progress. Regardless of what methodology that you follow to develop software - the quality equation must be dealt with at the beginning of the project and must touch through all of the parts of your lifecycle to ensure that you're providing the highest quality software in to the production environment.  This is just as true in an Agile environment as it is within a waterfall environment.

So, let's touch base on some of the key things that need to be addressed by the overall test plan associated with your development effort:

1. Acceptance Criteria - when the team thinks it is done, what will be used to judge whether the software can move in to the production environment?
2. Integration Test Strategy - what are the application touch points that need to be addressed?  This includes system to system touch points - messaging, it includes intra-application - application sub-systems - that need to be tested, if your replicating data - it should include testing the replication mechanism, and it should also include testing of the security mechanisms used within the application.
3. Regression Test Strategy - is it necessary to perform a full regression test against the application, or is it valid to consider a limited regression test based on the functionality being touched by the development team?
4. Test Data - what data can be used to ensure that you can execute all of the tests needed to validate the functionality of the system?  This should include both positive and negative testing of the application.
5. Recovery Test Strategy - depending on the system you are building, you may have include functionality to allow the system to recover from various types of failure points - if so, you need to ensure that you test the recovery functionality?
6. Security Test Strategy - depending on your application, you may or may not need to include elements to secure the data being captured and/or manipulated by the system.  If this is the case, you need to ensure that you are testing the security elements to ensure that you are not allowing access to sensitive and secure data to individuals that do not have the proper authority.

On top of all that, each individual developer should be responsible for developing and executing unit tests against the code that they are developing.

All in all, there is a quite a bit of activity that surrounds the overall test strategy associated with the development process.  You may not formally address each of the individual items identified above, but in some way, these will get addressed throughout your project.  Either by accident or by design, someone should be answering the above questions before you put your code in to production.

As the Project Manager, it is to your benefit to ensure that these questions are being asked early.  This allows for the entire team to proactively address the test strategy and test requirements.  What good is it for development to be finalized if the development team doesn't understand how they will perform integration testing, or if the team doesn't understand how they will validate the acceptance criteria?

Next time, I'll dig in to some of the tactics that I've used - both within the current Teams that I work with and within previous organizations where I've worked.

In the meantime, feel free to chip in to the conversation and talk to me about the strategies that you use within your teams to manage your test strategies.  What are the components you feel are important and who within your teams has responsibility?  I'm not hear to judge what anyone does, but by sharing, we all might learn something new.

Tags: SDLC, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development, Security, Secure Development Lifecycle, Communication, Testing, QA

For more information on David L. Collison: LinkedIn Profile