Is the course "Applyying Professional Scrum for Software Developers" suitable for QA Analysts
With topics such as pair programming and tdd I'm wondering whether sending my QAs on this course would be beneficial even though it says it would be suitable for "testers" is appropriate or whether a different course would be better. Any comments from people that have attended the course would be helpful.
Is it your intention that QAs recognize they are not a subrole, but are Developers and share in that accountability?
Our QAs are part of the scrum team, but their role is to assure quality through manual and automated testing. Pair programming and TDD would mean nothing to them because they are not writing program code and do not have the skills to do so.
Knowing more about Scrum is an advantage to any QA working in a Scrum Team. Scrum advocates for cross-functional teams, and not silos in separate Dev and QA. If the QA's don't know TDD who is writing the tests for TDD?
Are there better courses, I can't say, but if the developer focussed team members found the course valuable, then I am sure the QA focussed members will also benefit
I worked as a QA in a Scrum team, and knowing Scrum values and principles are valuable for a QA, actually a must I would say. QA's should take part in TDD and pair programming us a technique also beneficial to QA's, especially QA's working in automation.
QA's should absolutely know about Scrum, I'm just questioning the value of a training course that is geared more towards software developers than testers (based on TDD and pair programming being mentioned). TDD is about writing unit tests before the code (red-green-refactor), the software developers write those tests. It is true that some benefit, re pair programming and TDD, would be gained by those QA's writing automation tests.
I have a long background in QA. The course would probably be a good thing for them even if they don't understand everything. It could help them to get a better understanding of the work that the Developers do. It might also peak some interest from them in learning more about coding. The pair programming could come in by having a seasoned Developer pair with an interested QA. Also, even if the QA staff is not versed in development, they are versed in testing. They can transfer some of that knowledge to the Developers and make them better as well.
...their role is to assure quality through manual and automated testing.
Unless I am mistaken, automated testing is coding. So there could be benefit for them with the pair programming topic. I worked at an organization that adopted a variation of "paired programming" for manual testing. They would pair up together and do exploratory testing. Worked very effectively.
I'd suggest letting a couple of the QA go through the course and then let them discuss it with the rest of the QA group. Let the group decide if they want to do it as a team. If nothing else, the QA can use their empirical skills to self organize and make a decision. If that doesn't teach something about Scrum, then I don't know what will.