‘Let’s build a framework’, this is perhaps one of the most common phrases that I hear yet fail to understand why when we do not understand ‘what the problem is’. Being integral to Quality Assurance, I find it highly confusing to see software engineers jumping to ‘building frameworks’ with the latest tools and ideas but are yet to spend a moment trying to understand why they need one. In this post I will try to elaborate why the importance of ‘understanding the need to build a framework’ outweighs actually building a framework.
Step One – Do not build a Framework
Building a framework is actually very exciting. Constructing a framework means that one must explore tools for a host of purposes. For instance, build tool, development tool, testing frameworks, other libraries for logging, monitoring, CI etc. All of this needs to be thought of and implemented. This gives any ‘framework builder’ the freedom and capacity to show off their skills and showcase their methods.
However, building a framework by looking into tools, deciding on the best approach, it may all be a complete misuse of time as the tool may actually not solve any problems. In fact, your framework may instead become a nightmare to manage and maintain. Why would building a tool with the latest proven technologies become a problem?
It potentially may become a problem because the latest tools on the market may not solve your problems. Before building a framework, it is much more important to understand what the problem is.
Build a Solution by Understanding your Problem
The very first thing one must do before building a framework is to understand that your problem is. How do you understand what your problems are? Ask questions. Ask your Product Owner, your Developers, your QA’s, your Analysts etc. Questions such as:
- What is the scope of the application?
- Who will use the framework?
- What does the application do?
- Is the application customer facing? Is it an API?
- What is the expected load of the application?
Let’s go through some of the questions above.
Answers Drive Solution
After asking the first question, you get the answer that ‘we do not care about any other application, only ours’. This means that we may not need to write any integration tests and only need unit tests. How does this influence your decision on tools. Well, you may not need tools that help with Integration tests. As there is only one type of test you will not need to overthink your test configuration plans.
The answer to your second question comes back ‘the team’. If this is the case, is there any value in using tools the the team may not benefit from? What if the answer is ‘a list of external teams’. Have you consulted the other teams?
Assume the answer to the forth question is ‘the application is an API and not client facing’. This would potentially aid in helping you pick the right tool. For instance, there would be no need to use a browser testing Framework such as Selenium. You may also decide to use a tool such as REST to make http calls.
If there is some non-functional requirements for the tool, have you considered any performance testing as part of your framework?
Now let’s assume you asked these questions after you had built a framework, imagine the nightmare of having to maintain it over time. You may not want to lose what you have done. Therefore you start to mutate your framework to become something more closely related to what is needed. In the end, the framework may need to be thrown away. This is why understanding the problem on paper is much more important than writing a single line of code.
How Do You Measure Success
Perhaps the most difficult aspect of any framework, is it delivering value?
It is actually very easy to measure the success of a framework. You can measure it easily be answering the questions below:
- Is your framework picking up on issues before any code goes to production?
- Are you able to release easily and quickly?
- When an issue occurs, is it easy to identify?
I have tried to tell you why it is important to understand your problem before writing any code. Do you agree, do you feel that I might have missed something? Let em know in the comments below.
