David Dietz

During my time at LoopQA, I've found that an effective model for leveraging automation involves a clear division of responsibilities between development and QA teams. I'll caveat this by saying, I generally advocate for developers to refactor the automation they break, but the reality is that most organizations aren't willing to invest their time into it. Hence, having a dedicated QA team for E2E tests often proves more practical. Here's a typical and highly functional workflow: Local Development: -Developers work on their local environments. -They run unit tests and integration tests to ensure their code is functioning as expected. Dev/Test Environment: -Code is merged into a shared Dev/Test environment. -Unit/Integration Tests: These tests must pass before any merge can occur. If they fail, the merge fails. -E2E Sanity Tests: These are also run, but they can fail for both valid and invalid reasons. Developers need to be adept at identifying actual bugs versus new legitimate failures. -Automation teams step in to refactor failing E2E tests to ensure stability. A common problem here is when dev teams opt not to refactor failing tests, leading to false negatives and potential issues down the line. Stage/Pre-Prod Environment: -After passing all tests, the code moves to the Stage/Pre-Prod environment. -Any merge to this environment is contingent on passing E2E tests along with unit and integration tests. Production Environment -Finally, the tested and validated code is merged into the Production environment. Key Insights: -This model ensures that unit/integration tests act as crucial gatekeepers, providing immediate feedback to developers. -E2E tests, maintained by the QA team, ensure overall system validation and highlight integration issues early. -Collaboration and clear division of responsibilities between dev and QA teams maximize the value of automation, leading to robust and reliable code delivery. #SoftwareDevelopment #QA #Testing #DevOps #SoftwareQuality #Automation #ContinuousIntegration #ContinuousDeployment

46

9 Comments

In simple words - testRigor is the #GenerativeAI #QA #software answer you've been waiting for. Free sign-up here: https://lnkd.in/dp9tAMRB

2

Should the entire development team attend all of the sprint events? No, because it’s inefficient and a waste of time. Right? Years ago I battled a tough client who didn't want the developers to attend the Sprint Review. He wanted them to, in his words, “just keep coding”. I argued…how will the team learn about what the customer and the business needs? His predictable answer was “better requirements documentation”. Software engineers are professionals who need to deeply understand the problems to be solve. The intent of sprint events is to provide context for these problems and enable collaboration. Ask your developers if they are receiving value from sprint events. If not, don't exclude them. Fix the events so they enable the development team. #scrum #agile #collaboration

2

Between 1995-2010-ish it was popular in the agile community to talk about patterns and principals. 15-25 years later we see the industrialized late adopter / laggard version of agile as the norm. I wonder if the "product operating model" (a synthesis of patterns in use for ~20y, similar to how a 2010 agile pattern language represented patterns in use starting in the 80s and 90s) will follow the same trajectory based on the introduction of domain-specific pattern languages? In 2035 will be be talking about the "death of the product operating model"? History would say....yes. The funny part about Agile is that I would say the *core* ideas are perhaps even MORE in demand (or relevant) now, even among the companies that see themselves as high performing product orgs. You can argue that *some* Agile ideas have widespread adoption, but when you look at how few companies have healthy, functioning teams that follow some of the edgier and heretical parts of the agile manifesto, you might view those companies as the "top" 1-2%.

269

81 Comments

Hey LinkedIn, a gap I consistently see in the world of test automation is managers understanding how to hold automation folks accountable. Particularly in startups or non-traditional software companies, QA automation falls under the CTO/Director of Engineering and they have enough other priorities where they just tell the automation engineer to go off and do their thing. I've tried to lay out some very basic questions/checkpoints for managers to quickly touch base on: Before starting, 30 days in, 90 days in & 180 days in. The article provides a 6-month strategy to prevent automation projects from failing. It outlines key questions to ask, expectations at different stages, and common pitfalls to avoid. This guide aims to help technical leaders ensure their test automation initiatives deliver real value and don't become abandoned projects. Hope it is helpful! Check out the full article here: https://lnkd.in/gSyPAmwE #TestAutomation #QualityAssurance #TechLeadership

53

15 Comments