Hello! My name is Rona and I am a QA engineer at freee Digitalization Service. It's the 19th day of the freee QA Advent Calendar 2023.
I am grateful for the opportunity to write an article for this event, and this time I would like to share about creating and running automated end-to-end [E2E] test scripts.
Self Introduction
I started working with Likha and the Global team in September 2022. I became part of the sisig team and mostly tested on the freee Digitalization service. I can say that I had a wonderful and amazing experience witnessing the service from the time it was in development until its first release on December 15, 2022.
Until now, the service has been constantly improved, and I'm pleased that my understanding of it has grown along with the new incoming updates.
About Sutekaku
“SUTEKAKU” is “Staging Kakunin” in Japanese. This word means “Verify on staging environment”.
As QA Engineers in the sisig team, we regularly add test cases to Digitalization Sutekaku with each new feature that is launched for the product. This way, we can make sure that the overall functionalities continue to behave as intended even with the additional pull requests (PRs) that are pushed in staging.
Having said that, our manual Sutekaku test cases became 61 in Digitalization, and that number increased to 82 when we included the Invoice Support functionality. With the new features added and will be released for the service, it may have increased up to this point.
Therefore, I realized, along with every other QA member of the Global team, that it is optimal to begin acquiring and incorporating automated end-to-end test scripts into our ongoing projects. By doing so, we can minimize the amount of time we spend on manual testing, enhance productivity, and deploy capabilities more quickly and efficiently.
Learning Automated E2E tests
Naturally, we had to learn how to perform automated testing before we could begin. To achieve that, we held several workshops in addition to regular meetings.
- Firstly, we set up our local environment using onboarding documents about E2E.
- Following that, we held an E2E workshop in Japan. SEQ team talked about coding based on Selenium, and we learned a lot about creating E2E test scripts from the session.
E2E Workshop by SEQ team - A few months later, the Lapu-Lapu team traveled to the Philippines on a business trip. Then, we conducted the Advanced E2E workshop once more. We learned how to merge our E2E test scripts from Shiho-san, QA Engineer in freee.
How to merge E2E test scripts by Shiho-san - We then began trying to write our own E2E test scripts for our projects and started a bi-weekly meeting named 'Technical Session - E2E.'
- Additionally, we created the #global-qa-e2e Slack channel, where we post our PRs for review and ask questions if we run into any problems.
#global-qa-e2e Slack channel 
My first time submitting a pull request for review!
Helpful Commands when Creating Automated E2E Test Scripts
Once you have set up your local environment for writing a test script, the following frequently used commands are ones I have learned, and that, in my experience, will make writing scripts easier and more comfortable.
For creating a new branch:
- git checkout -b (branch name)
For switching from a new branch to another:
- git checkout (branch name that you will switch into)
For deleting a branch:
- git branch -D (branch name to be deleted)
For renaming a branch:
- git branch -m (old name) (new name)
To check if you have to correct some format of your code for Rubocop’s purpose, run these commands successively.
- bundle exec overcommit --install
- bundle exec overcommit --sign
- bundle exec overcommit --sign pre-commit
- bundle exec rubocop --except Layout/EndOfLine (This command can show you how many formatting errors you have and where they are in your files.)
For automatically correcting the errors shown by the previous command
- Install GitLens - Git supercharged in VS Code
GitLens - Git supercharged in VS Code - bundle exec rubocop -A (path of the file you want to automatically correct)
For saving the changes you have for a local branch before you switch to another branch, run these commands successively.
- git add .
- git stash save “(stash name)”
For applying your saved code in a stash to another branch:
- git stash list
- git stash pop stash@{number of your saved stash in the list}
- Example: git stash pop stash@{2}
Helpful Commands when Running Automated E2E Test Scripts
Some useful commands I discovered for executing E2E test scripts are listed below.
For running ALL the tests in your project in your local environment, use an asterisk (*) instead of the spec file name:
- bundle exec rspec spec/digitalization/*_spec.rb
- There are instances when we must verify that the modifications we make to a given file do not have a negative impact on other files. This command will execute everything in your project to confirm that everything is still operational and stable.
If you run into an error, adding this line of code to your changes may help you figure out what's causing it.
- binding.pry
- You may put this anywhere in your code that you want the test to end when you run it locally.
Conclusion
Perhaps there are still more useful commands that I am unable to share with you, but for the time being, I believe that these are the most important and common ones that we can use to conveniently build and execute automated test scripts.
As of this writing, we have reduced a favorable proportion/percentage of Digitalization sutekaku manual test cases. Hopefully, we can all continue to enhance the quality of our projects and reduce even more in the future.
For tomorrow, the article 「QAとしてチームとのコミュニケーションで心がけていること」 written by toyopi, QA engineer of freee会計の口座連携システム will be published.
Let’s keep good quality~
