Quality Assurance Planning – Part One (Unit Testing)

Unit testing should be done by the developer and include two tests. The first of these is to walk through each line of his code to insure it works correctly. This is a normal part of the development process, however the second test is not. During this test the developer should try to “break” their code through destructive testing by passing invalid parameters. Passing parameters that will not work, helps insure exceptions are handled and correct data types and field lengths are used. Passing a set of code to the development team that just barely works does not represent good habits. The attitude that, “I am not sure if it works, but they will catch it in QA,” is not acceptable.

For this second test, the quality assurance team should give the development team test cases that accompany the use cases they are developing. The test cases should include tab order, exception handling with exception message, alternate paths based on incorrect end user habits and path that introduces invalid data into the tested case. Giving the development team test cases insures consistency in the quality of the test and removes from the developer the burden of having to think of alternatives which may not be obvious to them. Without allowing the test case to become too involved, incorporate elements of a unit, integration, system and acceptance test into the cases. The white box approach during unit testing is the only one that makes sense.

Realizing the quality assurance manager normally has no authority over the development

Lunch Over the Abyss

Lunch over the abyss fosters strong relationships.

team the only way one may be assured these tests are run is through developing a strong relationship with the manager of the software team. There is a natural tension between the development and quality assurance teams. Since the QA manager has more to gain from this relationship than the development manager, the QA manager should foster this relationship. Maybe going to lunch on a regular basis will help. If targeted unit testing is applied, the amount of bugs will dramatically drop.

Click here for Part Two – Integration and System Testing


About Larry

Larry Lawhead is a passionate Agilest with a love for coaching, mentoring and organizational transformation. Huge fan of the Lean Enterprise, LeSS, Theory of Constraints, systems thinking and of course the Toyota Production System. Avid learner. Deeply influenced by the works of Jeff Sutherland, Eliyahu Goldratt, James Womack, Craig Larman, Faith Fuller, Marita Fridjhobn and countless others. He is likewise a member of the team that brings the Agile Open to the Southern California. Above all else, he loves coaching teams and individuals. He believes creating a safe and empowered place for individuals and self-organized teams to develop brilliant solutions, shared vision, demonstrate compassion and desire to continuously improve brings life’s greatest rewards. Watching clients unfold into a greater sense wholeness, purpose and direction is the miracle coaching enables. This satisfaction leads to continuous self-improvement, curiosity and personal growth that Larry passionately embraces.
This entry was posted in Quality & Value, Quality Assurance Planning and tagged , , , , , . Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.