среда, 23 марта 2011 г.

Стратигия, План, Методика

Я противник написания документов ради документов, и чем дальше, тем более рьяный. В компании из трех программистов и полутора тестировщиков не нужны никакие глобально написанные "стратегии". Зачастую вся стратегия укладывается в двух словах, понятных всем - тестим отчеты, сдать в конце недели! К черту нагрузочные, функционал только в отношении отчетов. Вот и вся стратегия, что вам еще нужно? План выглядит ровно также. Это просто список тестов, которые вы собираетесь провести. В мелкой компании План тестирования - оглавление методики, а стратегия - введение перед списком тестов. И то, если есть желание ее писать. Читать это все равно некогда.

Однако, тесты писать - надо. Вопрос в подробности написания. Нужно ли расписывать все до точки или достаточно названия теста? Я задаю себе этот вопрос по другому. Кто будет это читать? Если читать никто не будет, незачем и писать. Ну не придут ко мне тестиовщики из детского сада, что бы я всё дотошно и подробно расписывал. И штат в 10 раз внезапно не увеличится. Да пока я все напишу программеры успеют пять раз все поменять. То что я напишу, буду читать в первую очередь я, мои коллеги, которые и так в курсе как это проверять, и программеры, которые при нахождении бага прибегут и будут пытать "А что вы тут делали что бы оно вот так вот....?" Многие тесты сокращаются в одну строчку и из них получается чеклист.


3 комментария:

Unknown комментирует...

А представте что у Вас Очень большой проект, который вы ведёте уже не один год и всяких модулей/дополнений написанных за этот период несметное множество. Скажите честно, вы сможете вспомнить все нюансы связанные с сопряжением некоторых элементов, если последний раз Вы тестировали этот кусок один/два/N месяцев/лет назад? Я думаю, навряд ли. И вот в такие моменты Сценарии тестирования, Планы проекта, Обобщённые описания ой как нужны.

ua9msn комментирует...

У меня именно такой проект. Ему лет 10 и модулей там общим числом за 50. Я не говорю, что писать не нужно. Нужно. Но только то что нужно. К тому же, я говорю о маленькой компании. Не стоит бездумно применять это на всех. В определенных ситуациях даже маленький проект требует большой внутренней документации. Например если часть работ на аутсорсе или штат программистов за сотню, проще один раз написать, организовать базу знаний, чем вновь и вновь рассказывать одно и то же.

Unknown комментирует...

значит мы говорим об одном и том же, только разными словами)

Отправить комментарий