Вот как обычно происходит создание отдела тестирования? Есть “контора”, “контора - пишет”, причем в прямом смысле, пишет код. Контора маленькая, программа – маленькая, требования все три с половиной программиста знают и так, то есть не фиксируют. Заказчик один, он продукт получает, платит сколько то денег. Главный находит еще и еще клиентов, нанимает еще программистов… Коммуникации между программистами неизбежно ухудшаются, хотя бы просто в силу увеличения команды. Требования и баги от клиентов превращаются в бесконечный поток, и программисты в первую очередь пытаются избавиться от непродуктивной работы, то есть – от тестирования. И тогда на сайтах с работой появляются объявления – требуется тестировщик.
Приходит тестировщик, и начинает писать… А вот что? Часто от тестировщика требуют написать “процесс”. Или регламент. Или сразу внедрить автоматизацию. Или начать тестировать и писать тесты. Требуют отчетов и планов. Голова идет кругом, работы непочатый край, и за что не возьмись – срок непредсказуем. Начальство теребит – когда?
Моё искреннее убеждение, основанное на личном опыте – всё это потом. Потом тесты, потом планы, потом процессы. Главное и первоочередное – список фич. Даже просто составив этот список, нужно прийти к главному и попросить расставить приоритеты. Это даст вам представление о том, в какую сторону копать. От саппорта вы по этому списку узнаете на что больше всего жалуются заказчики, где гнездовища багов.
Список фич хорош тем, что он конечен. Список требований или список тестов – очень непредсказуемые по объему документы. А список фич – нет. Пишите его как вам удобно, тестлинк мне показался самым удобным из бесплатных, хотя для этого не сильно приспособлен, да и сырой он как тряпка под дождём. Я задумываюсь написать собственный инструмент для ведения списка, ибо навыки необходимые есть, и задача не кажется слишком сложной. Останавливает только то, что потом захочется туда приклеить и требования, и тесты, и баги, и прогоны по ревизиям, и построение отчетов. И получится какой то аналог какого ни будь платного продукта, причем заведомо худшего качества.
Но это я отвлекся. Программу на фичи дробить следует по своему усмотрению. Основным критерием я избирал такой показатель как тестируемость. Если я нечто могу протестировать и сказать – вот, это работает – я объявлял это фичей. Разногласий с программистами здесь как правило не возникает. Есть, например, отчеты, 20 штук. Отчеты объявляются фичей, и каждый отчет тоже объявляется фичей. В отчёте есть графическая и табличная части? Ещё две фичи. Древовидная структура становится очень удобным способом представления списка.
На сегодня всё. Пора дочку спать укладывать.
2 комментария:
Это фича и это фича. Напомнило "Кин-дза-дза" - Ку! Три раза ку! =)
Я когда стал разбираться в своём проекте, получилась такая вложенность, что от подподподподфич уже рябило в глазах и подсчитать глубину по этим "под" стало невозможно. Поэтому - КУ!
Вот предыдущий комментарий от анонимуса почему то не опубликовался... Я на него ответ готовил.
Отправить комментарий