The purpose of this document is to define the QA processes, responsibilities, and best practices for ensuring consistent and high quality testing across web and mobile applications developed by Nextera.
These guidelines currently apply to manual testing, but are designed to accommodate future automation testing when implemented.
QA engineer
- Review requirements and acceptance criteria before starting testing.
- Create and execute test cases.
- Document defects / bug with complete and clear information.
- Communicate with developers and product owner to clarify issues.
- Execute testing after bugfix
- maintenance product post release
SQA Lead
- Oversee test planning, execution, and reporting.
- Ensure all testing follows QA guidelines.
- Coordinate with development and product teams for every project and defect.
- Review and approve test reports before release.
Feature Readiness Checklist (before starting test):
- Requirements documentation are complete and approved.
- Acceptance criteria are clear and testable.
- Development notes and or change logs are available.
- Test environment (dev and or staging) is ready.
Testing Flow:
- Ready for QA → Confirm readiness for the documentation and criteria are clear.
- Test Case Creation → Creating test case for testing.
- Test Execution → Follow test cases or perform exploratory testing.
- Defect Reporting → Log bugs in ticket with all required details (see Section 5).
- Retesting → Verify bug fixes and close tickets if criteria are met.
- Regression Testing → Check related features for potential impact.
Types of Testing Performed:
- Functional Testing
- Regression Testing
- UAT Support (if requested by stakeholders)
Storage Location: Google Sheets – stored in shared team drive for easy access.
Test Case Format:
- ID: Unique identifier.
- Title: Clear and concise description of the test
- Preconditions: Setup needed before execution
- Steps: Actions to perform
- Expected Result: What should happen
- Actual Result: What actually happens during testing
- Status: Pass / Fail / Blocked
- Bug Severity: what the severity level of the bug.
Result Recording Rules:
- Always update the actual result column after execution.
- Attach evidence in the Google Sheet (link to screenshots/videos in drive).
¶ Bug Reporting Standards
Required Details in Jira Ticket:
- Title of the bug (short but descriptive title)
- Summary of the bug with the actual result vs expected result.
- Steps to Reproduce (numbered list)
- Environment (dev, staging, production)
- Device used (web browser, mobile android, mobile ios)
- app version
- Attachments (screenshots, videos, logs if relevant)
Severity Definitions:
- Undoable - Issue force close where user cannot do anything at all.
- Blocker - Issue that blocking user cannot do anything when doing flow for example app crash, freeze, stuck on loading, etc.
- Major - Issue that have big impact for the user for example like functionality issue
- Medium - Issue that impact are in gray zone also depend on perception, for example the display issue.
- Minor - Small impact, cosmetic, or low-risk issues.
Pre-Release Checklist:
- All Undoable, Blocker and Major bugs are resolved and verified.
- Smoke test passed in staging for both web and mobile platforms.
- Regression test completed for all impacted modules.
- QA completed testing and recorded ready for release.
Regression Testing Rules:
- Prioritize features directly affected by recent changes.
- Include core user flows for both web and mobile apps.
Post Production release:
- QA recheck the feature that released on the production if possible retest the flow.
- Regression test for all impacted modules if possible.
Tools Used:
- Jira – Ticket tracking, bug logging, sprint management.
- Google Sheets – Test case management and execution records.
- [Future] Automation Tool – To be defined when automation testing starts.
Environment Rules:
- Use dev/staging environment for all testing unless otherwise approved.
- Avoid using production data; use test accounts where possible.
These guidelines will be reviewed per semester or after major changes in process.
Team members are encouraged to provide feedback or propose improvements to ensure the QA process remains effective and efficient.