Продолжаю писать "Байки для оруженосца".
Будет после принятия
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.