Featured case study

Lobika quality assurance

Testing an event-management product across registration, billing, event lifecycle, guests, invitations, RSVP, and access-control flows.

Role
Software Quality Assurance
Approach
Manual QA with technical validation
Evidence
Test cases, defect records, and sanitized screenshots

434

documented test scenarios

386 user-facing and 48 technical/backend

60

passed executions recorded

15 user-facing and 45 technical/backend

83

defects documented

across product and technical flows

75

QA-verified fixes

passed during documented retesting

Scope

My role in the product

Testing responsibilities

  • Functional and exploratory testing
  • Positive, negative, and business-rule validation
  • Test scenario and test case preparation
  • Bug reporting with supporting evidence
  • Defect verification and regression testing

Technical validation

  • Database validation using MySQL
  • Backend-state investigation using PHP Tinker when necessary
  • API request and response validation using Postman
  • Browser diagnostics using Chrome DevTools
  • Git and GitLab workflow collaboration

Process

QA workflow

  1. 01

    Understand

    Review requirements, product rules, and expected behavior.

  2. 02

    Design

    Prepare positive, negative, edge-case, and business-rule scenarios.

  3. 03

    Execute

    Perform functional and exploratory testing across connected flows.

  4. 04

    Validate

    Inspect API, database, network, or backend state when necessary.

  5. 05

    Report

    Document reproducible defects with clear expected and actual results.

  6. 06

    Verify

    Retest developer fixes and run relevant regression checks.

Test design

Representative test cases

A selected sample from the documented suite, showing positive, negative, edge-case, integration, and authorization coverage.

IDCoveragePriorityScenarioResult
TC-REG-P01PositiveP0Successful registration with valid dataPassed
TC-REG-N11NegativeP0Verification token cannot be reusedPassed
TC-REG-N14NegativeP1Resend is rejected during cooldownPassed
TC-REG-N15Edge caseP1Rapid double submission creates only one pending registrationPassed
TC-REG-P10UI behaviorP1Notification timing remains consistent across navigationFailed
TC-PWD-N13TechnicalP0Client-side cooldown state cannot bypass server enforcementPassed
TC-BIL-N05IntegrationP0Duplicate payment callback does not apply the result twicePassed
TC-BIL-N18AuthorizationP0A user cannot poll another user's pending invoicePassed

Documented scenarios and execution results are reported separately; unexecuted cases are not counted as passed.

Defect reporting

Selected bug reports

Five examples selected for variation in business logic, integration, responsive behavior, error handling, and data persistence.

LOB-029

Billing

Expired payment session remained actionable

Integration / state consistency

QA retest passed

Scenario
A user continued a payment from purchase history after the payment session had expired.
Expected
The transaction should be marked expired and the obsolete continuation action should no longer be offered.
Actual
The transaction remained pending and opening it produced an expired-session response.

Fixed by development and passed documented QA retesting.

LOB-032

Authentication

Login content could not be reached on a mobile viewport

Responsive behavior

QA retest passed

Scenario
The login page was reviewed at a mobile viewport size.
Expected
All form content should remain reachable through normal scrolling.
Actual
Part of the page was inaccessible because the viewport could not scroll correctly.

Fixed by development and passed documented QA retesting.

LOB-049

Guests & invitations

Invitation action did not reflect the completed event state

Business-rule validation

QA retest passed

Scenario
Create Invitation was selected for events in active and completed states.
Expected
Invitation creation should be blocked with state-specific guidance once the event can no longer accept new invitations.
Actual
The completed-event state displayed behavior intended for a different lifecycle state.

Fixed by development and passed documented QA retesting.

LOB-065

Public RSVP

Expired RSVP link exposed an application error state

Error handling

QA retest passed

Scenario
An RSVP link was opened after its confirmation deadline.
Expected
A clear, product-level expiry message should be displayed.
Actual
The flow exposed a framework-style error or an incomplete blank state.

Fixed by development and passed documented QA retesting.

LOB-067

Invitation configuration

Edited RSVP configuration was not persisted

Data persistence

QA retest passed

Scenario
Existing RSVP configuration was edited, saved, and opened again.
Expected
Previously saved values should remain available when the configuration is reopened.
Actual
The edited values were not retained or displayed after saving.

Fixed by development and passed documented QA retesting.

Technical evidence

Evidence used during investigation

Sanitized Postman form-data request evidence

API request validation

Request method, body type, and payload structure were checked while private endpoints and values remained redacted.

Sanitized 403 authorization result from Lobika testing

Authorization validation

Direct access to a restricted event action returned the expected 403 outcome.

Sanitized Chrome DevTools network evidence

Network investigation

Repeated update requests were captured after a successful payment flow.

Sanitized payment link 404 evidence

Payment-link failure

An obsolete payment URL returned 404 and exposed a state-consistency problem.

URLs, identifiers, tokens, commercial values, and other internal details are intentionally redacted. Raw database and backend-state screenshots are not published.

API validation

Validated request structures, payload behavior, response codes, filtering, and failure paths with Postman and internal API documentation.

Database verification

Used MySQL to inspect stored records and compare application behavior with the underlying data state.

Backend state investigation

Used PHP Tinker when necessary to inspect model state and support defect investigation without treating it as a coding showcase.

Browser diagnostics

Used Chrome DevTools to inspect authorization outcomes, failed resources, network activity, and client-side application behavior.

Working toolkit

PostmanMySQLPHP TinkerChrome DevToolsGitGitLabExcelGoogle SheetsGoogle Docs

Technical QA capability

API testing and contract validation

API testing is part of how I validate software quality. These examples show how I work with authentication, request parameters, payload rules, response codes, and documented contracts. They come from earlier backend project work and are included specifically as evidence of technical validation skills relevant to QA.

Sanitized API documentation evidence from Damai Putra

API validation evidence

Damai Putra

Validated a POST endpoint contract covering bearer authentication, required multipart fields, request structure, and success and validation response codes.

API contractRequest / responseHTTP statusPostman
Sanitized API documentation evidence from Homewiz

API validation evidence

Homewiz

Validated a GET endpoint contract covering filters, pagination, date parameters, allowed status values, authorization, and documented response outcomes.

API contractRequest / responseHTTP statusPostman