Отправляет email-рассылки с помощью сервиса Sendsay

Записки бизнес аналитика

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "О карьере и профессиональном развитии IT-специалистов" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Октябрь 2003   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор sla***@p*****.ua

Статистика

2.701 подписчиков
+9 за неделю
←   Все выпуски   →

Записки тестировщика


Информационный Канал Subscribe.Ru
Записки тестировщика // выпуск 2 // 2003-10-27

немного о покупке тулов.
о том как важно верно выбрать средство автоматизации тестирования написано много. даже я вот стараюсь отличится на сим достойном поприще.

я хочу поговорить немного о другом. об источнике инициативы. о тех людях в компании, которые инициируют приобретение средств автоматизации тестирования.

если инициатива выбрать и купить средство автоматизации тестирования исходит из отдела разработки (или любого другого подразделения, которое занимается непосредственно тестированием) особых проблем нет. вы уже умеете проводить все типы тестов вручную. включая нагрузочные, между прочим. тестируете с привлечением одного или даже нескольких скриптовых языков. у вас есть поставленный процесс ручного тестирования. сценарии использования, тестовые планы, чеклисты, словом процесс идёт и отдел выпускает проекты в жизнь. осталось дело за малым, хочется работать на несколько ином уровне. хочется автоматизировать рутину, чтобы не тратить время на однотипные задачи. кажется, что есть силы на переход к следующей ступени системы зрелости процесса разработки в целом и тестирования как его аспекта. что ж, пока искать средство автоматизации. искать средства на его приобретение и обучение работе с ним. словом проблемы обозначаются довольно ясно.

если же инициатива приобрести средство тестирования исходит из стройных рядов менеджеров? или, скажем, отдел разработки становится в позу и заявляет, что динамика тестирования недостаточна, для динамически растущего и развивающегося процесса разработки. второй вариант, конечно, встречается реже: разработчики и тестировщики обычно работают по одну сторону баррикады разработка-менеджмент, но бывает в этой жизни и такое.

одним словом инициатива внедрить средство автоматизации тестирования исходит из вне системы тестирования. что за этим стоит?

с менеджерами более или менее понятно, кому-то попался на глаза пресс-релиз компании разработчика таких средств: золотые горы в результате сокращения времени на тестирование, минимальные усилия, лёгкость процесса обучения и так далее, одним словом реклама. рождается мысль быстро перерастающая в доклад начальству: “мы купим инструмент и тестеры нам быстро всё протестируют”, “зачем нам отдел из 3 тестировщиков? мы купим тул и покроем затраты за счёт зарплаты за полгода”. иногда правда добавляется нечто, что должно вроде как говорить в защиту интересов самих тестеров: “ну ведь у программистов вон какая студия есть!” или “что же мы по старинке-то всё, когда в мире уже...”, ну и так далее. мотивация отдела разработки или попросту программистов уже обозначена: тестировщики за нами не поспевают.

есть такая проверенная практикой вещь: “на разработку и внедрение системы автоматизированного тестирования уходит от 7 до 15 (!) раз больше времени. чем на построение аналогичной системы ручного тестирования”. вот это нужно просто знать.

чувствуете чем пахнет? нехороший запах. палёный.

что же делать? если инициатива исходит от менеджера, чья работа заключается в продажах и не затрагивает процесса разработки, то его мнение можно просто засунуть... проигнорировать. идти к руководству, которому уже проспамили все уши и объясняться. мотивировать и так далее. очень рекомендуется мотивировать обосновано, 5-10 независимых источников, особенно на ресурсы самих адептов автоматизированного тестирования обычно приводят в норму любое заблудшее мнение. потому как времени нет. кроме того в компаниях, где процесс разработки налажен, менеджеру со стороны в него вмешаться будет нелегко, хотя и возможно. это не критичная ситуация.

с программистами интереснее: давайте я подойду к программистам и предложу им новое средство разработки, мотивируя это тем, что сократятся сроки разработки, а то мол тестировщики простаивают. пошлют? пошлют. так почему эта мотивация применима ровно в обратную сторону? не может ли быть, что под отдел тестирования просто закапывают проблемы, пытаясь спихнуть ответственность за сроки? стоит подумать. в целом ситуация тоже не перерастет в проблему, если вовремя расставить акценты.

а если инициатива исходит от менеджера проекта? или руководства компании в лице достаточно подкованного технически руководителя? такая ситуация может встречаться в небольших молодых компаниях, которые возглавляются человеком, который является одновременно и проектным менеджером. инициатива понятна. есть желание повысить качество продукта и сократить сроки выхода продукта. правило умножения на 15 никто не отменял, но о нём скорее всего просто не знают. кроме того скорее всего процесс тестирования в компании ещё не вышел на тот уровень, когда автоматизация просто необходима и логична на 100%. в таком случае стоит пожалуй делать первые, сбалансированные шаги в сторону внедрения средств автоматизации. удивлены? рационализм в сторону? попробуем разобраться.

в этой ситуации сломить неверное представление об эффективности не так просто. этих представлений просто нет. логика доводов потонет в тумане неопределенности постановки. есть скорее всего желание повысить качество и некое подозрение, что так лихо это не выйдет. будем на этом играть, раз идея блага. попытаемся представить средство автоматизации как инструмент разработки для тестировщика. средство, использование которого не есть самоцель, не есть возможность достижения оперативных задач, но может существенно облегчить повседневный труд. вариант? реальный вариант. компромиссное решение, которое с одной стороны не создаст отделу тестирования славу ретроградов, с другой стороны даст реальную возможность внедрить технологию автоматизации исходя от потребностей тестировщика, а не от стратегических задач компании. в конце концов тестеры ведь тоже любят эти модные игрушки, так ведь?

то есть в этом варианте развития событий (и только в этом — я верю в пм-ов! в противном случае мы вежливо улыбаемся и советуем заниматься своими делами, тактика дальнего боя в чистом виде) ответ “да”. но! сбалансированное внедрение. использование от потребностей — мы к этому всё равно придём. но ведь лучше идти при поддержке всей команды и её рулевого, чем по прихоти менеджера отдела продаж, который просто обедает с главой фирмы? логично?
по-моему да.
25/10/2003

С уважением, Панкратов Вячеслав. Записки тестировщика.
http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное