When is it the appropriate time for QA? Who is responsible for quality when working in such a small team?

Work in the open. Create a culture on your team that encourages sharing unfinished work and working live together. This will drive the highest quality bar for your team. If you wait until the end of development to QA too many problems will be compounded.

Some rituals I use to encourage a high quality b ar throughout the entire product development lifecycle:

1. Fresh Eyes - Once a week anyone in the Product Squad can demo unfinished work for the purpose of getting feedback mid-build. The phrase and concept of “Fresh Eyes” comes from Shopify - it’s part of their culture to value feedback throughout development and actively seek it.
2. Weekly Demos - Every Friday anyone in the Product Squad can demo near complete work (PM, UX, Eng, Data). The purpose here is to celebrate progress and create a shared understanding of what the product will be. There can be great feedback that comes in these sessions, but typically more minor edits around design elements (padding, text, etc) vs fundamental functionality changes.
3. Journey Checking - All too often, I’ve seen great product visions and phenomenal products not live up to the dream. When work gets broken up into bits and pieces for engineering you easily lose sight of the journeys. It is the job of the PM to define and educate the group on the key personas and journeys they will take in the product. In the weekly demos, the PM should choose one journey every week to show where you’re at with it. Individual bits may work in isolated demos, but when you string a journey together you will quickly find a lot more gaps and issues.
4. Prototype as Requirements - The UX prototype is a living, breathing requirements document that provides incredible detail beyond what a written doc could. This is the bar that is referenced and should be actively referenced by eng as they’re building. Things that cannot easily be seen in a prototype should be written as requirements by PM.

I've worked with some teams that have dedicated QA people and others with none. If QA falls solely on 1 person, this can also become a challenge where engineering is not checking along the way becuase the attitude is "Oh, QA will catch it" and this can create inefficiencies in your process.

There's a saying, "if everyone is responsible, no one is." This sometimes happens regarding QA.

Ultimately, I hold the product manager accountable for quality of the resulting product. If something isn't working, they have to prioritize and coordinate the work to make it right. To help combat this, PMs need to create the right amount of detail clearly answering "What does success look like?" ahead of code being written so that the engineering teams can check what they produce with the acceptance criteria.

QA should always be an ongoing effort and be treated as a team effort. There might be spikes in QA efforts based on the complexity of the project but it should never be treated as 1 person responsibility. 

1. Engineering is the first line of defense with unit testing. 

2. Having a test environment where integrated end-to-end testing can be done is crucial for any development team. 

3. PM + Design + EM should periodically be in the test environment testing an integrated experience.

4. For complex products, there sometimes might be an end to end usability testing team but by the time this team starts testing the product, trivial bugs must have already been identified and fixed via activities #1 and #2 listed above. 

   1. “Testing party” is another forum that is worth organizing for complex rollouts or more 0->1. Think of this as a dedicated testing room/slot and include non-development teams (e.g., business, customer success etc.) and sometimes stakeholders/early customer groups as well. 

5. Additionally, creating a QA metric such as number of post launch bugs can also help drive accountability & quality as a development culture. 

For a small team, make QA a culture rather than a process to enable quality products being “shipped at desirable velocity”.