It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
It's a bit awkward for us because our QA department is based halfway around the globe. We have our standups as early as possible and they've adjusted their working hours so there's a little overlap when we can talk to each other without a time lag.
We deploy every evening (our time) so they can start validating the latest resolved tickets in our issue tracker as soon as they clock in. If they find a problem, they'll create a new ticket or reopen an old one as appropriate. When we're gearing up to release, we'll deploy to a second environment that doesn't get automatic updates so they can run their automated regression suites against it without having to worry about timing.
Our testers have some facility with programming, but focus entirely on automation. They don't dig into our code or try to look "behind the curtain" as they're checking us. I think that's a good way to approach it, by and large. If they know the application internals well it can lead to blind spots, and besides, if they knew the application internals well I'd want to move them into development.
It's a bit awkward for us because our QA department is based halfway around the globe. We have our standups as early as possible and they've adjusted their working hours so there's a little overlap when we can talk to each other without a time lag.
We deploy every evening (our time) so they can start validating the latest resolved tickets in our issue tracker as soon as they clock in. If they find a problem, they'll create a new ticket or reopen an old one as appropriate. When we're gearing up to release, we'll deploy to a second environment that doesn't get automatic updates so they can run their automated regression suites against it without having to worry about timing.
Our testers have some facility with programming, but focus entirely on automation. They don't dig into our code or try to look "behind the curtain" as they're checking us. I think that's a good way to approach it, by and large. If they know the application internals well it can lead to blind spots, and besides, if they knew the application internals well I'd want to move them into development.
Interesting! The second environment is definitely key. And yeah, knowing what's in the "black box" could lead to bad tests too