How to design a testing framework
Hello, my name is Abigail Armijo, and people know me as Abi =). I learned programming when I was in high school, and I liked it a lot. I dedicate much time to continuing to learn programming.
I started as a developer and changed to QA a few years ago. I have worked on different projects. My primary experience is with .Net and Microsoft tools. I helped a lot of QA to design the automation of their current manual tests.
I like to share my knowledge. I wrote a GitBook in Spanish: how to develop APIs with .Net. I will share a series of articles about designing an automation testing framework.
In this first post, I will explain how I decided to design an automation framework.
The most important thing for me is to focus on the problem to solve and choose the best tools and language. I have used different frameworks or tools for different projects.
This is my list of how I decided to design the automation.
The current process: I like to see the current process and ask any doubt I have. For API testing, I will not suggest Cypress or Playwright, which includes API testing. I prefer the right tools to test, like Postman, SOAP UI, Karate Re,stSharp, or Rest Assured.
The budget: If the company has the budget to buy licenses. Otherwise, I choose free tools with a specific license, such as MIT or Creative Commons. For example, I can suggest paid options like Cypress Dashboard or Visual Studio License instead of Playwright and VS Code. Too I can suggest some free tools for 3 users, like QASE (a test management tool) or Postman.
The team: The team's knowledge (for example, .Net, Angular, React, JS, Python) and the ratio between developers and QA. If the team has QA and the app is written in Java or C#, I can suggest Playwright with Java or C#. Some companies have 1 QA for every 3 developers; others have 1 QA for 10. (From "Future of Quality Assurance" by Lambda Test). With 1 QA for 10 developers, having the time for automation tests is very difficult. Most of the time, developers help with automation. It's also easier when they are using their preferred language.
After checking the current process and team knowledge, my next steps are:
Create a POC with the most straightforward and/or typical test case. I also considered solving the most complex test case and thought about how to automate that test case.
Schedule a meeting with the team to install the software required and explain how to use it.
I decided on the required training and time, such as unit testing. I also considered concepts like the arrange-act-assert pattern, Page Object Model (POM), and Behavior Driven Development (BDD).
I schedule some workshops to explain the POC. I shared some external courses, too.
After the workshop, I added documentation with the main steps. I included diagrams and a step-by-step guide. A helpful diagram is the C4 model.
I am available for pair programming or to check any doubt for the first test cases.
I monitored the advance and made adjustments. After some time, most test cases included a lot of business logic, like testing SQL queries. I changed from Postman to RestSharp. And it is better to use RestSharp instead of my initial idea of some API + Integration Test with C#.
Change the tool when needed
I had to migrate some testing frameworks for different reasons:
Deprecated tools (Protractor). When I read about this in the angular roadmap, I evaluated the options:
Use stable tools. At that moment, Playwright was in preview. Beta or preview versions are not suitable for large migration projects.
The number of test cases: if it is over 2,000, I will choose a tool that can easily migrate without significant breaking changes.
The team's experience: Migrating from Java, C#, to a JS/TS will be more complicated.
To reduce the complexity of the test cases and code:
Suppose a web app is available in different languages; I use only one test for multiple languages instead of one for each country. I use JSON files with the languages, texts, and specific locators. With this, I reduce the time to change many pipelines and the code's complexity. And I don't need the if or switch statements.
To UI redesign: When the UI is changed from web forms of Java to Angular, React, or Vue.
I use the concept of components to reuse the current automated tests. I can create an interface with the standard functions for each component. I only need to change the component instead of rewriting all the steps.
I will share a sample of these examples in future posts. This is my initial framework with only one test case, a successful login in saucedemo.com.
https://github.com/apis3445/PlaywrightFramework
Subscribe if you want to follow my building in public testing framework with Playwright and TS.
Thank you for reading =)