The KDE Quality Team is designed to, amongst other things, manage the release tesing for KDE and move towards having a structured approach rather than just releasing some code, and seeing what happens.
This means keeping clear instructions on how to install the latest betas, promoting testing and trying to do the testing more effectively.
If you have refactored a large area of code, or introduced a new feature, please add it to the to-test list (http://community.kde.org/Getinvolved/Quality/Beta/4.10/AreasToTest) along with instructions of how to get to test it. Use end-user terminology, and keep things deliberately vague to encourage users to spot bugs in areas that you (as a developer) haven't thought about.
Be on top of the bugzilla lists. KDE only works if all developers are on top of triaging their own products, confirming bugs, closing duplicates and invalid bugs and of course, fixing them :)
Make sure our wiki page of "how to get the latest beta" (http://community.kde.org/Getinvolved/Quality/Beta/4.10/Installing) is up to date with clear instructions. A link to the relevant release page is enough. It's a wiki for a reason, edit away :)
You may have noticed we're running a bit behind this release. We really need to step it up, both now and for future releases. It's a new-ish team, and I've ended up being ridiculously busy.
We have a number of ways to get involved in the managing side of KDE Quality:
It's a real work in progress, but we're already showing real results both in terms of bugs reported, and bugs fixed.
Join our mailing list [https://mail.kde.org/mailman/listinfo/kde-testing] or find us in #kde-quality.