How do you teach QA best practices to engineers and product teams?

Quality is part of the SDLC, so it should be a Team Effort. That does not mean you can't split the tasks between Devs/QAs, but everyone should be responsible to ensure high quality. It's beneficial for the business, the customer, but also for whoever is working with the app. If you are not responsible for the quality of your code, the feature will be probably pushed back multiple times and the feedback for each deployment/release will be delayed.

To get the first mover advantage, the QA of the entire ecosystem needs to be strategized. The QA team should be aware about the vision of creating any product, technology used to create products, all moving parts and features of the product, and consumers interest in the product. All this knowledge will help the QA team to devise a customized strategy for the unique product proactively.

Instilling QA best practices in manufacturing demands a holistic approach. Initiate regular training sessions emphasizing real-world scenarios, making the content relatable. Encourage active participation, fostering a culture where engineers and product teams collaborate on problem-solving. Implement hands-on workshops to reinforce theoretical concepts, ensuring practical application. Emphasize the significance of QA in delivering quality products, linking it to overall business success. Cultivate a continuous learning environment, where QA is not just a process but an integral part of the team's DNA. It's about creating a shared commitment to excellence across the manufacturing spectrum.

Often QA teams are considered as First customers of any workable software product. This is because QA understand customer pain areas very well. Although, developers or product owners sometimes might thinks that some features that they'd introduced would greatly improve productivity but in reality unless QA teams are not confident about this new features how customers would know/use it. So, start involving QA teams at the start of requirement itself.

Instead of approaching the Tech perspective I would like to go for how important is the Quality for a product from Business and User perspective. From Business perspective: It helps to stablish a brand getting a possitive reputation that can led to set prices higher than competitors. Also support on the efficiency of the release cadence which again helps the business on getting ahead of competitors by releasing faster and stable. Also reduce customer escalations and reduce the chances of lawsuits, which ends on contract loses. User perspective: Increse the good customer expirience giving the end client what he wants how he wants it. Increase customer satisfaction, customer retention and convert client into advocates that increase the sells

Engineers and developers can often have their own way of working that suits their teams best, and making inroads into that workflow without disrupting them can be a diplomatic challenge. The easiest bare minimum place to begin is advocating for documentation. QA cannot adequately support a project if there are no initial Requirements, or User Stories. With those documents in place and agreed upon by the Product Owners and the Engineers, then the engineers can focus on building towards those requirements without getting lost in feature creep - and QA can design their tests around those Requirements. Everything stays tight and everyone is working towards the same goals.

Promoting QA best practices involves defining clear standards, organizing training sessions and workshops, fostering collaboration, and emphasizing automation for efficient testing and higher product quality.

Working on a team that has the up most standards passing QA might take a while. This would more or less corelate to QA wanting to make sure that the new feature as no adverse affect to production. We can speed up the time it takes passing QA if we start testing as soon as engineers are working on the feature or even sooner when product is writing out the feature spec. Thus teaching QA methodologies to them makes the most sense to greatly move the spread our teams can spit out great features. Start by having QA in product meetings and QA in Engineering meetings. From there, have QA give input and advice on how these features be tested and made to minimize the chance of unwanted bugs appearing in dev environment/ prod.

I think best way to learn new tools, QA processes is to read blogs, make a cookbook for any new learnings, connect with your peers and finally do not assume anything unless it is documented.

I do it with real examples and also teaching the Quality as part of the cultural values of anyone who works in the Life Sciences sector. This is easier with lots of empathy.

One approach is to adopt Continuous testing with CI/CD. Here is an example of a shift left testing approach. From the moment a JIRA ticket is created for a user story, a test ticket should be written at the same time and linked to it and story point. This will ensure everyone in the scrum team understand the QA efforts at the beginning.

In my current team we have acknowledged Quality Assurance as an integral part of our Software development. This means that when we have our yearly planning meet-up, Quality is a major topic just like any other Engineering topic (to MFE or not, TDD) for example. This has allowed us to adopt initiatives like Shift-left strategy where all JIRA tickets must have AC’s as soon as possible and that Engineers are heavily involved in writing these. Involving Engineers in these practices makes them realise the value and in turn becomes second nature.

Additionally, integrating a CI/CD pipeline into the workflow streamlines processes by automating testing and deployment activities. It enables teams to catch bugs early, receive faster feedback, and release features more quickly while ensuring reliability. This approach helps improve code quality, reduces manual testing efforts, and enables consistent delivery of high-quality software

QA teams are integral part of any product developments because they bring different perspective on useful products are or what can be further improved. QA teams should be mature and should assume responsibility of delivering bug-free software products.

Plenty of engineers today have turned into successful entrepreneurs. However, the value of tension will be much valued when collaboration and coordination is in place between engineers and product teams. Although, with a common organization goal which is a successful end-product for their respective customers, Achieving a more respectful, and collaborative environment will require work from both teams.

Sometimes giving negative feedback or criticising your QA team member are necessary because it would help them to improve and they'll learn on their own. This increase maturity in the team which can handle growing pressure especially at tight project delivery timelines.

It requires a mindset shift to move away from perceiving QA as an isolated function and work towards integrating it in every stage of the development process. This requires a unified commitment to quality from every team member. We should advocate for active participation, collaborative learning, and shared accountability for product's quality. Create an environment that values innovation and teamwork. This will improve the product's quality and also cultivate team ethos where striving for quality excellence becomes a shared vision, seamlessly woven into the fabric of our daily work

In my experience the best way to foster a culture of quality is to have everyone responsible for quality. I like to use the phrase “Everyone Owns Quality”, to show that every team member has a part in producing a high-quality product. By making quality a top initiative in the organization with messaging like the one above it enforces to all team members that they play a part in quality.

Do not burden your team with rigorous and unproductive QA processes that would take out their imagination and creativity. Instead give them enough freedom, platform, and all the resources to share their learnings, ideas etc.

Keep reminding that Quality is everyone's responsibility. At every stage starting from requirements, development, testing and monitoring - all stakeholders need to ensure that they are building in quality.

I would like to point that this section is probably the one that has to be in a starting point. To foster the culture of quality should be a top priority over process and tools. If we want to work in Agile or we are woking in Agile, we have to put first people over process. Individuals and interactions over processes and tools, as outlined in the Agile Manifiesto.

Take a holistic approach. Lots of time when the "QA department" is running the quality check process with a lot of test automation at end-to-end level, everyone ends up in lose - lose situation: - E2E suite is often become a gigantic beast to run, often takes a day (or more) to complete the run. - E2E suite is unable to keep up with the recent feature development. - Devs often get frustrated their feature broke something. One of the solution is to take a holistic view of "test case distribution" AKA test pyramid. Tests should be heavier at unit level where testing can be performed easily, cheaper and more comprehensive.