Software Best Practices

Hey guys, thanks for setting up this forum. 

The general question that I am trying to answer is, for a small team (less then 6 developers), is there a need for a dedicated position to ensure quality?

Currently, our team is (trying to) following scrum for product development, and spending the final 3 days of our 2 week iteration in a dedicated quality assurance mode.  I have been searching for resources online to help me answer the above question, but have not been very successful in finding answers that satisfy me.  Specifically I would like to hear answers from people who have asked this same question and how they are assuring quality in their products, to these questions:

• Are testers required?  (I know Joel's answer)
  
• Should testing occur as development is occurring or should it only be done on a completed iteration?
• If testers are required, should they be doing unit testing or only integration and regression testing?
  
• If developers are not performing the testing, should development stop while testing is going on, waiting for bugs to be identified so that they can provide fixes as quickly as possible?
• If testers are required, what is the best use of a tester's time while development is going on? 
  

Thanks in advance for any responses!

 Ben

beebe4:

The general question that I am trying to answer is, for a small team (less then 6 developers), is there a need for a dedicated position to ensure quality?

• No - you can't afford it.
• Yes - make EVERYONE in your team dedicated to quality.

beebe4:

Should testing occur as development is occurring or should it only be done on a completed iteration?

If your following scrumm how about trying test driven development at the same time. So testing occurs before you implement any working code. That means writing tests and getting them to fail properly first. Then implement the code so that you start getting the tests to pass.

beebe4:

If developers are not performing the testing, should development stop while testing is going on, waiting for bugs to be identified so that they can provide fixes as quickly as possible?

 If a developer isn't developing what are they doing? Get them doing the testing, possibly testing other team members  code. 

 Basically don't fall into the trap of thinking that testing and development are separate activities. They aren't. Also late testing is a REALLY bad and expensive way of finding defects. Do your test development early and make it a fundamental part of the development process.

David Harper:

If your following scrum how about trying test driven development at the same time. So testing occurs before you implement any working code. That means writing tests and getting them to fail properly first. Then implement the code so that you start getting the tests to pass.

We are enforcing TDD this iteration after a hiatus from it, but I guess my mental block is on acceptance testing... is running your suite of tests enough before releasing it to the world? 

How much manual verification needs to be done? 

Or is developing software always going to boil down to the product manager drawing the line, sticking his neck out there and saying, "Here ya go world, this is our best offering.  Enjoy!"

beebe4:

but I guess my mental block is on acceptance testing... is running your suite of tests enough before releasing it to the world? 

Almost certainly no. What does your software do? Should you consider running beta tests with real users etc? Will they find ways of using it that you hadn't though of which could have unforseen consequences?

Does your software implement a protocol? If so have you gone to various plug fests and done interoperability testing? Sometimes it's not your software you have to worry about but the real world software that it interacts with. My experience of designing and implementing the HTTP framework for Symbian OS is that  the real world is always going to throw up challenges that you hadn't forseen.

I think you can analyze quality control from a broader perspective. Defects can be removed all along the development cycle. The question is what activities are adequate in your context to remove defects. You can peer review your requirements, design and code. You can perform unit test, apply TDD and/or design integration and system test cases and execute them in a formal testing phase after all code is completed. You need to analyze all the picture.

From this perspective, everyone could be involved constatly in quality control. Now, if the question is "Should someone be fully assigned to verify formally all the implemented functionality?" my answer is yes. In my organization no matter how many people are working on a project. All the implemented requirements must be formally tested. There are 1-person projects where this rule applies, and we have good results so far.

# Are testers required?  (I know Joel's answer)

In my opinion, yes

# Should testing occur as development is occurring or should it only be done on a completed iteration?

As you prefer. Test results are feedback about your code. I prefer this feedback sooner than later.

# If testers are required, should they be doing unit testing or only integration and regression testing?

A common approach is to assign unit testing activities to developers and ntegration, regression and system testing to testers. But it depends on your context. Anyhow, I consider that someone different from the author of the code provides great value in the verification of the functionality.


# If developers are not performing the testing, should development stop while testing is going on, waiting for bugs to be identified so that they can provide fixes as quickly as possible?

Sometimes we assign some people to fix bugs and the rest continues with the following functionality. Sometimes all the people is needed to fix bugs. It depends on the severity of the issues and other factors.

# If testers are required, what is the best use of a tester's time while development is going on?  

Analyze the functionality, define tools, identify as many scenarios to test as possible, design test cases and automate them, plan the test cycles. All these activities are required if you don't want to end with and ad-hoc verification phase where the testers just play around with the software without boundaries, goals or sense of progress/coverage.

Hope this helps