"What advice would you give for getting #developers #TestInfected and grow their #QA chops …"So here we are. I'm going to share my thoughts on how developers can grow their QA chops, to use Stephen's words.
If you're fortunate enough to be working with an Agile™ team, then you've already got an advantage because if you're doing it right, your team will be made up of specializing generalists whose collective goal is to complete all the stories committed to within each sprint. This sets the stage nicely for any team member to feel empowered or even encouraged to perform tasks beyond their defined specialty - in this case, testing even though they're a programmer. So there's a little motivation/reasoning.
Let me start with what I believe is the most important piece of advice I can give on this topic: Programmer's can still use their primary skill set, coding, in the pursuit of assisting with testing. Sure, to catch up on a QA backlog we can teach testing skills and set programmers loose on exploratory testing of features and fixes. But that would be a lot like handing engineers buckets and telling them to bail out the sinking boat, instead of fixing the broken bilge pumps.
1. Please, please, (and one more for importance) PLEASE write unit tests.
If you're not already doing this then I'm not convinced you're looking to grow your QA chops. This is easily the quickest win for getting developers to help with testing. Now, it's not just that easy. I've seen many instances where unit tests get added for the sake of having unit tests without much thought being put into what they test. Test the happy path, then test the negative cases, and any edge cases you can identify that seem valuable. Then grab a tester, show them the scenarios you've got and see if they have any more suggestions about what to test. Ok, now you've got good, useful unit test coverage. But that is likely not enough on it's own.
2. Pair with a tester, find out what cases they would test, and discuss how much of that can be tested in code. Now, do it.
If a tester says "Well I'd do x,y,z and then check that the expected value was written to the database"...you've got a candidate for a database test, or an integration test. The tests you come up with don't have to cover the *exact* steps that the tester would take. The goal here is to answer the same questions they were seeking to answer in their described testing scenarios.
Maybe you don't have the infrastructure in place to create and execute these kinds of tests. That happens a lot. In that case, you can discuss whether now is the right time to add them or not (make a value assessment around what info you'd be getting from the tests). If it's not the right time, log a tech debt ticket or a story and work with your product and engineering managers to get them prioritized appropriately.
3. Pull branches when doing others' code reviews, and exercise the code locally.
Here's where we diverge from just testing in code. A Tech Beacon article on the subject states:
"Pure code-based testing fails because it lacks the human factor. Humans do interesting things to applications in ways that are often surprising. [Testers] enhance the success of coded tests by providing a human eye, and a human element, to help anticipate that."
Want to help get a jump start on early testing coverage? Well those code reviews you're doing (you ARE doing code reviews...aren't you?) is a great time to execute some high level exploratory testing. Don't just read the code changes in your friendly neighborhood diff viewer or code review tool, but actually pull the code and dive in through your IDE. Experience the code the way you would if you were the one writing it. Then click that run button and actually give the feature a test drive armed with your knowledge of the code change. The more you discuss with testers about how they'd explore through features during their testing, the more efficient you will be at doing this on your own at code review time...likely catching important bugs early in the process.
4. Start by having debriefs done. Then move to participating in debriefs.
I covered this a little bit above. If you can't pair with a tester when you're starting out to help you learn to think the way testers think, then at least do debriefs with them. After you've done some testing, grab a tester and walk them through what you did, and why. This can foster a healthy discussion around what kinds of workflows need to, or do not need to, be exercised. For instance, if you can prove edge cases were covered in other automated tests, then great! No need to run them manually. Perhaps the tester will point out some additional things they'd have tried, and you can go back and do it... and in the process, sharpen your ability to identify those types of scenarios in future.
5. Seat time
In past, my spare time has involved racing cars. At many driving schools and speaking with many experienced drivers, they'd almost unanimously agree on the single most important thing to improve one's driving skills.
"Seat time."What they meant was that the single best thing you can do is practice. Now the caveat to this is to have advisers, teachers, mentors or whatever you want to call them ensure you're practicing the right behaviors and not bad ones. The same is true for testing. With enough practice and the right guidance, you can teach your brain to think the way a tester does. This is why I keep encouraging "talk to your testers!" Ask questions, discuss, and listen with an open mind to how they think, and why they do the things they do.
For those REALLY interested
There are other ways if you truly want to keep growing your QA chops. For instance, a couple times a year, our local testing meetup KWSQA hosts Testing Games nights. Anyone is invited. At each event, a company offers up their app to be put through its paces. Attendees are then encouraged to test and find bugs in the app in any way they feel is appropriate. Bugs get logged, and often there are prizes for most creative test, biggest security flaw, and other interesting things that attendees find. This is a great way to practice testing in a fun and open environment against an application not in your usual domain.
Good luck, and happy testing!
No comments:
Post a Comment