Static and dynamic testing

Recently on my last appearance on SPaMCAST, we talked about static and dynamic testing. As always, it was a great conversation with Tom on the matter.

Let’s review the definitions.

Static testing – reviews, looking over, visual inspection. Basically, anything where what is being tested is not “exercised.” No buttons pushed, not run-through of the code, no actual value used to get an output. In some instances, human eyes and software tools help determine the logic and contents are of high quality.

Dynamic testing – Using actual variables to run through or “exercise” the product or walk through a service.

What get’s lost is that the level of detail needed for dynamic testing is sometimes not done during status testing. Reviews are sometimes seen as a rubber stamp activity to check off a process in the SDLC. The implicit thinking is that the actual testers will find anything wrong if there is anything wrong.

In previous conversations and blog posts, it has been said that “quality is everyone’s responsibility” when everyone is accountable to quality. Finding things earlier saves frustrations down the road. Ensuring everyone is doing the best they can and provide the best quality with what they provide is the biggest value.

One of the issues that cause static testing to be rubber-stamped is the perception that it is cheaper to fix them if you find issues sooner. Over the years are articles out there that debunk that thought and that it is a false concept. Simply put, the change costs will always be there as their people, already stakeholders on a project, are working on it. Now there could be some extra costs with overtime or delays. Could it be as exponentially as what most believe? Unfortunately no. So when the process is done, and something is found late without those large increases, the process is legitimized, and the focus is on dynamic.

With that focus on the dynamic, all the work done to that point will increase frustrations and finger-pointing.

Suppose we look at it through an agile lens technically, the entire team all the way through the flow of inputs to outputs. Unfortunately, similar issues occur and sometimes come at the cost of quality, as the lack of discipline shows.

Dynamic testing is everywhere. It just falls under different names. Keeping the same discipline that goes into dynamic testing won’t reduce costs; as stated, they are already there; what it will reduce is aggravation, frustration and obstruction of flow while increasing productivity and quality.