Quality Assurance (QA) in mobile application development is not just about finding bugs. This profession acts as a gatekeeper, ensuring that every feature, every interaction, and every second of user experience functions perfectly under various real-world conditions. With the fragmentation of the Android ecosystem spread across hundreds of different devices, the role of QA becomes increasingly crucial to maintain product reputation. In Indonesia, the demand for QA Engineers has surged alongside the proliferation of technology startups and the rising quality standards of domestic applications.
A career in QA offers exciting prospects. A junior QA Engineer in Indonesia starts with a salary of 4–8 million rupiah per month, while mid-level (3–5 years of experience) can reach 8–15 million. Senior QA Engineers or QA Leads can exceed 15–25 million rupiah, depending on domain experience and international certifications such as ISTQB. Demand continues to rise as every startup now realizes: bugs that slip into production are not just a technical issue, but an expensive business problem to fix.
QA vs QC: Fundamental Differences Often Misunderstood
Many people consider QA and QC to be the same thing. In fact, they are not. QA (Quality Assurance) is process-oriented, focusing on preventing bugs through well-designed testing processes, clear requirement documentation, and mature automation strategies. QC (Quality Control), on the other hand, is product-oriented; it involves detection and reporting of bugs in finished products.
A simple analogy: QA is like a system audit in a company (is the process robust enough?), while QC is like an inspector on the production line (is this product defective?). In modern practice, especially in agile teams, both roles often merge into one person known as a QA Engineer. This person designs test plans, writes test cases, conducts manual and automation testing, and reports bugs with complete details to developers.
Bug Severity vs Priority: Don't Confuse Them
Severity and priority are two different dimensions in bug reporting. Severity measures the technical impact of a bug, how severe the defect is on the application's functionality. Priority measures the business urgency of how quickly a bug should be fixed relative to sprint goals.
A concrete example: a banking application crashes when the user presses the “Transfer” button on Android 12; this has a severity of Critical (crash = highest severity), but it could have a priority of Low if only 0.2% of active users are using Android 12. Conversely, a typo in a button label may have a severity of Minor, but a priority of High if the brand guideline requires perfection across all touchpoints. Industry standards such as ISO 29119 and IEEE 829 establish severity scales: Critical, Major, Minor, Trivial. Each organization can customize, but consistency in naming is important to avoid confusion for developers.
Anatomy of an Effective Bug Report
A poor bug report wastes developers' time as they have to ask follow-up questions to understand the issue. A good bug report is informative enough that developers can immediately reproduce and investigate the root cause. At a minimum, every bug report should contain:
- A concise and specific Title: “Transfer button crashes on Android 12” not “App crashes”
- Steps to reproduce: the exact sequence of actions that produce the bug (user flow, input data, app state conditions)
- Expected vs Actual: what should happen vs what actually happens
- Environment: OS version, device model, app version, network condition (WiFi/3G/4G/5G)
- Attachments: screenshots, video recordings, crash logs, or adb logcat dumps
- Severity and Priority: initial assessment from QA (developers can override)
Tools like Jira, TestRail, and Bugzilla are industry standards for tracking and assigning bugs. They all have mandatory templates or workflows that require QA to fill in the fields above. A complete report reduces back-and-forth, speeds up fixes, and demonstrates the professionalism of QA, a soft skill highly valued in engineering teams.
Software Testing Life Cycle (STLC): Important Phases
Testing is not an activity that starts after developers finish coding. Testing is an integral part of the STLC lifecycle that begins with requirement gathering and ends with maintenance. A mature STLC consists of the following phases.
1. Requirement Analysis: QA reviews requirement documents (feature specifications, acceptance criteria, business rules) alongside product managers and developers. QA looks for gaps, ambiguities, or edge cases that are not covered. This phase produces clarity that serves as the foundation for test planning.
2. Test Planning: QA creates a test strategy covering testing scope, resources, timelines, and risk assessment, as well as automation opportunities. This document becomes the roadmap for the subsequent phases.
3. Test Case Design: QA writes detailed test cases, with one test case equating to one specific scenario that tests one aspect of functionality. Each test case must be executable and repeatable. Tools like TestRail help organize test cases into test suites per feature or per OS version.
4. Environment Setup: QA prepares the test environment, including a device farm (various OS versions and device models), staging servers, test data, and monitoring tools such as Logcat for Android, Crashlytics for crash tracking, and Firebase for real-time monitoring.
5. Test Execution: QA executes test cases through manual testing for happy paths and exploratory testing, and automation testing for regression. Each failure is logged as a bug in Jira or Bugzilla, with attachments such as screenshots or logcat dumps.
6. Test Closure and Reporting: After release, QA compiles a report detailing how many bugs were found, how many were closed, severity distribution, and defect escape rate (bugs that made it to production). This report serves as feedback to improve processes in the next sprint.
Types of Testing: From Functional to Exploratory
There are many types of testing, and QA Engineers need to know when to use each type. Some of the most common in mobile apps include:
Functional Testing: Tests whether features work according to specifications. Examples: testing money transfers, testing logins, testing product filters. This is the most common and straightforward type of testing.
Regression Testing: Tests whether fixes or new features do not break existing features. Regression testing is often automated due to its repetitive nature and large volume of test cases. It is critical to prevent the “fix one bug, create a new bug” syndrome.
Smoke Testing: A quick and superficial test to validate that the application can open and main features are accessible. Conducted every time a new build is deployed to staging, for early detection of critical breakage.
Exploratory Testing: QA uses intuition and domain knowledge to test features without following detailed test cases, searching for edge cases and unexpected behavior. This complements functional testing and often uncovers the most unusual (and valuable for user experience) bugs.
User Acceptance Testing (UAT): End users or clients test the application to validate that the product meets their business needs. QA supports by creating test scenarios and checklists, but execution is carried out by the user.
Mobile-Specific Challenges: Android Fragmentation and Network Variability
Testing mobile apps has its own complexities that do not exist in web or desktop environments. First, fragmentation: the Android ecosystem includes OS versions from Android 5.0 Lollipop to Android 14, and there are thousands of device variants from various manufacturers with custom ROMs and screen sizes ranging from 4 to 7 inches. Developers can optimize for Android 13+ only, but research shows that 25–30% of users in Indonesia still use Android 10 or older due to the low price of second-hand devices and long upgrade cycles.
Second, network conditions are highly variable in Indonesia. QA must test applications not only on WiFi but also on 3G, 4G, and 5G with varying latency and packet loss. An application that runs smoothly on WiFi may hang or timeout on 3G. Firebase or Crashlytics help monitor real-world performance, but manual testing under various network conditions remains essential.
Third, battery and memory constraints. Mobile devices are more resource-limited than laptops. An app with a memory leak can drain the battery in 2 hours, frustrating users. QA needs to monitor memory usage via Android Studio Profiler, battery drain via Battery Historian, and conduct long-term stability tests by letting the app run for 8 hours, then testing functionality to see if it remains normal.
Log Capturing in Android: Logcat, Crashlytics, and ANR Detection
When testers find bugs, developers need evidence to debug. In mobile, the most valuable evidence is crash logs or error logs. Android has several ways to capture logs.
Logcat via ADB: Android Debug Bridge (adb) allows developers or QA to pull real-time logs from devices or emulators. A simple command: adb logcat. Logcat displays all print statements and exceptions from the application and system. It is very useful when reproducing bugs in a controlled environment. However, in production, users do not have adb access, so logcat is not a solution for capturing bugs that occur in users' hands.
Firebase Crashlytics: This is the modern standard for capturing crashes in production. Every crash, Crashlytics automatically captures the stack trace, device info (OS version, RAM, manufacturer), user session info, and breadcrumbs (the sequence of actions before the crash). QA can open the Firebase Console and filter crashes by OS version, device model, or custom events. For example, “Show me crashes on Samsung Galaxy A10 running Android 9” is very powerful for debugging rare environment-specific bugs.
ANR Detection (Application Not Responding): If an application freezes for more than 5 seconds in the foreground, Android triggers an ANR dialog and logs the ANR trace. This trace shows which thread is blocked and why. Firebase Crashlytics also tracks ANR as a type of “crash.” QA testing must deliberately trigger heavy operations such as large database queries, file downloads, and complex computations, and monitor whether ANRs occur.
QA professionals always attach logcat dumps or Crashlytics links in their bug reports. This exponentially speeds up debugging. Developers do not need to ask “what device are you using?”, “what OS version?”, as all this information is already in the logs.
The Importance of QA Culture in Indonesia's Tech Ecosystem
In the global market, applications with bugs are harshly evaluated; ratings drop drastically, and uninstall rates are high. In Indonesia, awareness of quality is still developing. Many local startups push features quickly without proper testing, then face reputational damage. QA is not a cost center; QA is an investment in sustainable product quality and user trust. As Indonesian startups become more mature and competitive, QA Engineering is becoming an increasingly critical profession. Organizations with quality QA Engineers, solid testing processes, and high automation coverage are the ones that can scale products with confidence. This is an industry trend that will continue into 2026 and beyond, meaning the career opportunities for QA Engineers in Indonesia will continue to rise, making this profession one of the most solid career investments in technology today.
References:
- ISTQB – Certified Tester Foundation Level Syllabus → istqb.org
- Google – Android Testing Fundamentals → developer.android.com
- Ministry of Testing – Mobile Testing: A Complete Guide → ministryoftesting.com