Getting your project moving – Configuration and Testing

Getting your project moving – Configuration and Testing

The Configuration and Testing stage is usually when you expand your team and add several additional resources from your Nearshore team.  In doing this situation, the first thing I have every team member do is read the SOW or set of contractually obligated items that the customer has requested.  Once this has occurred, they should know and understand what they are legally obligated to do.  This is critical because in many cases there are gates to pass to the next level, and requirements/design is a gate to config/test.

111When you pass a gate there is a sign off that occurs.  If your new team members aren’t careful they can get off track either by their own doing or the customer’s and obligate you to complete not only what you contractually signed up for, but other items that customer requested and that they agreed to.  Once they have read the SOW, it’s on to reading the requirements and then design.  This will give the new team members a solid foundation of what they will be building and what the end user is trying to have the system do.

It is important to give the new team members access not only to the project management, but also members that have been part of the project in an ongoing basis.  This should allow them to understand some of the key decisions made and why design may look the way it does.  Also, make sure that the team has the capability to raise issues.  What I see a lot from people is that they tend to either work very hard to figure out a problem themselves, often time taking much longer than the task is allotted or they are asking someone how to fix/config something before they even give it a second thought.  These team members should understand what the expectation is and to whom they can reach out when they run into a problem that seems insurmountable.

Once configuration is complete, the team will move onto testing phases, unit test being first.  Testing in general gets less attention than it deserves and it is often used as a time shortening mechanism to bring project deadlines in.  The other big problem with unit testing is often the data used to test is absolute rubbish.  People will mock up test cases without a true knowledge of what task they are trying to fix.  Making sure that your team has a guide on how to conduct testing and formal process on what the layout of those testing will be.

Add that to the fact Unit Testing is so BORING, most people neglect it in a really bad way.   Having those guides and templates will get you through some of this, but having people to lean on in your team is paramount.

  • Posted by Doug Erb
  • On December 15, 2014