While it’s probably not breaking news to anyone involved in software development, but ITG cannot stress enough how important software testing is as part of the SDLC.  In almost every situation, adding another viewpoint is often what it ultimately takes to point out what others might have previously overseen. Software development projects require strict specifications, complex logic flows and ever-changing formulas: testing these projects thoroughly and repeatedly is 100% necessary for the success of any project.

Testing is an inseparable element of software development, however it is important to differentiate between dynamic and static testing. Dynamic testing involves going through a previously developed function to look for logical flaws (executing the code). This usually happens closer to the end of the system development life cycle (SDLC), following actual development. In contrast, static testing is where code has not yet been exercised or where there simply is no code. This involves testing in all stages of the life cycle from the very beginning, well before actual development. Focus is on functionality meeting the business requirement, design or if any open questions remain regarding flow of the actual or related functionality. As this is part of all stages of the cycle, static testing can be also used in parallel with dynamic testing (ie, code reviews) so they are not mutually exclusive. However, dynamic testing only happens development. The focus of this post concerns software testing in the early stages of the SDLC.

The emphasis here is that testing should not start at the end of development. If testing techniques are implemented in all stages of development, there is a correspondingly higher chance to rule out possible logical fallacies or highlight misleading or missing piece(s) of information. The sooner this happens the better as any time wasted following the wrong flow burns development capacity in vain. Worst-case scenario is that completed developments need to be completely re-written after critical mistakes are discovered during dynamic testing or worse,  UAT (user acceptance testing).

Thus, static testing involves the actual testing of specifications, business requirements, design and user stories. This is commonly called review. The review is much more than proofreading a document, it is a detailed examination of data with the actual product in mind and with the aim of clearing up ambiguous issues and removing errors. This is actually the first step of testing where project specifications are examined. If anything comes up during review, the tester is a vital partner in client meetings to stress findings and concerns. Review session should be done with the final versions of the specification, the design and user stories. The main goal is to always avoid unnecessary development.

Spending time and effort on reviews comes with the following benefits:

• By removing ambiguity, requirements are more clear and development more efficient
• It reduces time spent on testing, as the amount of dynamic testing will be reduced (instead of multiple cycles of dynamic testing (until the requirement is finalised) there will be a few
• It reduces time spent on development as unnecessary refactors and development can be avoided.
• The testers are more deeply involved in projects from the beginning. This has an enormously positive effect on efficiency and productivity. The more clearly the team sees the big picture, the more efficient the delivery becomes.

To summarise, it is crucial to involve testing in all stages of the SDLC. At ITG, we strive to follow these techniques to provide the best possible product and a satisfied client (and satisfied end users) at the end of the project.