Onboarding Guide for New QA Recruits in Trendyol Android Team
“One procedure wipes out a thousand uncertainties.”
In this article, I will explain the structure and functioning of our Android Test Process.
The procedures we have prepared allow our new team members to quickly adapt to our team, as well as filling our lack of documentation, which is one of the biggest shortcomings of the companies.
DOMAIN STRUCTURE
As a mobile team, we develop our business in 8 different domains.
Discovery: The team responsible for the actions taken by the user before adding items to their basket. Homepage, Boutique Detail, Product Detail, Favorites, Collections, and all of the functions under these pages.
PDP: The PDP team is responsible for the actions on the product detail page.
International: The team responsible for the actions taken before and after the user has added items to their basket. Homepage, Boutique Detail, Product Detail, Favorites, Collections, Login / Register, Basket, My Account page and all the other pages under these channel.
Platform: The team responsible for all kinds of actions that will facilitate the work of the developer, test and product teams.
Checkout: The team responsible for the actions taken after the user has added items to their basket. Login / Register, Basket, Checkout, Pudo, Checkout Success, Trendyol Wallet, My Account page and all the pages under these pages, and all of the functions under these pages.
DolapLite: The lite version of the Dolap app is included in our application as a channel. We can be redirected from within the application as well as by deep link.
Market: Market channel. All pages of the market. We can navigate with a banner on the homepage within the application or with a deep link.
Meal: Meal channel. All pages about the meal pages. As in the meal, we can redirect with a banner on the homepage within the application or in the same way with a deep link.
Or, we can direct by clicking on DolapLite / Market / Meal on the quick action screen that opens by holding down the app on the phone.
Working in different domains gives a different perspective. It allows us to think in a versatile way. We need to calculate whether each of our task affects different domains.
SCRUM BOARDS
We have 8 separate scrum boards. Each team develops the work on its own board. Each team has its own planning, grooming, review, retrospective meeting. We run a weekly sprint.
PR PROCESS
Each team opens their PR’s with the numbers of the jobs on their board. EXAMPLE: MLBS-1223 / cartModularization.
If the scope of a job is too wide, development is being made on the DEV_PROCESS branch.
EXAMPLE: CHECKOUT-455 / BASKET-DEV-PROCESS
The work being developed (if dev_process) is developed by targeting small PR’s to dev_process. These little PR’s from the review are being merged into the Dev_Process branch. After the Dev_Process development is completed, we start the testing step.
For other PR’s, we can directly test the task coming to the Ready For QA area in the Jira board.
The prerequisite for this is to get 4 approves and pass Unit Tests successfully.
For more information about Code Review Process, you can refer link below.
HOW WE USE JIRA
On Jira, we have Blocked, Ready For Dev, In Dev, Code Review, Ready For QA, In QA, Ready For UAT, and DONE columns. In cases where we have a bottleneck related to a job, we move the job to the Blocked column and inform the product owner. We try to take relevant actions in sprint or retrospective meetings.
When the development of a business is completed, it is moved to the Code Review column. We expect it to get 4 approves here and we expect the Unit Tests to be successful. The PR that meets these conditions is automatically moved to the Ready For QA column. Later, the tester moves the work to the IN QA column and begins testing.
We try to open the bugs we find to a standard so that the developer can understand the bug more easily and the integrity is not broken.
When the bugs are fixed, we check it again and move it to the Ready For UAT column when the development test is over. Here, development is completed with feedback from the product and design team. Finally, the job is moved to the DONE column and the MERGE process is performed by the tester.
REGRESSION PROCESS
We run the works developed in 8 different domains and our regression over a single RC package. EX: 5.8.1-RC. The bugs found are opened to the relevant boards. Regression tests continue until the bugs are fixed. We keep our regression suites for all domains in separate documents.
For more information about Regression Testing, you can refer to my previous article below.
RELEASE PROCESS
After our Regression Tests are completed, our release process begins. We are sending our RC package, whose tests have been completed, to the store gradually.
We are moving forward by increasing our package by 1–13–26–43–67–81–100%. After 1 week or 10 days, our package is 100%.
For more information about Release Process, you can refer to my previous article below.
HOTFIX PROCESS
After the Regression Tests are over, our release process begins and we increase gradually. After our release period is over, after our package is 100%, if there are problems in our application, our Hot-fix Process starts this time.
We also keep the heading when / should we exit our hotfix package in a separate document. We come out with the hotfix package in the following cases;
FIREBASE TRACKING
We follow our app in the store with the Firebase Crashlytics tool.
We open the issues with high crashes to the relevant boards. For the fixed bugs, we patch the package in the store and send the fixed bugs back to the store by increasing the package. The crash tracking continues all the time. Even if there is no crash, we continue the rollout process by increasing the day-based percentage. We carry out these operations thanks to our CI / CD tool, which we call leylek.
Related leylek commands we use during the regression, release, and hotfix process;
UI TESTING
Each team writes the UI Tests of its own pages. We follow our UI tests on excel. UI Test jobs are opened as separate jobs on each board. We also hold UI Test meetings on Mondays every week. We use;
- IDE: Android Studio
- Language: Kotlin
- Framework: Kaspresso
- Library: Kakao (Simpler syntax)
For more information about UI Testing, you can refer to my previous article below.
BUSINESS FLOW
There are documents that we keep our business flow in each domain. In this way, know-how is increasing and we do not forget which features are available on which page, the whole team is easily accessible.
We keep these pages constantly updated.
New team members will be able to quickly adapt to our teams with the information above.
Preparing an Onboarding Guide is very useful both for our newly joined teammates and when retrospective is needed. I highly recommend preparing Test Procedures for every tester to able to catch all uncertainty.
