After about a year in the role of product analyst, I walked into the office one day and noticed “The Destroyer” written in bold on top of my desk. As daunting as this sounds, it was an honor. Why you ask? For the first few months that I was in the office, I was bringing our development environment’s CPU pod down every day because of how rigorous my testing was. I pushed Coherent Spark to its very limit and tried edge cases on every single feature. As frustrating this was for our DevOps (software development and IT operations) team, it led to interesting findings and further optimization techniques on performance.
Our exceptional team of developers and QA (quality assurance) testers does the same work, but on a more professional and much larger scale! Spread across the globe, Team Spark makes sure that all our customers have a smooth user experience.
How does the team function?
We are firm believers in the Agile Framework and make sure we follow it for a seamless end-to-end journey for our customers. A typical sprint is two weeks and begins with a sprint planning session, which defines the stories and tasks that should be included. A typical day for the team starts with a stand-up call where our sprint managers get an update on everyone’s to-do list for the sprint. This 15-minute catch-up reminds every one of their sprint goals, as well as how far along they are in achieving them. During a sprint, a task is passed around between a few members – starting from the product owner who defined the acceptance criteria and ending with the QA tester who makes sure all the points were catered to and developed without any bugs. Sprints end every two weeks, and the developers perform a demonstration for all the involved stakeholders. This is a good platform for all product owners to understand if the feature updates are still relevant and get constructive feedback.
At each step of the way, product owners keep track of the efforts made and any blockers that might produce a challenge for the developers. Continuous iteration and development allow the team to get feedback and make any necessary changes.
The real fun starts after the first look!
Once the first iteration of back/front end development is complete, a task ticket is assigned to the quality assurance tester. This is the second check on a feature after the lead developer has already signed off the code. No pressure!
Our testers like to have fun during this process and often make it a challenge by gamifying the number of bugs found. An interesting way to look at this is – if we break the product, then our customers can’t! Tools such as Selenium and Postman help us to do advanced automated testing with professionally written and constantly updated scripts. We use Zephyr to manage manual test cases (when we want to show off even more!) The fun doesn’t end there. Product owners get to have a third look after passing the QA checks. They rely on their knowledge of the industry and client analytics to test the feature with certain use cases in mind. Stretch goals that are not met here are passed back to the QA team. They double check to make sure the issue does, in fact, exist. Then back the ticket goes into further development! If the product owner is content with the feature development or upgrade, the ticket is finally marked as done.
How do we make Coherent Spark client-ready?
A developed feature is only as good as its release mechanism. Words to live by for Team Spark. A new feature is first presented across different teams at Coherent. This is the first phase of unbiased feedback and gives a good understanding of whether the user interface is in fact as seamless as we assumed. One step closer to customers, the product team interacts with other Coherent team members and gets feedback on the functionality, performance speed, use case relevancy and other upgrades that would make the feature more beneficial. Once the team feels comfortable in moving the feature out to production, a release plan is built. The team gets creative with the release notes and our user guide is updated. When the team manager signs off on the new features along with the release notes, we ship it out to our customers. Et voila! You’ve got a brand-new feature.
Why do we spend so long on testing and development?
Ever wondered why a child will draw on your walls even though there is blank paper right in front of them? Consider these children to be the edge cases. There will always be unpredictable use cases on a software like Spark, given its versatile nature, and to account for them we make sure to involve different team members in the process. The fun and purpose of testing then becomes more visible, and we take advantage of each other’s strengths and learn from the mistakes.
At Coherent, we don’t just innovate, we make sure the innovations are working well.
This requires an immense amount of effort not just from the development team but also from our experienced QA testers and the pseudo testers like product owners and designers. Some extra time to release features with a seamless journey is always appreciated by our customers.
How does continuous testing help?
It’s not just the quality assurance that’s important, it’s also the continuous testing. New and old features should all be part of testing scripts in a well-connected SaaS (Software as a Service) product such as Spark. We don’t want to break an old feature for the sake of a new one! Regular QA checks not only help with end user’s satisfaction with the feature, but also improve efficiency in teams by directing them in the right direction of development. Eventually it leads to reduced development and maintenance cost, easy fault recovery and improved scalability.
From ideation to testing and deployment, these are just a few of the ways that we break together to build together at Coherent.
“Testers don’t make the software; they just make it better 😉”
Sadhana Gupta
Associate Product Manager for Coherent Spark
Sadhana is a Associate Product Manager for Coherent Spark and helps build new features and updates on the platform. She has been a part of the team since it's initiation and owns vital pieces including the Spark Assistant, User Management and others. Apart from being primarily involved with the developers and designers in product development and user onboarding, Sadhana is very hands-on with the release cycle and deployment management processes for Spark and manages User Guide updates and release communications to customers!
