Static, as in Stationary or Stagnant. What do you think is stationary in software terms? Yeah! The code. Either it can be stationary – or running, i.e. when you run the code. As the name suggests Static Code Testing is one of the software testing technique where the code is stationary, i.e. NOT running. How? Simple, you don’t execute any functionality (or code). Then how does it ‘test’ the system, you may ask 🙂 In Static Code Testing we don’t execute the code, instead it is checked manually or via tools for any design defects. As you might have guessed – Static Testing is not just limited to the code, we can even analyse the associated documentation like requirement & design documents to identify any potential errors or standard violations. Static testing is also known as Dry run testing.
Requirements analysis is an important aspect of software testing. On many traditional projects, this was devoted solely to Business Analysts, who worked closely with their clients to build out a framework onto which development could be executed. With an effective agile project, Quality Assurance engineers should also be part of this phase who can provide significant value. The software code, doesn’t matter how well it’s written, can’t do anything if there are ambiguities in requirements. It’s better to catch the requirement ambiguities and fix them in early development life cycle. It’s a fairly well established theory that the later in the software development life-cycle an issue is discovered, the more expensive it is to fix, and that most often, this cost growth curve is exponential rather than linear. So it’s important to have requirement analysis and catch these incorrect requirements before design specifications.
Continuing on our tryst with Bollywood’s Karan-Arjun, let’s read about some more important duos in the field of Software Testing!
Will you start testing in parallel with development or only after the development is completed? What about testing at the code-level? i.e. code reviews to ensure best practices are followed. Will it only be reviews or will you actually run the application to identify defects? How about utilizing some automation tool to ease the process? Or will it be hybrid?