Almost all successfully SCRUM practice on software development has different degree of tests (unit-test, integration tests) as a part of definition of done. Is there any research about how these successfully SCRUM spent on time testing activity?
There is nothing about Scrum (not SCRUM) that specifies or would even affect how much testing you need or should have. Scrum is a project framework, but it is up to the product owner in consultation with key members of the team to determine how much, how robust, and what kinds of testing are needed.
This is really a fundamental question of software development as it applies to your project(s), not one related to any certain methodology.
Now, Agile principles can help you make these decisions. I might suggest that:
- Since you value working software, test as much as you need to deliver working software (and no more).
- Since you value individuals and interactions, the team should self-organize to respond to the business need for quality software; the team should come up with testing standards, accountability, and other practices to ensure quality. The team can also develop unit testing standards in ways that are mutually useful for all on the team to develop efficiently, with a preference toward a short code-test-debug cycle time.
- Since you value customer collaboration, make it the product owner's responsibility to make testing a higher priority and to push for stronger testing; the product owner should insist on lots of help from key team members to figure this out.
- Since you value responding to change and an iterative approach, consider becoming "one step better" in your testing at any given iteration. Often, many steps of intentional team-wide change add up more quickly and more effectively than a big-bang let's-all-become-more-mature effort.
To the best of my knowledge, there is no such research. There is, however, lots of experience in that field. Like, for example, this great SERadio-interview with Lisa Crispin about Agile Testing or this Interview with Kent Beck about JUnit (less immediate, but he talks about the tester-hat of developers).
The message certainly is that you need to spend enough time on testing, for you to be confident that your product works. There is no way of telling how much that actually is, since it greatly depends on the problem at hand and your experience (both as a programmer and as a tester). It also depends on whether you are working on a new project or on some legacy code.
You should do so much testing during the development phase of the product which should drop down the product related servicing rate after product release/deployment and try to find the sweetspot of your "test-service time invesment rate" bell curve.
What I mean is,
Spending 10 hours of testing time in the x hours total project time is NOT good practice if the servicing time you spend after release is NOT dropping down in a satisfactory rate
Spending 100 hours of testing time in the x hours total project time is a good practice if the servicing time you spend after release is dropping down in a satisfactory rate
Spending 250 hours of testing time in the x hours total project time is NOT good practice if the servicing time you spend after release is NOT dropping down in a satisfactory rate
The sweetspot in this scenario is near 100 hours or a certain percentage of testing time invesment. You shouldn't spend less or more time in the total development stage for testing of similar projects.
This kind of data can only be accumulated in the long run of a company's product lifecycle.
Scrum do not define testing time frame or scope for a feature or a PBI. It is the Scope of the newly implemented feature that helps in identifying the Scope of testing. Say a new feature is to be implemented for an application. The feature should have a "Definition of Done" and the Product Owner should define this. It would in turn help the team to analyse the feature and develop it.
Based on the experience of the team, the scope of testing could be defined. The parameters that should be considered for it could be:
- End User environment, this includes network Speed, OS used and the machine configuration.
- Complexity of the implemented feature for DEV
- The business value of the feature and its criticality.
- Lines of code written for the feature would also help. The more the lines the more it would be vulnerable to errors.