Blog

  • Improving Quality through Testing as part of Implementation

    Improving Quality through Testing as part of Implementation

    I do not want to shock you, but software often has bugs.  We may call these “features” or “known issues,” but in the end they are bugs.  These defects are just part of being human and trying to craft large and complex solutions.  Sometimes we make mistakes.  The challenge with these errors is finding and eradicating them whenever possible.  Thus, improving quality.  That is where testing comes in.

    Not a Popular Focus

    It is hard to argue that QA and testing are treated with proper respect.  These tasks that are critical for good software are often dealt with as a “nice-to-have.”  Whether the focus is unit, system, or acceptance testing the needed time is rarely allotted.

    Software development has advanced and embraced the design and deployment steps along with implementation.  However, testing is still lagging in how we approach it.

    Embrace All Testing Types

    These are sweeping statements so your experience may be very different.  However, most projects are starting to embrace the value of testing, just in baby steps.  Development tools have been instrumental in this progress.  The ability to create and run unit tests along with implementation has made it almost an automatic step.  Unfortunately, this does not extend to the system and acceptance testing.  Even worse, that is where most bugs get through to a customer.

    Unit testing is great, but just the first step.  A good strategy will include system testing to make sure the pieces fit together and work properly.  Once that is accomplished, a solid acceptance plan is needed to ensure that requirements have been met. These testing types may have different names in your company, but they boil down to three areas.  Test the code modules and components by themselves.  Then verify that the modules work together properly.  Finally, check that the solution matches the original requirements.  Much like a game of telephone, it is not hard to confuse the original goals by the time we get to the end of the project.

    Improving Quality Requires Testing Throughout Implementation

    The problems with making testing a step at the end of coding are cost, effectiveness, and perception.  Cost is a function of fixing issues that arise.  There are several articles written about how the cost of fixing a bug increases as you move along the life cycle.  Thus, we will take that as a given.  The sooner a bug is found, the less the cost of fixing it.  Therefore, finding bugs early in development leave us more resources to create better quality software and deliver it on schedule.

    The impact of timing on the effectiveness of testing is not often discussed.  However, it becomes evident when we look at the situation.  A unit test or similar testing early on in the life cycle will have limited inputs and outputs to validate.  The permutations of data inputs and output are going to be small when compared to larger systems.  Once you start putting together those “units” the complexity increases exponentially.  Thus, testing the system increase in complexity as well.  Likewise, the likelihood of 100% test coverage starts to decrease dramatically.  When we include proper testing earlier in the life cycle, we can implement it before the software complexity gets out of hand.

    The Perception of Testing

    Finally, we need to look at how timing can impact the perception of testing.  When it is included throughout the implementation portion, it becomes just a part of development.  It works hand-in-hand with creating software, just like writing, compiling, and commenting code.  However, when testing comes at the end of the implementation phase, it can be seen as a blocker.  The software project was chugging along fine until the testing team stopped progress and forced the developers to go back and fix bugs.  This approach puts QA staff in the position of being the guardians of a release and the ones that bear the burden of saying whether it can proceed.  Thus, we put QA staff in the awkward position of doing their job right or letting us “ship” the product.

    Baby Steps

    I am a big fan of steady growth and improvement.  The issues listed above can be significant and even overwhelming to address in one shot. Instead, look for ways to make improvements with each release.  Start from simple tasks like good unit tests, get comfortable with them and then move forward.  Find the means to document, reproduce, and then automate as much as possible.  Once testing becomes automated and part of your daily development you will see dramatic improvements in software quality.  It is time for us to move software creation out of the realm of dark arts and into the light of reproducible high-quality processes.

  • Using Milestones For Project Communication and Success

    Using Milestones For Project Communication and Success

    One of the important parts of tracking project progress is defining milestones.  These are points during the project where the required tasks and the goals for time meet.  It only makes sense that the definition of milestones and how they are treated are an important part of project success.

    Defining Milestones Simplified

    Although these steps in the definition process are necessary, that does not mean they have to be complex.  Every project is different, but I have found these guidelines useful.  In fact, I use them every time we need to craft milestones.

    1. Milestones must have a deliverable

    Defining a deliverable for a milestone is rarely a problem.  However, I have seen vague descriptions like “complete the application UI” as the total of the objective.  This description is a start, but not truly definable.  Nor is there a deliverable mentioned.  We have to be able to say a milestone is complete (or not) without ambiguity.  This example is improved by including a UI demo to be delivered as part of the objective.

    2. The deliverable must be visible to the customer

    This point is often an issue during a project.  There will be a step that includes securing the site or building a backend database.  Unfortunately, the implementation does not have a visible result. That is not okay.  Find a way to craft the deliverable so that the customer can see that progress has been made.  The progress may be a login screen tied to an ACL or the result of some select statements to show default data in a database.  When in doubt, modify the milestones, so the “invisible” work is part of visible steps.

    3. Provide a Method For Feedback

    Milestones are more than just getting work done.  They are also an opportunity to gather customer feedback.  Use the milestone deliverables as a way to verify the implementation is still on track with the vision and goals of the client.  This option helps deliver a successful project instead of just delivering a project.

    Defining Milestones For Success

    We have already alluded to milestones being about more than progress.  They can also be designed to improve the chances of a successful project.  As mentioned earlier, the first step is to ensure that customer feedback is part of delivering any milestone.  This goal can be achieved through regular demos and review sessions that coincide with milestone deliverables.  I find that presenting milestone deliverables in some way is useful for drawing out feedback as well as a sort of test of the deliverables.  That extra look over the deliverable can be a sanity check well also revealing gaps.

    Scheduling the milestones in a way to reduce risk is recommended.  When the milestones that have the most risk are tackled early in a project, it allows for the less risky steps to be used to make up time.  Of course, that is not always possible.  In most cases, the work on challenging items early in a project is a way to bring up estimation issues and slippage sooner.

    Defining Milestones in a Vacuum

    We are not always a part of the project definition.  Thus, we run into those projects that are ill-defined and yet, we want to be successful.  In these cases, I find it is best to break the work you control (or are assigned) into milestones.  Your position in the team may not allow for customer feedback as part of milestone delivery.  However, you can usually find someone to which the deliverable can be presented.  Every little bit helps.

    Even the largest projects can be broken down into smaller “sub-projects.”  This step is where milestones come into play.  Thus, an over-whelming or “impossible” task becomes more manageable.  Since there are so many ways projects can go wrong we need to use tools like milestones to improve our chances for success wherever possible.

  • The Importance of Communicating Status and Plans

    The Importance of Communicating Status and Plans

    One of the best ways to control project success is to meet or exceed expectations.  One of the best ways to understand and impact expectations is through regular status and review.  Therefore, status reporting habits are an excellent way to improve the chances of success for your project.

    A Failure of Communicating Status

    I had an experience that has made me a firm believer in providing my clients with a weekly status.  In this case, the problem came from a sub that I trusted, and a customer that was happy and trusting.  I would periodically touch base on progress and tasks.  I left things to run on their own as did the client.

    We had some communication issues that led to my sub doing more testing and rework than the customer desired.  This confusion would have been a small problem if caught early, but instead, it went on for weeks.  Thus, by the time the client saw a large number of hours on small numbers of tasks, it looked like they were getting over-billed.  In a sense, they were.  Therefore, we ended up eating a bunch of billed hours and rolled the sub off of the client.

    A weekly status of hours and work would have brought this issue to a head earlier.  That early catch would have been easy to correct and saved headaches on both sides.  This situation could have ended worse, but part of the reason I did not over-communicate was due to the great relationship I had with the client.

    A Lesson Learned

    I learned from this bad experience that communicating status is an important detail to address.  I now send a status each week to every client large and small.  Most status reports are one project and one page.  However, sometimes I go to multiple projects per client and multiple pages.  I may also append some pages of notes or deliverable recap to make it easy to link tasks to outcomes.The status I send is not very complicated.  I list what was done, roughly how many hours were spent on the tasks, and then estimates of tasks and time for the week ahead.

    The status report takes less than fifteen minutes to put together each week.  However, I did spend close to an hour creating a template that is easy to fill out and still looks pretty good. Thus, the time I invested has more than paid for itself over the last few years.

    The status I send is not very complicated.  I list what was done, roughly how many hours were spent on the tasks, and then estimates of tasks and time for the week ahead.  This takes maybe fifteen minutes to put together each week.  However, I did spend close to an hour creating a template that is easy to fill out and still looks pretty good. Thus, the time I invested has more than paid for itself over the last few years.

    Keep It Simple

    The art of making a weekly status valuable is in its brevity.  Keep to simple line items and maybe even a summary at the top.  Consider that a client will only read the first part of the status.  Anything below the fold may be missed.  In particular, this scanning of status will occur as they receive one week after week.  Yes, it is a little bit of a CYA, but the real goal of this is to make sure you are on the same page as your clients about work to be done and priorities.

    A weekly status call would be a good way to keep it simple, but I recommend a written version as well.  The report provides something for future reference by your client.  However, it also provides you a great checklist to make sure your tasks completed each week match what you said you would do.  Communicating status seems like something everyone knows and values, but it is easy to get away from the process.  Beware if you do.  The lack of communication can cost contracts, clients, or even reputation.