Real-World Implementation:
Automating the Sofol Mobile App

What is SOFOL?

“Sofol” is a proprietary mobile application of iFarmer that enables our field agents and partner retailers to serve our farmers. Farmers can get registered, complete their e-KYC and receive necessary updates through “Sofol” which is operated by our field agents and partner retailers. “Sofol” also enables us to capture farmer and farm information for better monitoring, customized services and building farmer profiles along with their transaction history.

To demonstrate Maestro's power, I implemented a complete end-to-end automation for the Sofol mobile app covering: Market Facilitator (MF) Login → Add Farmer → Submit Loan → Add Project → Follow-ups 1 & 2 → Payment Collection.

How the Automation Flow Works

The master orchestration file coordinates five independent flows, each handling a specific responsibility. When the test starts, it launches the app, executes the Market Facilitator login with credentials passed as environment variables, then seamlessly chains through the farmer addition, loan submission, project creation, and finally post-disbursement monitoring.

Step 1: Market Facilitator Authentication

The login flow accepts phone number and PIN as parameters, allowing the same test to run with different user credentials. The flow waits intelligently for the login button to appear, avoiding hardcoded delays.

Step 2: Add New Farmer with Unique Data

Instead of using static test data, the automation generates a unique phone number (starting with 019 + 8 random digits), a unique National ID, and random farmer names for each test run. This ensures that every execution creates genuinely new test data, catching bugs that only surface with varied inputs. The flow also demonstrates intelligent field population—copying the farmer's name from one field and pasting it into the English name field, mimicking real user behavior.

Step 3: Loan Submission (The Complex Multi-Form Journey)

This is where the workflow becomes sophisticated. The loan submission spans 20+ screens with multiple form sections:

• Personal Information: Capturing marital status, name, NID, and date of birth using drop down selections and date pickers

• Document Verification: Capturing both front and back of the National ID using the device camera, with automatic handling of different camera interfaces across Android devices

• Banking Details: Selecting the bank, entering a random account number, and choosing account type from drop downs

• Loan Scheme Selection: Automatically defaulting to poultry as the farming type, then selecting the specific scheme and loan duration

• Socioeconomic Data: Filling in housing type, appliances, and land area information through drop downs and text inputs

• Income Sources: Entering 7 different income sources (farming, business, service, transportation, etc.) using index-based field selection—allowing the same automation logic to fill multiple similar fields without hard coding each selector

• Field Mapping: Using coordinate-based taps to define the farmer's actual field location on a map by drawing a polygon

• Crop Information: Selecting crop types and cultivation dates

• Final Verification: Entering OTP (One-Time Password) digit by digit for loan approval

All of this is handled without brittle waits or exception handling—Maestro's intelligent waiting ensures elements are ready before interaction.

Step 4: Add Project to Approved Loan

The automation navigates to the projects section, filters to show only disbursed loans (validating business logic), and adds a project to the first eligible loan. It fills in:

• Project financing type

• Total poultry purchase cost (৳10,000)

• Individual poultry cost (৳20)

• Purchase date

• Farmer's contribution amount (৳20,000)

• Project photographs

This demonstrates state-based testing—verifying that only approved and disbursed loans can have projects added.

Step 5: Follow-up 1 - Health & Feed Monitoring

The automation enters Follow-up 1 data, simulating field officer monitoring:

• Daily feed quantity (2 kg)

• Disease prevention measures taken (Yes/No selection)

• Vaccination status (Yes/No selection)

• Cleanliness level assessment (Good/Fair/Poor)

• After submission, the test asserts success, verifying that the data was recorded correctly.

Step 6: Follow-up 2 - Market Preparation

The flow enters Follow-up 2, capturing:

• Expected market price (৳25,000)

• Expected sale date

• Support needed for selling (free text entry)

• Optional project photograph

Step 7: Project Closure - Sales Documentation

The automation completes the project lifecycle by recording:

• Actual sale date

• Quantity sold (100 birds)

• Sale price achieved (৳100)

• Receipt photograph (mandatory)

• Product photograph (optional)

Step 8: Payment Collection with Financial Verification

The final step automates the payment collection process:

• Filters to show loans with pending payments

• Views detailed payment breakdown including interest calculation, last payment date, disbursed amount, farmer's debt, and any penalties

• Selects payment method

• Records amount deposited

• Confirms payment and enters OTP to verify the farmer's phone number

• Validates that payment was successfully recorded

The automation then advances to the next status (Payment Processing), where it uploads a deposit slip image and confirms the upload, simulating the complete financial settlement workflow.

Impact by Numbers

Aspect

Manual Testing

Maestro Automation

Time per complete flow

45-60 minutes

12 minutes

Test data

Hard-coded (static)

Unique every run

Maintenance effort

4-5 hours/week per app update

Zero—self-adapts

Manual error rate

~15% (data entry mistakes)

0% (fully automated)

Business validations

Spot-checked manually

60+ automated assertions

Why Maestro Won—A Deeper Look

1. Intelligent Waiting Without Complexity

Traditional tools like Appium require developers to write custom wait conditions for every element with explicit waits and hard-coded delays. Maestro eliminates this boilerplate. It understands when elements are ready and taps them at the right moment, adapting to network delays, animation timings, and device performance variations. The test doesn't fail because an element took 3 seconds instead of 2 to appear—it just waits intelligently.

2. Handles Device Variations Gracefully

Android manufacturers customize the camera interface—Samsung devices show different buttons than Pixel phones. Maestro's optional flag skips elements that don't exist on the current device, and its regex text matching finds buttons regardless of exact wording. Appium tests break immediately when UI elements shift slightly; Maestro adapts.

3. Modular Flows = True Code Reuse

The login flow is called from three different test scenarios (Add Project, Follow-ups, Payment Collection) without duplication. If the login process changes, updating one file fixes all tests. In Appium, you'd either duplicate the login code (painful to maintain) or create complex page objects (verbose, hard to debug).

4. Unique Test Data by Default

Maestro's random data generation functions produce varied inputs each run. This catches bugs that only manifest with different data—a validation rule that fails for certain NID patterns, locale-specific date issues, or business logic flaws with edge case values. Hard-coded test data would miss these entirely.

5. Readable Enough for Non-Technical Stakeholders

A product manager can open the test file and understand exactly what the test does: "It logs in, adds a farmer with phone number 019XXXXXXXX, submits a loan for ৳50,000, adds a poultry project for ৳10,000, records two follow-ups, and collects payment." They can suggest test scenario changes without touching code. In Appium, this requires a developer's expertise.

6. Built-In Validation Without Extra Code

Maestro's assertions are simple but powerful. Rather than taking screenshots and manually comparing, the test validates that critical UI elements appeared at the right time. If a screen transitions but a mandatory field is missing, the test immediately fails and reports which element wasn't visible—pinpointing the bug precisely.

7. Resilience to Fragile Selectors

UI changes break Appium tests constantly—a developer renamed an element ID from etFarmerName to etName, and now 50 tests fail. Maestro's mixed approach (ID when available, text matching as fallback, coordinate-based for maps) means tests survive minor UI refactors. The automation keeps working because it's not dependent on a single brittle selector.

Conclusion: From Manual Effort to Reliable Automation

Automating the Sofol mobile app with Maestro demonstrates how modern mobile testing can move beyond fragile scripts and time-consuming manual execution. What once required nearly an hour of repetitive manual validation can now be executed consistently in minutes, with every step—from farmer onboarding to payment collection—verified automatically. By generating unique data, validating business rules, and simulating real field operations, the tests ensure that critical farmer services continue to function reliably as the app evolves.

As Sofol continues to grow and support more farmers, having a robust, maintainable, and scalable automation framework ensures that innovation can move fast without compromising quality.

Written by Md. Anisur Rahman, Junior QA Engineer at iFarmer Ltd.