First, this is a really good question and one that I wish more developers would ask! It shows empathy, teamwork, and consideration for the different roles.
Is it ok to tell QA their testing strategy is overkill?
Yes, but let's change the phrasing. "Overkill" sounds too judgemental and will come across in a way you don't intend. As a developer, how would you like it if QA said, "I've found a lot of bugs in your code. Your code sucks! This is terrible work!" You'd probably not like that and "overkill" sounds like that!
Instead, you can say, "I've reviewed the test automation and it seems like we can make some optimizations. Can we work together to understand why we have these tests and find ways to optimize them?" Or, "It looks like we have multiple tests doing the same thing. Why is that? Can we remove some of these tests?"
This is more friendly, allows for teamwork, promotes empathy, and lets them know it's not their failure, that you want to find a good path forward that ensures the software is well-tested, yet optimized for expedient execution!
My initial assumptions are to tell QA...
Well, QA can stand for "Quit Assuming," so I'd recommend to find ways you might be making assumptions and to limit those, to ask questions to find clarity. QA can also mean "Question Asker, Question Anything, Question Authority, Questions and Answers, Questions and Actions, etc"
Assumptions and presumptions lead to bugs, lead to strong egos, lead to an unwillingness to learn/adapt. The old saying is, "Assume is just making an ass out of u (you) and me!" This is probably not your intention.
Next, why do you want to "tell QA?" To me, this shows that devs and testers are on a different level or that QA is beneath a developer, just a developer's assistant. I've had devs tell me these things! "Oh, testers are like a nurse and a dev is like a doctor, so you need to do what I say!" Whoa, no! That sets up a working environment that is not conducive to teamwork!
It is so much better for team relations to see devs and testers as equal partners with different skills. Let's look at a coin: there's a "head side" and a "tails side." Each side is equal; one is not better than the other! You can't have a coin unless both heads and tails are present. I recommend seeing devs:testers this way, as collaborators, not competitors!
I want to avoid the "I'm the developer and I know it should work" problem
Awesome! More avoiding this problem! And "should" is just hoping. QA, we don't like to rely on "should," we want to prove it! Why? Because we know that if a bug takes down production, QA is the first to get blamed. We don't like being blamed, so we take precautions to prevent that by proving it!
The way I approach testing is like using the scientific method. A test case is your hypothesis and testing is proving it right or wrong!
"You only need to test the first flow comprehensively once" and possibly even provide them a more direct way to test that flow (that presumably end users wouldn't call)
Why only test the first flow once? This is often referred to as the "happy path" or "positive testing." This is good for a developer to do, but not QA! QA is there to understand the "sad paths" and all the "negative" test cases: all the ways where software can fail or generate errors!
Software is complex and one cardinal rule is, "Users will always find a way to use the software in an unintended way!" Being curious, exploring the application is fun! That complexity also leads to multiple pathways and many integration points. The testing doesn't need to necessarily occur on the path, but definitely at the integration points! This is where understanding testing techniques help! In my experience, lots of bugs occur on integration!
Instead, good alternatives can be:
- To seek consent (ask if your QA needs help, ask if they have questions versus assuming they need help). This goes a long way to improving relations!
- To seek understanding (ask why type questions to understand why there are duplicate tests)
- Let's find ways to collaborate and work together!
Should QA be aware of under-the-hood application flows?
Yes! 100% YES! QA should be aware of what's under the hood of the application! I have a CS degree and love the QA/testing role! It's fun! And, my technical education allows me to dig into the code in order to test in faster cycles, prevent duplicate tests, build/optimize test automation suites, train/educate developers on proper testing techniques, find race conditions, code review developer's code, approve the code reviews, find bugs in the design or requirements, etc!
If you don't have that level of testing/QA on the team, you can recommend to your tester to take classes on coding (what's relevant to your team). You can sit with your tester, like a code review or like a pair-code session, to explain to them what the code does in a technical sense, what changes you made, how those changes affect the new/existing code, etc. You can even recommend different paths to test! (But be sure to ask if they want test case recommendations first)!
Once they build a test plan, they can sit with you and you can review them before testing! This can be an opportunity to learn more about testing and also see ways to optimize testing. You can see where there are holes in the tests or what functions/methods/classes aren't getting exercised.
I've done pairing sessions with devs to show them how I think about requirements, how to write requirements that are testable, show them in real-time how I write test cases, how to think from different perspectives! Or, finding ways to remove bias? This is a fun exercise to do! Not all users are the same and understanding how a web user is different than mobile user is different from an a11y (accessibility user) or i18n (internationalization) leads to different test cases!
To me, solely doing black-box testing is like guesswork; I don't want to guess, I want to be specific, so white-box testing is always more prudent! I tend to use black-box testing techniques during requirements review and building test cases before any code is written!
I'm wondering if it wouldn't be against some cardinal rule that QA is supposed to be black-box. Should all testing be black-box?
Yes, this is against a cardinal rule of Quality Engineering!
No, not all testing should be black-box! What about gray-box? White-box? End-to-end testing? Accessibility? Localization? Internationalization? Performance testing? Basic security testing? etc, etc
Testing and QA has a deep and broad set of skills, techniques, and fundamentals to ensure the software build is well-tested at all levels across the stack! Saying all testing is black-box does a disservice to the QA role and shows QA is not an equal role on the team.
Did you know the ISTQB, an international board for testing certifications and standards, has a glossary of 569 terms for testing and quality? I highly recommend reviewing it as an initial step in learning more about the depth of testing!
Note: this "black box only" perspective is industry-wide and it shouldn't be. There is a failure in the industry to see QA as only an entry-level role, non-technical role, etc, which is unfortunate! Part of this is due to testing not being taught in Computer Science courses or bootcamps; maybe unit testing is discussed, but it stops there when there are a lot of technical skills/techniques involved!
Let's talk about permutations!
Are you, as the developer, and your QA/tester, aware of basic testing fundamentals like:
- Boundary Value Analysis?
- Equivalence classes/partitions?
- Truth Tables?
- State Machines?
- The Agile Test Pyramid?
- Integration testing
Understanding these concepts are literal ways to properly test software while keeping the amount of permutations limited! I've been on teams where the developers did not know these terms or techniques, so I taught them, which allowed for better testing results!
Overall, my philosophy from 25 years in tech on software and quality engineering is:
- Deliver Excellence: Users should not be finding bugs.
- Collaboration: Quality is a cross-team responsibility.
- Find Clarity: Reduce risk and uncertainty by testing early and testing often, which will improve confidence.
- Consider Perspective: Focusing on user experience, usability, and empathy improves quality. Be an advocate for the customer.
- Be Efficient: Automate for functional efficiency and long-term success.
- Be Curious: “Why,” "How," and “What if” are the best questions to ask.
Hope this helps! Working with teams on developer relations is something I've done a lot!
