How Test Fest Transforms Product Quality with Collaborative Testing

What Is Test Fest

The usual testing workflow—development hand‑off, test execution, regression testing—relies on testers to collect and report defects, then hand the finished feature back to the product side.

Because issues discovered during testing are not fed back to the whole team instantly, a method is needed to gather relevant stakeholders for multidimensional product quality assurance.

“The main idea behind the Test Fest conference was to create a platform where we can learn something new, meet people and discuss interesting quality related topics.” — testfest.pl “Test Fest” originated abroad as a platform for discussing product quality topics.

Inspired by Test Fest, our company launched an internal Test Fest: a small‑scale crowdsourced testing activity where the testing team invites product managers, developers, designers, operations, and customer‑service staff to conduct exploratory testing and discover bugs together.

Four Major Testing Pain Points Solved by Test Fest

1) Why is communication always the tester’s burden?

A massive requirement document may be changed many times and interpreted differently by various roles. Conversely, a fragmented set of requirement documents leaves each person familiar only with their own module.

Relying solely on testers to coordinate communication is inefficient; face‑to‑face interaction solves this.

A Test Fest lets product managers see the product early, catch misunderstand‑ings, reduce fix costs, and later discover product‑level defects that prevent envisioned requirements from being realized.

2) Why are bugs only discovered after release?

Changes to entry points or copy do not guarantee a bug‑free implementation; they may trigger new scripts for customer‑service or operations.

Testers are pressured to test “fast and well.” Limited time forces trade‑offs, causing some “unimportant” tests to be skipped.

A Test Fest enables every role to test from their own perspective, gaining deeper product insight and identifying strengths, weaknesses, and improvement ideas.

3) How to achieve broader compatibility testing?

Resources are limited; not all device models can be covered. Some defects appear only on specific devices, and fixing them after release is costly.

Android’s device diversity makes full coverage impossible; network, system, and brand variations affect many users.

Test Fest assigns different device models to participants, allowing rapid exploratory testing that uncovers device‑specific issues.

4) How to evaluate new feature experience?

“Eat your own dog food.” – using your own product helps improve it.

During execution, participants discuss competitor implementations, propose optimizations, and turn experience‑related suggestions into product requirements.

How Testers Organize a Test Fest

After defining clear testing goals, the process is broken into four steps.

Step 1: Preparation

Determine the host, usually the lead tester for the product.

Divide the product into modules based on test cases and label test types.

Design 1‑3 specific test scenarios for each module and assign them to participants to avoid overlapping exploration.

Assign a responsible person for each feedback item; this person should be a tester familiar with the module.

Send invitations, confirm participant count, allocate test devices and pre‑install the product.

Step 2: Task Distribution

The host introduces the test scope, distributes devices or platforms, explains the assigned modules, provides defect submission links and formats, and indicates the responsible handler.

Step 3: Issue Collection

During testing, bugs or suggestions are declared verbally on the spot, then submitted to the defect management platform with a title prefixed by “[Test Fest]” or “[Bug / Suggestion / Bug‑to‑Requirement]” and assigned to the appropriate handler.

Step 4: Follow‑up Work

Feedback filtering: the handler reviews feedback, assigns bugs to developers and suggestions to product managers, and de‑duplicates similar reports.

Bug priority management and regression testing promotion based on the project stage and feedback composition.

Impact of Introducing Test Fest at Different Testing Stages

1) After the first round of testing and defect fixing

In recent practice, Test Fest generated effective bugs accounting for 70% of the total. Bugs are categorized as: P0 — crash or block issues P1 — regular issues P2 — UI issues P3 — experience issues

2) After two rounds of testing with a controllable defect trend

Effective bugs represented about 50% , with 20% product suggestions and 30% rejected or duplicate bugs.

Rejected bugs require developers to annotate the reason; developers can explain the root cause and discuss possible fixes for the next version.

3) After multiple rounds, when remaining bugs are single‑digit

Effective bugs drop to 20%‑30% , mainly product suggestions. These suggestions often reflect product‑requirement viewpoints and should be routed to product managers for potential innovation.

At this late stage, fixing bugs may involve large code changes that risk introducing new issues, so impact assessment is essential.

Ensuring Successful Test Fest Adoption

Getting non‑testers to spare two hours for testing can be challenging. Success requires clear hosting effort, timing, venue, and incentives.

1) Host responsibilities

Timing : Prefer 2:00‑5:00 PM when overall team efficiency is lower, minimizing disruption.

Venue : Use a spacious meeting room or lounge to create a relaxed atmosphere.

People : Secure project manager endorsement and consider honorific or material incentives.

2) Suitable test content characteristics

Broad coverage : Includes network, device models, user actions, and application types.

Low time‑sensitivity : Activities that do not require immediate turnaround.

Low complexity : Avoid deep technical or specialized test cases that demand extensive training.

3) Designing effective test cases

Focus on “scenario‑based testing” rather than merely executing scripted cases. Simple scenarios allow participants to explore freely while keeping the focus on core functionality.

Test Fest Effectiveness

Our experiments show that Test Fest uncovers misunderstood requirements, compatibility problems, and post‑release support issues, while significantly improving testing efficiency and quality. Each session costs about two hours, delivering a high ROI.

The format can be extended to retrospective testing of long‑unupdated features or comparative testing against competitors, involving non‑technical staff for functional testing and technical staff for performance testing.

Conclusion

An effective Test Fest engages every participant, gathers proactive feedback, and serves as a valuable supplement to regular testing while providing a platform for other roles to understand testing processes.