How can a developer that joins a QA team give the help that has the biggest impact and which are the best assignments for him that would most benefit the team?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Eduard, welcome to SQA. I will assume you are that developer.
I think there are a lot of ways a developer can help a QA team. The most obvious way to help would be to write automated tests or to write tools that make testing easier, e.g. creating test data or automating a deployment.
You may have skills outside of coding that would also benefit your team. For example, if you are good at writing, you might be able to write test plans in a better way than your team does now. Having insight into how software is put together gives you a different perspective on how to test.
Of course, you asked how to have the most impact. I cannot answer that because I do not work for your company or on your team. If I were you, I would spend some time talking to people about what it's like to test right now: what works, what doesn't, what's easy to test, what's hard or time-consuming. I would look for trends in your bug tracking system, too. You might also talk to the developers about those things.
On top of all that, you may need to live the life of a tester for a few weeks or months. I am confident that after a few months you will have a number of good ideas about how to have a big impact on testing.
A developer can be also useful to QA team in defect isolation.
Having skills to read the code, understand the architecture of the system and debug a running program, you will be able to isolate the root cause of the defect you or the rest of your QA team has found. It is often faster to reproduce and isolate the issue, when you are performing the tests and you have access to the test environment. Imagine that the person that is going to fix the defect, may need to isolate the defect herself. She will need to setup test environment herself, or get access to it. This requires a knowledge, that developers working on single components often do not have. Why is so?
It's because developers who build application are highly specialized in single components. In extreme cases they are "narrow-minded": their job is to make sure the software works on the unit level. On the other side, testers may have wider view on the system, may know the problems of components that your team has not developed, may know the challenges at integration points and know external systems better.
@user246 has some good options - the first that came to mind for me as well was the creation of automation and support tools. I think that another area where many test teams that I've been on could benefit is from having a deeper understanding of the system architecture and technologies. A developer has a different perspective on the system - they have more technical knowledge and/or experience that can give them the ability to better understand the technical risks inherent in the system. Maybe there are areas of the code that work for unknown reasons - a developer may be able to identify those more easily. Maybe there are certain technical interactions that are riskier. If the developer has already worked with the developers still working on building the system or has participated in code reviews with the other developers, the dev in test might even be able to give some pointers like "Oh, Joey wrote that code. He tends to forget to free up his pointers when he's done with them, so be sure to run tests for memory leaks on it." Sometimes, even just being able to explain the technical aspects of the system to a tester can help them see additional test cases.
This isn't going to necessarily work for every tester - some testers or test cases need to not have technical details to achieve their goals. It's also not something that requires a developer to do - a technical tester could fill the role as well. However, I think it's a big area where a developer assigned to a test team can help in addition to creating code for tests and tools.