Разделы портала

Онлайн-тренинги

.
Путевыводитель из царства иллюзий про тестирование ПО
11.04.2011 12:11

Джеральд Вайнберг является автором ряда признанных "классическими" книг, посвященных психологии и антропологии разработки программного обеспечения.

Его очередную книгу "Perfect Software and Other Illusions about Testing" внимательно прочитали Наталья Жданова и Алексей Лупан.

ЧЕГО ИМЕННО ВЫ ХОТИТЕ ОТ ТЕСТИРОВАНИЯ?

В одном из своих монологов Жванецкий рассказывал: "Я ведь как пишу?! Выйду в магазин, получу по морде вернусь домой, напишу ответ..."

Ладно еще, что Жванецкий сталкивался только с советскими продавщицами.

А что бы он написал, если бы его окружили менеджеры, которые отвечают за выпуск ПО, со своими извечными вопросами:

- Зачем нужно тестировать, если это только задерживает выпуск?
- Почему нельзя просто писать софт без ошибок?
- Там уже всё протестировано?
- Почему бы вам просто не взять и протестировать всё, что можно?
- Почему это ваше тестирование такое сложное?
- Почему вы тестируете так долго?

Это же не конкретные вопросы. Это вопросы о вечном, о мироздании, о сути создания ПО.

Джерри Вайнберг, в отличие от Михал Михалыча, ответить может сразу, но поскольку вопросам этим присуще появляться регулярно, он решил ответить сразу всем письменно.

И получилась книга.

Неспешная, "размышленческая" книга.

О многом думается после ее прочтения.

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

Но почему?

Чем занимается тестировщик?

В чём суть его работы?

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

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

Что может быть доходчивее денежного аргумента?

Тем не менее, опять-таки возникают нюансы:

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

2. Менеджмент - он ведь бывает плохим. Результаты плохого управления и организации не исправить на этапе тестирования, но можно найти козла отпущения...

Или аналогичную козу.

И отсюда следует другой поток поражающей глубины размышлений о том, НАСКОЛЬКО в разработке программ важен человеческий фактор, насколько функционирование этой сложной системы завязано на отношения между людьми, на взаимодействие между ними, на регулярный и свободный обмен информацией.

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

Вайнберг не стал копаться в глубинах подсознаний вопрошающих, а просто попытался ответить всем сразу самым простым и доступным языком - языком дополнительных вопросов. Вопросы приводят к соображениям. Соображения приводят к просветлению. Просветление приводит к...

Он прямо говорит о том, что основы тестирования - в психологии людской, в изучении нашего поведения, в работе мозга. "Наши решения эмоциональны, а не рациональны. Мы несовершенны, иррациональны, руководствуемся разными ценностями, и очень отличаемся друг от друга. Поэтому мы тестируем".

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

Тем, кто "не менеджер", книга просто вкладывает в руки внятные (нет, не ответы) соображения о том, как отвечать на заковыристые вопросы.

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

Люди, которые задают перечисленные во вступлении смешные вопросы, вовсе не глупы. Это же наши извечные вопросы.

Тот, кто поймет, почему эти вопросы появляются, получит нобелевскую премию из рук самого Будды.

Простые ответы на эти вопросы есть, но удовлетворят они... почти никого, бо требуют предварительного просветления.

Например, сентенция о том, что "Humans are not perfect thinkers. If your thinking were perfect, you would not need testing"
непосредственно отвечает на вопрос "Зачем надо тестировать?"

Достаточна ли она в качестве ответа?

Местами рассуждения Вайнберга сугубо юмористические, и выдают его богатый рабочий опыт:  "Вы идете к менеджеру, который ответственен за выпуск, и спрашиваете "Как там дела, скоро ли будет готово?" А он отвечает: "Не знаю".  Что вам следует делать, чтобы получить от менеджера более внятный ответ? Может быть, пытки помогут?"

Или зарисовка "из жизни консультанта":

- Вы по спецификациям тестировали?

- Разумеется.

- Можно на них посмотреть?

- Конечно, можно... Только мы не знаем, куда они подевались...

- Давно вы их потеряли?

- Уже никто не помнит.

- Мгм. Ну, а заново их получить можно?

- Можно. Это займет около месяца.

В общем, представляем себя ответственными за выпуск очередного ПО в высший свет, и приступаем к чтению.

Каждая глава завершается списком "Common Mistakes" с краткими толкованиями. Мы же любим краткие толкования?

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

* Рабкрин - рабоче-крестьянская инспекция, действовала в советском государстве с февраля 1920 г. по февраль 1934 г. Отличалась тем, что ничего не сведующие в том или ином деле люди оценивали с точки зрения государственной важности качество работы отдельных лиц или предприятий, и все-таки выносили оценочные суждения о качестве и полезности труда инспектируемых подразделений. К тестированию имеет опосредованное отношение :)

Книга искренне рекомендована не только тестировщикам, но и менеджерам проектов и/или тимлидам, которые:
а) знают английский язык, бо её перевода фиг дождешься,
б) хотят получить ясное и четкое понимание грамотной (и потому - более безопасной) организации процесса разработки ПО на всех стадиях, сэкономить нервы, силы и время всей команды. И может быть, также получится организовать здоровую и продуктивную атмосферу в своей организации?!

ИНТЕРЕСНЫЕ ФАКТЫ

Известный и бородатый Джеймс Бах упомянут на страницах этой книги сто раз.

Или двести.

ЦИТАТЫ

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

Тестирование сводит менеджеров с ума.

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

Тестирование может быть одним из способов получения информации, которая может снизить определенные риски. А оценка рисков - очень субъективное дело.

Уровень погружения в тестирование можно определять на основе рисков.

Незачем спрашивать у тестировщика, готово ли ПО к выпуску. Принимать решение о выпуске - это работа менеджера. Работа тестировщика - снабжать информацией, достаточной для принятия такого решения.

Тестирование никак не улучшает продукт, этим занимаются люди, которые исправляют дефекты.

Когда менеджеры говорят "Тестирование занимает слишком много времени", они подразумевают "Исправление дефектов займет слишком много времени".

Testing cannot be done in zero time and cannot be done for free.

Testing is not fixing.

Чего именно вы хотите от тестирования? Выпустить успешный продукт, или избежать судебного преследования, или просто продвинуться по карьерной лестнице?

Иногда тестировщики не генерируют кучи отчетов, и вы становитесь жертвой несоответствия качества информации ее количеству. Будьте внимательны, иногда отсутствие информации и есть самая важная информация.

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

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

"Тестирование может доказать наличие дефектов, но не может доказать их отсутствие" - цитата из работ Дейкстры.

Ограничение по времени - это эвристический принцип, а не жесткое правило.

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

Ошибочно думать, что вся необходимая для принятия решения информация находится в отчетах о тестировании.