|
Giving advice to developers can be tricky. You success in doing so depends on a lot of things, some of them most likely out of your control. Recognize that it's not enough that you know the right advice to give; your programming team also needs to want to hear it. More importantly, they'll need to what to hear it from you.
I point this out because I've worked in teams where the testers aren't seen as equals to the programmers. Their advice wouldn't have been welcomed. It wouldn't have mattered how good it was. I've also worked on teams where the testers shouldn't have given advice because they didn't know enough of the context, but they did anyway. In both of those cases, you can hurt more than you help.
That said, from here out I'll assume the best. You have a healthy team, you know the challenges and struggles the programming team is facing, and you're just looking for some places to start a conversation that will help everyone on the team down the road by reducing the regression issues that get found as new features get added.
As a tester, you should be able to carry some "street cred" when it comes to testing. So I'd recommend starting there. Try talking about the unit testing taking place. Talk about testability features you think may help the team with developing regression tests or that may help cut regression test cycle time in some other way. Look for projects that you could work on with the developers to help solve testing problems.
In the past, I've paired with programmers to extend unit tests they've already written. I've also had them pair with me to try to get some difficult test automation working. And I've sat down with them to design testability features like tools for data management, increased logging or alternative interfaces.
After testing, focus on design and the design process the team is following when they make their changes. As a tester, it's reasonable for you to ask to be involved there. You need to know for your testing, and most likely it's a place where you can contribute by asking questions and raising concerns. (Just don't become the tester who cried wolf.) Who's involved in designing the solutions? What peer reviews are they doing? Do they consult existing design artifacts and code or make assumptions?
After that, it starts to get more difficult to give advice. Unless you're a regular programmer, you don't want to give coding advice. You also want to be careful about advice around tools and individual processes. To give advice, it needs to be authentic. It can't just be some "best practice" you read online and talk about out of context. I've seen plenty of testing "best practices" I'd never do, and would rarely recommend. I suspect the same is true in programming, and unless you're a programmer you most likely won't know the good from the bad, or under what contexts something becomes good or bad.
Hope that helps, and good luck. Find the developers who seek the feedback you're offering and ask them how you can help. Most likely, they don't like the regression problems either. I'm sure they'd like to talk about what can be done to fix it, and would welcome your feedback if you're upfront about your goals and where you think you can help.
|
