Продолжаю писать "Байки для оруженосца".
Key Testing Metrics
Before the talk, I highly recommend reading Goldratt’s books "Haystack Syndrome" and "Goal-1". The material is complex without a preliminary study of the base. On a three-point scale of complexity, this material is about five.
For seed, I’ll give a list of metrics that can be measured in principle. As the talk will show, this is the road to nowhere.
1. A number of bugs found.
- In general
- By time
- Only critical for the software functionality
2. The number of reports from the customer/client.
3. Time spent on testing of the next delivery.
4. The number of tests that were successful or not successful.
5. Percentage of code coverage (“What can I get from tracking this indicator?”).
6. Percentage of test coverage of requirements.
7. The number of software failures over a period of time.
8. The number of elements that the tester clicked (covered by manual testing).
9. The number of re-opened tasks for testing.
This list is more informational noise than information.
Будет после принятия
Pile of books on software development contains information that the requirements must be tested. And, according to statistics, more errors build into a product on the levels of creation and design of the requirements, than during the coding.
As soon as it comes to practice, very often the requirements just do not pass the proofread procedure (and sometimes do not read them). If it comes to a proofreading, it usually ends up by spelling and punctuation. And then the error gets to the end user.
Why? Many reasons are for this. The first - the psychology. Here "isn't thought up here" and different contexts of thought, and much more. The second - lack of the described verification techniques. There are a lot of literatures and courses, but there is no practically on the verification subject.
The topic will be considered at the workshop:
* Psychological barriers to verification;
* Verification techniques;
* Example of an use-case verification submitted by the participants of the uml2.ru community.
Preparation of the test strategy for high-risked and profitable project.
Business scenario to be considered:
- Innovative project.
- More than half of these projects failed.
- Success projects are bring millions a week. Not in rubles. Every extra week of development is a multi-million losses. Priority - speed.
- The error in the system, similar to that described in Russian here (http://goo.gl/xJfVcj), can make the company bankrupt in an hour.
In my report you will:
- See the generalized algorithm for constructing a testing strategy.
- See a look how to built the facet by facet of the strategy and how to improve the flow in concrete case.
- See the difference between strategy and non-strategy.
- Test Managers: they have to write and defend the testing strategy.
- Project managers: they have to coordinate the testing strategy with the general strategy of the development.
- Engeenirs: they have to understand and adopt the strategy.