Functional and Code Perspective: What Does It Mean?
The concept of the functional and code perspective in software testing encompasses various approaches and techniques that can be applied depending on what you include or exclude. There are approximately 10 to 14 commonly used testing techniques, including:
Common Testing Techniques
| Testing Technique | Description |
|---|---|
| Equivalence Partitioning | Dividing input data into partitions of equivalent data. |
| Boundary Value Analysis | Testing the boundaries between partitions. |
| Decision Table Testing | Using a table to represent input conditions and actions. |
| State Transition Testing | Testing transitions between different states of the software. |
| Pairwise Testing | Testing all possible pairs of input parameters. |
| Cause-Effect Graphing | Using graphical representation to find cause-effect relationships. |
| Error Guessing | Using experience to guess likely errors in the software. |
| Exploratory Testing | Simultaneous learning, test design, and execution. |
| Use Case Testing | Testing based on user scenarios or use cases. |
| Ad-hoc Testing | Informal and unstructured testing approach. |
Code Perspective ᒡ◯ᵔ◯ᒢ
Let’s say you write a piece of code, a specific function. You can use one of the techniques for exampleDecision Table Testing to verify whether all possible cases have been covered within that code.
However, this does not mean that by merely checking the code, you have also covered all the business logic that exists in the front-end. You see?
For example: The program code ensuring that every possible value for a specific input field triggers the correct actions does not automatically validate the flow of various mortgage versions or the business logic governing different insurance aspects.
Functional Perspective ᒡ◯ᵔ◯ᒢ
So testing techniques can be applied to the code perspective, but they can also be applied to the user interface perspective. This ensures that both the underlying code and the business logic visible to the user are thoroughly validated.
Adapting Testing to Changes
Now, let’s consider a more complex scenario. Suppose you make a change in the code—for example, increasing the possible values for an input field from three to four. This means that:
- The testing technique you previously used (Decision Table Testing) must now be adapted to account for four possibilities instead of three.
- The front-end business logic must also be revalidated using the testing technique you previously applied, for example, State Transition Testing.
Here is where things truly become complex. You understand that making changes to the user interface might require retesting to ensure everything still functions as expected.
- You may also recognize the need to test the code changes. Both aspects—UI and code—must be tested.
- However, who’s to say that the testing techniques you applied previously will still be applicable after the (code) changes? It’s entirely possible that you’ll need different techniques this time.
- In fact, the latest (code) changes might even render certain test techniques ineffective, requiring you to rely instead on the empirical knowledge and experience you’ve built up through years of software testing.
- Not only that! You might even need one technique after the other!! (mixed with your tacit knowledge and or software testing subject-matter knowledge and expierence)
Conclusion
By addressing both the functional and code perspectives in software testing, you ensure a more comprehensive validation process that considers all aspects of the application, from underlying code to user-facing functionality.
