Dynamic testing is the process of giving an input, receiving an output, and comparing the outcome to the expected behavior while dealing with the real system—not a model or artifact that represents the system. It involves actively using the system with the goal of identifying mistakes.
We shall discover via this process that the following two widespread testing myths are untrue:
- Testing is an activity that comes at the end
- It is performed only by testers and the rest of them have nothing to do
Let us start with a quick reference to the v-model:
- On the left-hand side of the V-model, we have activities that are not performed by the QA team.
- On the right-hand side, we have some of them that are taken care of by the Dev team, some by the testers, and some by users.
Let’s start with – Requirements Gathering. The Business Analyst and other high-level management performs it. The output document for this phase is the Business requirement document, BRD.
The next stage is System Design. System design is a phase where the business requirements are translated into the Functional requirements, in the FRD (Functional Requirements Document).
The Dev team, the primary player in this process, will go over the BRD document line by line, page by page, and step by step while the translation is taking place. The BRD document is read sequentially, despite the main objective being to consume the business requirements for translation purposes.
As an illustration, let’s say that this is the BRD for a financial website that prioritizes security. The BRD contains a section that discusses the password guidelines for different users that register for accounts on the online banking website. A user is not permitted to use the same password for more than one account.
This is not doable. Because a site can merely suggest how the user should set login credentials, but there is no way this restriction can be imposed. The software cannot accomplish this requirement; it is not feasible.
Let us now consider the following points based on this example:
- How is it decided that this requirement is not viable to test because it cannot be built? Do we go the bank’s website, set up the login credentials, and then discover that it isn’t feasible? No, we are merely relying on our analysis of the BRD and, of course, a little common sense.
- Are we testing this requirement? Sure, but purely based on the theoretical, conceptual sense, not on the actual AUT (Application under Test).
- What is the physical form of this test? A simple reading or a formal review of the BRD, or an even more formal feasibility analysis of the business requirements.
Coming back to our misconceptions:
- Who is performing this review of the BRD? – Mostly the dev team and other technical teams that create the product. These are not testers.
- Is this review going on at the end of the product creation? No, in the earliest stage of project development. So, it’s more than just the ending.
Static Testing Techniques:
To summarize, static testing is the verification part of software testing that follows the following methods:
- Document reviews
- Walkthroughs
- Inspection
- Feasibility analysis or any other form of analysis to determine if the software is what it should be or not
- Code review
To quote the CSTE CBOK, “Verification answers the question, “Did we build the right system?” while validations address, “Did we build the system right?”
The following are all the static testing activities that happen on the left-hand side of the V-model.
| SDLC stage | Output | Verifies | Actors |
|---|---|---|---|
| Business requirement gathering | BRD (Business Requirement document) | Scope document (if any) | |
| System requirement design | FRD(Functional requirement document) | Reviews/verifies the BRD | Dev, Technical teams |
| Technical requirements design | TDD (Technical Design Document) | Reviews/verifies the FRD | Dev, Technical teams |
| Design (code) | Code | Reviews/verifies the TDD. Code review by the dev team for completeness, format etc. | Dev, Technical teams |
Note that you can extrapolate this information for projects following any development methodologies, as the steps will be more or less similar.
On the right-hand side of the V-model is validation.
Dynamic Testing Techniques:
- Unit Testing
- Integration Testing
- System Testing
The purpose of the unit, integration, system, and UAT phases is to write tests that will be run on the AUT at different periods of its development. The tests are all tests, regardless of the type of criteria they are intended to validate.
Therefore, validation refers to any type of testing in which an AUT must be used and its output is needed to ascertain whether the test was successful or not.
Would it be OK to assume that there is absolutely no verification on the right-hand side (RHS) of the V-model? “No” is the response.
The team examines every test developed at every point on the RHS multiple times during the test creation/finalization phase times. Read about the detailed process of the test documentation review here..
On the RHS:
- The developers reviewed tests and code in the Unit/Integration testing stages.
- System Tests undergo a peer review during their documentation and upon completion undergo a review by the dev team and business analyst.
- UAT tests undergo a review by the QA team and the users before the UAT begins.
Static Testing Vs Dynamic Testing
Let us now understand the differences between these two important testing techniques.
| Static Testing | Dynamic Testing |
|---|---|
| Also known as Verification testing. | Also known as validation testing. |
| Does not require execution of the source code. | Requires execution of the source code. |
| Static testing is all about prevention of the defects | Dynamic testing is all about detecting the defects |
| It involves the documents, checklists, and a process to be followed | It involves the source code and the test cases for execution |
| No code compilation needed | Code should be compiled and in executable situation. |
| Cost of fixing the defects found is less | Cost of fixing the defects found is more |
| Done in early stages of the development life cycle | Done in later stages of the development life cycle. |
| Requires lots of meetings | Requires fewer meetings |
| This testing is done before code deployment | This testing is done after code deployment |
| Performs a dry run on the code as part of the static analysis of the code. | Code is fully analyzed for different paths by executing it. |
| Static testing covers the structural and statement coverage testing. | Dynamic testing covers the executable file of the code. |
| It includes the following items for testing: | It includes the following items for testing: |
| ? Requirement document | ? Unit tests |
| ? Design documents | ? Integration tests |
| ? Program specifications | ? System tests |
| ? GUI wireframes | ? Security tests |
| ? Performance tests | |
| ? User acceptance tests | |
| It consists of reviews, walkthrough, inspection and static analysis of code. | It consists of functional testing, non-functional testing and data/control flow analysis. |
| Some of the tools used for Static testing are: * Soot * Eclipse * Checkstyle * Clang * Sonarqube * Source meter | Some of the tools used for dynamic testing are: * ValGrind * Procmon * DroidBox * Diakon * BoundsChecker |
Conclusion
In conclusion, static testing is an important testing technique that takes the form of Business requirement review, Functional requirement review, design reviews, code walkthroughs, and test documentation review. It is a continuous activity and not done just by testers.
Validation, the dynamic testing part, is more hands-on and happens on the product itself and not on an artifact or a representation of the product. The dynamic testing methods are characterized by a much more formal process of test case/condition identification, coverage considerations, execution, and defect reporting.
YOU MAY BE INTERESTED IN
The Art of Software Testing: Beyond the Basics
Automation testing course in Pune
Automation testing in selenium
Mastering Software Testing: A Comprehensive Syllabus
Frequently Asked Questions
What is the main difference between static and dynamic testing?
Static testing involves reviewing and analyzing the software code without executing it, while dynamic testing involves executing the code to identify defects. This fundamental difference affects the approach and tools used for each type of testing. Static testing is often used for code reviews and inspections, whereas dynamic testing is used for actual testing and validation.
Why is static testing important in the software development process?
Static testing is essential because it helps identify defects and issues early in the development cycle, reducing the overall cost and time required to fix them. It also improves the quality of the code by detecting syntax errors, type mismatches, and other potential problems. By catching these issues early, developers can avoid downstream problems and ensure a more stable and reliable product.
Can dynamic testing be performed manually or is it always automated?
Dynamic testing can be performed both manually and automatically, depending on the specific requirements and goals of the testing process. Manual testing involves human testers interacting with the software to identify defects, while automated testing uses specialized tools and scripts to execute test cases and report results. Both approaches have their advantages and disadvantages, and the choice between them depends on the complexity, scope, and budget of the project.
How does static testing contribute to the overall quality of the software?
Static testing contributes significantly to the overall quality of the software by ensuring that the code is correct, consistent, and adheres to established standards and best practices. By detecting and fixing defects early, static testing helps prevent bugs and errors that could lead to crashes, security vulnerabilities, or other issues. This, in turn, improves the reliability, maintainability, and performance of the software, making it more suitable for release and deployment.
What are some common tools used for static and dynamic testing?
Common tools used for static testing include code analyzers, linters, and review tools, such as SonarQube, Checkstyle, and CodeCoverage. For dynamic testing, popular tools include test automation frameworks like Selenium, Appium, and JUnit, as well as load testing and performance testing tools like Apache JMeter and Gatling. The choice of tool depends on the specific needs and requirements of the project, as well as the programming languages and technologies used.
