The main objective in 2021 for our QA Team was to include more automation into our QA process. The need for automation became more obvious during QA team weekly meetings, where all the members shared their opinion regarding their struggles. Most of the team members were burned out because of the regression testing routine. Therefore, It was decided to primarily focus on automating regression, by considering the cases that are repeated more frequently in the project. In addition, after automating primary regression test cases, it is planned to automated API requests where it is needed.
There are several tools that are being used for automation. One of them is Selenium, where the tests are written in Python language, the environments for writing the code are VS Code and PyCharm, and the API tests are planned to be automated with the “request” python package. The tests will be written with OOP methodology, so the script could be reused/inherited later if needed by both QA engineers and developers. In addition, for less complicated projects, where just the front end needs to be tested, Cypress is used for automation. It operates directly with the browser without any extensions. Moreover, Cypress captures snapshots at the time during the test execution, so the issue could be found momentarily.
Below there is a description of the test cases and methods that were written already for one of our internal projects. At the beginning of all the current written test cases, modules are called Webdriver, Select, Time, and other types of explicit waits in order to have a smooth interaction with the browser. For now, only Chrome browser is used for tests, however, other browsers could be added easily as well.
The 1st test case that was written is admin authentication to the QA environment. The user will be automatically logged in and land on the main dashboard (the xpath is used in order to locate the elements).
The 2nd test case will go through all tabs from the navigation bar, back, and forward to make sure that all main pages are operable (the ID is used to locate the elements).
The 3rd test case will login, logout, and login back again admin user to make sure that multiple authentications could be performed.
The 4th test case will authenticate the admin user and create another new user with a unique username that will be stored in the database.
The 5th test case will authenticate the admin user and create another new client that will be stored in the database (the process is similar, so no code is shown).
All the scripts are stored in the Bitbucket that corresponds to the project.
These are the tools and approaches as of today, however, it all could be subject to improvement. Stay tuned for the next updates!