QA Guidelines - How to Test?

Purpose and Scope

To establish a structured process for managing QA testing tasks and time, ensuring tasks are efficiently tested, bugs are appropriately handled, and completed tasks are accurately reported. This SOP applies to all QA testers, developers, PMs, and BAs involved in the project.

All our apps are built in no-code/low-code. You are ALWAYS testing MVPs, so we need to deliver fast.

The objective of QA is to ensure the functionality of the app and that the UX makes sense, putting yourself in the shoes of real users. We need efficiency overall.

We look for long-term relationships with our QAs, which depend on efficiency and transparency.

Definitions

QA: Quality Assurance personnel responsible for testing tasks/milestones.
PM: Project Manager who oversees task workflows.
BA: Business Analyst who ensures business requirements are met.
"Ready for Revision (Internal)" Column: A column on Plutio indicating tasks ready for QA testing.
Milestones: Tasks that describe what is to be tested.
Subtasks: A task created under a parent task to detail one specific issue or bug (no grouped tickets).

Responsibilities

QA Team:

Verify task readiness for testing.
Conduct thorough testing of assigned tasks.
Report issues clearly and concisely (including evidence).
Provide evidence of task functionality when resolved.
Add:
- Ensure each issue is logged as a separate subtask (no grouped tickets).
- Notify in Slack at the start/end of each testing round.
- Monitor subtasks daily and escalate overdue issues to PM/BA.

Developers:

Address and resolve subtasks or tasks reported by QA.
Provide evidence when the bug/issue has been fixed.
Add: Notify in Slack after completing fixes (e.g., “Fixes deployed for [Task Name] – ready for QA re-test”).

PM/BA:

Ensure QA hours are allocated and estimated per task.
Review tasks for completeness and accuracy.
Provide final approval for tasks involving client feedback.

Procedure

Steps for QA Testing

Confirm Task Readiness for Testing
- The task must be in the “Ready for Revision (Internal)” column.
- QA must not test tasks outside this column.
- The QA must be assigned to the task.
Review the QA Allocated Hours Per Task
- "QA Time" indicates the maximum hours allowed for testing a milestone.
- Track time rigorously to stay within budget.
- Notify PM/BA if additional time is needed.
Test the Flow Described in the Milestone
- Follow wireframes and milestone instructions.
- Add: Post in Slack when testing begins (e.g., “Testing started for [Task Name]”).
Report Issues (If Any)
- Create a separate subtask under the main task/milestone for each issue.
  - Include:
    - Description of the Problem (with screenshots/video).
    - Expected Situation.
  - Assign to developer, set a 2-day due date, and add PM/BA as followers.
- Move the task to the QA column.
- Add: Post in Slack after logging subtasks (e.g., “[Task Name] – X subtasks logged”).
Verify Task Completion
- If no bugs:
  - Add a video/screenshot + “QA passed” in comments.
  - Move to “Ready for Revision (Client)” or “Completed” column.
- Add: Post in Slack when testing concludes (e.g., “Testing completed for [Task Name] – ready for fixes/approval”).
Daily Follow-Up
- QA Responsibility:
  - Check assigned subtasks daily for updates.
  - Escalate unresolved subtasks to PM/BA via Slack if overdue.

What NOT to Test?

No Test Cases.
No testing text field character limits unless specified.
No regression testing.
No unreal scenarios (e.g., 1,000-character titles in event apps).

Guidelines for Clear Communication

Be detailed: Ensure bug reports are clear and include context.
Be timely: Avoid delays in testing or reporting.
Be collaborative: Maintain open communication.
Add:
- Tag stakeholders in Slack for urgent updates (e.g., @dev, @PM).
- Daily Slack updates required for alignment (testing starts/ends, fixes deployed).

Best Practices for Deploying and Testing APPS

Purpose:
To define the standard process for QA and developer testing in software projects, ensuring production-readiness and clear responsibilities for each environment.

QA should test features in both test and live environments to verify proper functionality and production readiness.
Document deployment and testing practices as part of the project's best practices, and ensure they are communicated to all team members and clients.
Developers perform testing on their assigned branch or on the main branch, depending on workflow and the nature of issues being addressed.
QA typically tests on a dedicated QA branch, while final client testing occurs on the live environment once QA approves.
Always ensure the live environment is tested at relevant stages to avoid outstanding issues surfacing only at project close or delivery.
Schedule a kickoff call at the start of each project with PM, Devs, and QA to ensure all credentials and requirements are available before development begins.
Maintain transparent documentation for all testing responsibilities and processes, updating them as workflows evolve.

Responsibilities:

Developers: Test changes in their environment/branch before merging.
QA: Test both on the QA branch and on the live environment as needed.
Project Manager: Facilitate scheduling, documentation, and communication of responsibilities.
Client: Participate in testing on live after QA sign-off.

Review and Improvement:

Periodically review this SOP and update as needed based on project retrospectives or changes in best practices.

This workflow ensures efficiency, prevents late-stage surprises, and supports delivery of production-ready software.