Quality Accelerated: interview with the QAs from the Paralect Accelerator
The 2021 debut of the Paralect Accelerator brought together founders of Nudge and VISXA, product teams including developers, designers, business analysts and advisors. Plus the two teams of student developers from Startup Summer. And — to ensure the products shipped working as flawlessly as possible — two quality assurance engineers 🕵️♀️
Lena and Natasha joined VISXA and Nudge, respectively, with different experiences as QAs on previous projects. Here’s what they learned with their teams during the Accelerator.
What’s different about working on Accelerator startups?
Natasha, you’ve worked on a few projects already — one which was already 4 years old, others brand new — what’s different for you as QA on Nudge?
– The speed that we set up processes was much faster. There was no time to over-think anything, or discuss when we’ll have a retrospective, what was missing or what else should be done. We put minimum processes in place and that’s it — let’s get to work!
It was 100% a startup atmosphere without systems in place. But that made it all the more interesting.
Lena, you dove straight into the VISXA team immediately upon joining Paralect. What were your expectations and what surprised you?
– Before joining, I had a faint idea of what an accelerator was — but I didn’t know exactly what it meant. So it was all new to me.
I didn’t expect that I, as a young QA, and the dev students from Startup Summer would be on calls with the founder. But we were, and regularly! It was super cool, surprising, and such complete immersion in the product team was a great experience.
For me, it felt like a full-on commercial project. I felt responsible — everyone did — and we were all trying to do our best for the successful launch of VISXA.
Project management tools for the Accelerator
For Nudge and VISXA, the team decided to try some new tools and get away from the usual JIRA and Confluence project management stack.
Natasha, what tools did Nudge use and did you notice any differences with them?
– Compared to my earlier projects, we selected simpler tools. Trello instead of Jira for the board and Notion for documentation in place of Confluence. Basically, everything lived in Trello and Notion.
Some of the students had no real-world project experience, so Nudge was their first exposure to the kanban board and agile processes.
We got to teach them how the board works, how to file bugs, how to help us as QAs. This was a chance for the whole team to get a fresh look at the processes — why they’re needed and important.”
On the whole, I liked the Trello board but Notion was a bit simple for docs. Personally, it seemed less usable than Confluence.
So was this a successful change of tools?
– Trello — 100% yes. Especially for the Startup Summer students who are not used to JIRA, Trello is easier to get started with. I’m not so sure about Notion, but maybe others on the product team really like it.
Lena, how did you find the tools?
Everything was new to me, we used Linear for the dev board and I hadn’t worked much with Notion or Figma before. I got used to them all quickly — they’re all very user-friendly and simply diving into them full-time was the best way to learn.
In terms of organization, everything was great — the requirements were clear and I always knew where and what to look for. I found all these tools convenient and capable.
Testing on a brand new MVP
Let’s compare your QA experience on large, established products with the approach to a fresh, from-scratch project. What’s the difference? What’s important to consider when planning an MVP testing strategy?
Lena, what did you notice?
– I jumped straight into testing after a quick onboarding — there wasn’t much time to delve into the product or keep up detailed documentation. This is probably the biggest difference — there was no initial test plan or docs for testing.
But it wasn’t a problem for me or the team. If something was unclear, I knew what to do, where to look and who to ask.
What about you, Natasha?
– Nudge was my first brand-new product experience. The first challenge was that the team made a feature, I checked it perfectly front to back and everything was fine. But time went on, improvements were made, lots of discussions with the founder — more features went live.
And I understood a month has passed and that early feature which worked fine might not be alright anymore.
With an MVP, your main aim is efficiency. When a new feature is built, you understand that right now you need to test its functionality in the most important, positive scenarios. It makes no sense to spend more time perfecting it.”
So my main lesson for from-scratch MVPs is you need to bear in mind that functionality will change with each release. Work with this reality and try to stay efficient without sacrificing quality.
What’s important to focus on in product testing at the MVP stage, Natasha?
– Think like a user. Know what the app works for and that’s exactly what it’s for. Imagine you’re the first user — what do you want to do? I want to go there, do that, and I need that.
Besides that mindset, analyze the situations in which the application will most often be used.
Lena, what’s your take?
– The most important thing is to understand the goal — how the product will be used. Follow the main flow so that the user who came to the app with a specific goal reaches it without any interference. Minor bugs are not important as long as they don’t break key functionality and the user rarely finds them.
Working closely with the founder
The Accelerator teams were small, without several layers of management, and had frequent communication directly with the founders.
What was that experience like for you, Lena?
– For me, as a new specialist, and for the Startup Summer developers who also may never have had such a project — this was an amazing opportunity to dive into the process completely.
It’s great to chat live with the founder, clearly see that they like what we’ve done, that everything is working well. If there were any questions we could openly discuss them and agree directly and clearly. It’s a huge plus — such close communication with the whole product team.”
Natasha, what did you think?
– I love it when the customer is present in a conversation with the whole team. No matter how great the PM, BA or other team members are, I think our advice is very important and the founder should hear it directly.
Because we’re the people who directly develop and test the product, are constantly in contact with it and experience what the users experience. So the shorter the path between the founder and the team — I only see it as an advantage.
If your team had problems or doubts while working on the product — how to best make this or that logic or design element — how did you solve it Natasha?
– If something seemed like an obvious improvement, a best practice, then we’d make this decision and show it during a demo and highlight the change. So each demo there are a few improvements that were purely our ideas.
If it’s a larger change — something that will add more dev time or significantly impact the design — then we’d sync with Julie for approval before starting on it.
What about on VISXA, Lena?
– Each case was different. In the beginning, I talked a lot with our business analyst Alex, or wrote to our designer Sergey for some issues. Depending on the kind of problem or question, I asked certain people or raised it in our stand-ups.
In many cases, Alex would discuss an issue first with the founder. Then he’d bring ideas for a solution to us, we’d discuss the details amongst everyone, make a decision and offer the solution to the founder.
Did you have time to test everything before launching the MVP? Any tips you learned, Natasha?
– Good question! As I said above, keep in mind that the product will change a lot after the release. So don’t test thoroughly what will definitely have to be tested again after more features are added.
Lena?
– The main thing is to prioritize the tasks — we emphasized this and stuck to it throughout the whole dev process.
The result? Everyone knew clearly what to do, what they’ve done, and the bugs were also prioritized, fixed in order. So a high-quality MVP was made.”
There was no confusion from someone breaking something while writing their code.
Final impressions
What do you remember most about working on the Paralect Accelerator products? Lena?
– I was most impressed by the interactions of the people in the team. Absolutely everyone involved in this product could freely communicate with each other.
No one was shy about asking questions — everything was totally transparent and up for discussion. We all understood every process, every step on the way to launch — this was awesome.
Natasha?
– Working with the Startup Summer team! I was a little scared to join Nudge, I’m not sure why honestly. But then I came on the team and everyone was just incredible.
The dev students in Startup Summer were very diligent — I’ve never seen such obedient devs! They tried to fix everything on time, listened to me, asked for advice and were very worried when bugs appeared. Well done! They made my mood on Nudge and I really enjoyed working with them.
If this year someone is also a bit scared to work on an Accelerator project, do you boldly recommend it, Natasha?
I liked it and would totally do it again. It was some kind of challenge in Paralect and it’s cool to be part of this challenge. I’m so glad I decided to go for Nudge!”
For 2022, both the Paralect Accelerator and the Startup Summer program have been updated! The formats remain similar — 2 startups, 2 teams, 2 MVP launches.
But Startup Summer has added a program to train QA engineers as well as full-stack developers. And founders will get added services to launch even better with go-to-market support from our marketing and video teams!
