Comments on: Stop waiting to the end of the project to start QA!!! (And other QA principles) http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/ Fri, 03 Feb 2012 13:13:38 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: O melhor da semana 02/05 a 08/05 « QualidadeBR http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/comment-page-1/#comment-7320 O melhor da semana 02/05 a 08/05 « QualidadeBR Sun, 09 May 2010 21:35:10 +0000 http://www.makinggoodsoftware.com/?p=1305#comment-7320 [...] Stop waiting to the end of the project to start QA!!! (And other QA principles) – Alberto Gutierrez (Making Good Software); [...] [...] Stop waiting to the end of the project to start QA!!! (And other QA principles) – Alberto Gutierrez (Making Good Software); [...]

]]> By: Raymond Li http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/comment-page-1/#comment-7209 Raymond Li Thu, 06 May 2010 13:36:14 +0000 http://www.makinggoodsoftware.com/?p=1305#comment-7209 I like your principles. Like some of the other comments have addressed, the 5th tip needs to be qualified. A developer obviously knows their code intimately and probably knows about certain issues that may come up. However, it's difficult to change perspective from designing and building software you are proud of... to trying to break the software that you wrote. It's along the same lines of why a writer needs an editor or proofreader... I like your principles. Like some of the other comments have addressed, the 5th tip needs to be qualified.

A developer obviously knows their code intimately and probably knows about certain issues that may come up. However, it’s difficult to change perspective from designing and building software you are proud of… to trying to break the software that you wrote.

It’s along the same lines of why a writer needs an editor or proofreader…

]]> By: Mark Rebec http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/comment-page-1/#comment-7158 Mark Rebec Wed, 05 May 2010 00:21:37 +0000 http://www.makinggoodsoftware.com/?p=1305#comment-7158 #4 should actually be #1. People don't give enough credit to QA, and because of that not enough talented individuals are driven to the position. #5 is flat out rubbish. As one of the other comments noted, a developer should *absolutely* test their own code as their developing it (duh), but it should be passed off to a QA team for final testing. When you build something to a certain spec, you tend to verify functionality within that spec, but you're often so immersed in the spec and the building of the feature/functionality that you forget to see what happens when certain actions outside that spec are performed. That's where QA comes in and runs through a standard suite of tests (both automated and human) and basically just tries beating on random things with a baseball bat. A developer is simply not going to find all the more random and obscure bugs within their own code. It should be noted, however, that once something has been identified, the developer is of course very likely to have an "Oh! I know what that is" moment. #3 is also not entirely accurate in my opinion. If you've got a QA team and a team of developers constantly interacting with one another, it's likely close to nothing will get done. At the end of a project it makes sense to work closely with a lot of back and forth, when wrapping up final small bugs, design tweaks, etc. However, earlier on in the QA process, while there is still active development going on and larger functional bugs to be fixed, the developers quite frankly "need their space" and they need time to focus on these somewhat larger tasks. If the QA team is constantly bombarding them with new tickets, questions, etc. it can become difficult to focus. Finally, that brings me to the main point of the article. It should be clarified that (at least I hope this is what the author meant) while QA should not wait until the very end of the project, it should also not start too early. If you have a QA team pounding away at a half-finished product, they're almost guaranteed to start reporting "bugs" which in reality are simply features which aren't finished yet or something a developer is not only aware of, but actively working on as part of the ongoing or earlier stages of development. #4 should actually be #1. People don’t give enough credit to QA, and because of that not enough talented individuals are driven to the position.

#5 is flat out rubbish. As one of the other comments noted, a developer should *absolutely* test their own code as their developing it (duh), but it should be passed off to a QA team for final testing.

When you build something to a certain spec, you tend to verify functionality within that spec, but you’re often so immersed in the spec and the building of the feature/functionality that you forget to see what happens when certain actions outside that spec are performed. That’s where QA comes in and runs through a standard suite of tests (both automated and human) and basically just tries beating on random things with a baseball bat. A developer is simply not going to find all the more random and obscure bugs within their own code.

It should be noted, however, that once something has been identified, the developer is of course very likely to have an “Oh! I know what that is” moment.

#3 is also not entirely accurate in my opinion. If you’ve got a QA team and a team of developers constantly interacting with one another, it’s likely close to nothing will get done. At the end of a project it makes sense to work closely with a lot of back and forth, when wrapping up final small bugs, design tweaks, etc. However, earlier on in the QA process, while there is still active development going on and larger functional bugs to be fixed, the developers quite frankly “need their space” and they need time to focus on these somewhat larger tasks. If the QA team is constantly bombarding them with new tickets, questions, etc. it can become difficult to focus.

Finally, that brings me to the main point of the article. It should be clarified that (at least I hope this is what the author meant) while QA should not wait until the very end of the project, it should also not start too early. If you have a QA team pounding away at a half-finished product, they’re almost guaranteed to start reporting “bugs” which in reality are simply features which aren’t finished yet or something a developer is not only aware of, but actively working on as part of the ongoing or earlier stages of development.

]]> By: loiane http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/comment-page-1/#comment-7145 loiane Tue, 04 May 2010 16:51:12 +0000 http://www.makinggoodsoftware.com/?p=1305#comment-7145 Great tips, though I don't agree much with the fifth one. Of course you have to test what you've developed, but you are not the best person to do it as a final test. Sometimes you are very used to the code and can miss some scenarios. That's why I think it is important to test your own code, but it is best if someone else test it to give you a second opinion. Great tips, though I don’t agree much with the fifth one. Of course you have to test what you’ve developed, but you are not the best person to do it as a final test. Sometimes you are very used to the code and can miss some scenarios. That’s why I think it is important to test your own code, but it is best if someone else test it to give you a second opinion.

]]> By: Fabrice Aimetti http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/comment-page-1/#comment-7109 Fabrice Aimetti Mon, 03 May 2010 11:02:03 +0000 http://www.makinggoodsoftware.com/?p=1305#comment-7109 Hi Alberto, I've translated in french your excellent post : <a href="http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/05/03/Cessez-d-attendre-la-fin-du-projet-pour-commencer-la-recette-technique" rel="nofollow">Cessez d'attendre la fin du projet pour commencer la recette technique</a> Regards, Fabrice Hi Alberto,
I’ve translated in french your excellent post : Cessez d’attendre la fin du projet pour commencer la recette technique
Regards, Fabrice

]]> By: hlegius http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/comment-page-1/#comment-7108 hlegius Mon, 03 May 2010 10:29:11 +0000 http://www.makinggoodsoftware.com/?p=1305#comment-7108 Your fifth tip is the best one ! Many developers thinks that Tester and Developer must be two different people in two different area. I believe that the best person to test some routine is the one who create them. Your fifth tip is the best one !
Many developers thinks that Tester and Developer must be two different people in two different area.

I believe that the best person to test some routine is the one who create them.

]]> By: Tweets that mention Stop waiting to the end of the project to start QA!!! (And other QA principles) | Making Good Software -- Topsy.com http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/comment-page-1/#comment-7105 Tweets that mention Stop waiting to the end of the project to start QA!!! (And other QA principles) | Making Good Software -- Topsy.com Mon, 03 May 2010 09:40:30 +0000 http://www.makinggoodsoftware.com/?p=1305#comment-7105 [...] This post was mentioned on Twitter by Rui Curado, Manuel. Manuel said: GR> Stop waiting to the end of the project to start QA!!! (And other QA principles): Many project managers conside... http://bit.ly/bV6Kcu [...] [...] This post was mentioned on Twitter by Rui Curado, Manuel. Manuel said: GR> Stop waiting to the end of the project to start QA!!! (And other QA principles): Many project managers conside… http://bit.ly/bV6Kcu [...]

]]>