Summary
Coupled with your experience, we will provide a short summary of what you can do if you want to start a new project as a QA Automation. However, it is worth noting that this is only a guide, and should not to be taken as the only source of truth! Let’s review some steps you can take if you need to start a project from scratch:
First and foremost
The most important thing to do before implementing any technology is to understand the various journeys of the business workflow, request documentation from the team, and ask for the different repositories used for this purpose. You can do reverse engineering if you don’t have anything explaining how it works, although this last step is time-consuming and is not the best way to start a project, you probably don’t have another option in many cases.
What type of scenarios do we need to put the focus on?
What type of test do we need to automate? The list below must be the main focus because not all scenarios can be automated.
- Repetitive Process
- Regression testing: Over time, the regression suites will increment the size, and it is a fact that will take a little bit more time for each execution.
- Complex cases require a lot of time, for example, one scenario that requires many preconditions before testing something.
- Main functionalities could be an excellent approach to start the happy path to cover the quality in the significant functionalities and continue adding negative test cases.
Choosing the Technology
The technology used is determined by the type of project and the type of test that you need to conduct. This is determined by whether it is a front-end UI project, your access to microservices and the database, if it is a desktop application or mobile, and if you need to know if the application can resist a large quantity of requests at a specific moment.
Also, you must consider how you feel handling the different types of technology; what is more comfortable for you and your team.
In general, the technology used may be imposed by the client or chosen by the person who must start the project from scratch; as I mentioned before, depending on the type of the project and client, you may have a legacy automation project that you need to resurrect, you never know.
Below there is a list of technologies you can use for different purposes.
Front-end Automation
Here there are some recommended frameworks or libraries to use in this type of project and their benefits and drawbacks. I am not including the number of tools available on the market today because the list could be longer.
Cypress
Cypress is one of the most powerful and up-to-date frameworks for testing the frontend and backend, with all the power of Node JS in one place.
Pros
1 – All in one
It is likely that you do not need to include any third-party libraries to establish an automated test; simply downloading the Cypress dependencies gives you access to do assertions and run tests with the browser, perform API inspections, mock answers, and implement wait times.
2 – Good for beginners
If you are unfamiliar with programming, this framework is for you because it provides you with simple default libraries that will save you time.
3 – Documentation
Cypress has good documentation; 90% of problems can be solved by reading it.
4 – Fast test execution
Because it does not utilise external libraries to alter the web browser, the execution is quite fast. It also includes an automatic wait, which is very handy when searching for elements.
5 – Retry Capability
One of the most excellent aspects of this lovely framework is the option to retry the test while easily configuring the number of attempts.
6 – Cypress Dashboard
Optional feature to run the test cases, although paid, the optimisation offered is incredible overall to maximise the efficiency with parallelisation and automatic load balancing.
Cons
1 – Mobile test
Despite the numerous benefits, it is not recommended that you use Cypress for the time being for testing mobile apps in Android or iOS because it does not have support. You can change the viewport to see an approximation of reality, but this is not the same as testing on a mobile device, as there are errors that will only occur in real devices.
2 – Safari browser support
Nowadays, there is no existing support for the main browser of iOS. If you need to test this browser, you should find another alternative like Selenium.
Conclusion
Cypress is an excellent tool for automating test cases and is a perfect choice for web automation if you don’t have much experience working with automation frameworks. Even though it has some limitations and does not have as much market time as a Selenium library, Cypress will probably become a more powerful tool with time.
Selenium
Perhaps the favoured option for the majority of QA Automation Testers.
Pros
1 – Programming Language Support
One of the best features of Selenium is the ability to use it with languages like Python, Java, C#, Ruby, and even Javascript.
2 – Browser Support
Selenium supports a variety of browsers and operating systems, including Safari.
3 – Big Community of People
Because it has been on the market for a long time and many people use it, you will most likely find answers to many of your questions in forums and blogs, no matter how remote it appears.
4 – Selenium Grid
It is possible to execute test cases on numerous machines simultaneously, lowering execution time.
Cons
1 – Drivers
Depending on the browser, you must download the most recent version of the driver and continuously update the driver version with the browser version to avoid synchronisation issues.
2 – Retry Capability
It is possible to put into action, but it takes some work; other frameworks have a more advanced version of this capability that is easier to implement, although it depends on the selected programming language.
3 – Wait times
You need to configure the explicit and implicit wait difference with other frameworks that handle this feature more easily.
4 – Third-party dependencies
In contrast to other frameworks such as Cypress, you must install extra libraries to unlock its full capability. For example, if you require a runner in Java, you must include TestNG or Junit, to name a few libraries. If you need an execution report, you must consist of Allure or similar libraries.
Conclusion
Selenium was the first option for a long time. It has a lot of support and continues evolving; if true, it is not as user-friendly as Cypress but is an excellent tool that will let you do anything you can imagine with a little bit more effort. It can be considered a first option considering the team’s background regarding the technology stack they handle. Selenium has support for many programming languages.
Backend Automation
Cypress
As I mentioned, this multi-purpose framework can be used for back-end automation. Note that the advantages and disadvantages are the same as those described previously.
Jest and Supertest
Both libraries with the hand of Node JS, if Javascript is your preference without a doubt, this could be a good choice. Jest is used to do assertions, and Supertest is used to generate a request in the APIs.
Pros
1 – Installation
You do not need to be an expert or find workarounds to install Jest and Supertest; they are simple.
2 – Speed
These libraries are relatively fast in executing the test.
Cons
1 – Structure of the project
Suppose you are a beginner, or you are just starting in the automation of test cases. In that case, you shall need the imagination to structure a project because Supertest and Jest are libraries that, in combination, work as the framework. Still, if you don’t have an established structure to start, you have to use ideas.
Rest Assured
If you are familiar with the Java programming language, Rest Assured is a popular and efficient library.
Pros
1 – Useful
The syntax is easy to understand and use and supports the Gherkin keywords like Given, When and Then. Creating a large quantity of code to send an HTTP request and validate the result is unnecessary.
2 – Integration
Easy to integrate with JUnit or TestNG.
Cons
Knowledge of Java Programming Language, this language is not the most friendly to learn.
Postman and Newman
I leave this tool here because it is another option you can take into account, but I recommend it in the last case. With Postman, you can create the collections to validate the different endpoints and use Newman to run the list.
Pros
Postman is easy to use initially and can get you out of trouble.
Cons
Hard to maintain, and has limitations that other frameworks can provide.
Mobile
Appium
By excellence, the primary tool to automate mobile test scenarios.
Pros
1 – Community
Appium has an extensive community and documentation that can be very helpful at times to fix some issues or implement new test cases.
2 – Support for iOS and Android
One of the best features of this tool is the support for the different operative systems.
3 – Support for many programming languages
There is a massive list of supported programming languages to be used with Appium, which makes it a handy and powerful tool for mobile testing. (see below)
Python, Javascript, Java, Ruby, Objective-C, PHP, .Net Family, Perl.
Cons
1 – Differences between iOS and Android
Android executes faster than iOS.
2 – Configuration Troubles
Sometimes it’s hard to properly configure test cases to run on tools that provide real devices like Saucelabs. A lousy configuration can have slow test execution as a consequence.
Now what?
Once our repository is ready, we need to configure it to run automatically once the developers include new changes in the testing focus product. How we can automate this process to succeed will depend on the product type and the chosen environment. If you decide to use Cypress and run it in the background during continuous integration, or if you determined Jest and Supertest as separate projects and only needed to run when the developers were deploying in the staging environment but not in development, all of these actions will be determined by the type of project you are working on. You will have to investigate and get support from the DevOps team or read a lot of documentation to make the most appropriate and beneficial decision. Unfortunately, there is no recipe to do that, and the unique formula is experience.
Conclusion
There is no recipe for creating a framework from scratch, and having success will depend on our experience and the types of projects we encounter. The most relevant thing could be to know business workflows before making decisions.
Use your ability and creativity to implement the most appropriate tool that makes you feel comfortable. Still, if we do not have an election of the technology, establish excellent communication with the team and find constant support, read documentation. If possible, first the official documentation and then use forums, blogs, or anything else that can help you achieve what you yearn for.
