Представим себе стандартную, обыденную ситуацию. В компании N нет тестировщиков, и очень некачественный софт. Сроки регулярно срываются, заказчикам поставляются нерабочие продукты, менеджеры бегают в непрерывных попытках тушения пожаров. И тут, кому-то в голову приходит гениальная мысль: «А давайте организуем отдел тестирования! Все наши проблемы как рукой снимет!».
И организуют. И приходят они — рыцари в тёмных плащах. И начинают ломать продукт, и начинают заводить баги, и начинают критиковать требования.
А продукты как выпускались в отвратительном качестве и со срывом сроков, так и выпускаются…
И почему, спрашивается?
А потому что тестировщики не могут победить мировое зло, не могут сдвинуть гору и побороть Чака Норриса. Тестировщики не всемогущи, они не могут решить ЧУЖИЕ проблемы.
Обидно, да? В нашем социуме есть миф о всевозможности, «главное только захотеть». И что, много мечтавших уже в космос слетали?
1. Тестирование не поможет проекту, если бардак с требованиями
-У нас проблема, в интерфейсе всё разъехалось
- Это не проблема, это наш новый интерфейс
- Мммм… А давно?
- Да не, я только на прошлой неделе сказал дизайнерам переделать!
Знакомо? Отсутствие документации требований чаще всего не проблема. Их можно документировать и согласовывать самим, их можно выяснять. Но если они меняются спонтанно, а информация теряется, то ни один тестировщик не сможет поддерживать тестовые артефакты, своевременно находить баги, и уж тем более читать мысли о необходимости проверить новую фичу. О которой он ни слухом ни духом.
2. Тестирование бесполезно*, если проводится в последний момент.
- У нас есть ещё полгода на написание продукта. 5,5 месяцев будем разрабатывать, за 2 недели протестим — и клиенту!
Ха-ха! За последние 2 недели окажется, что продукт неработоспособен, сделано не то, что ожидалось, в продукте архитектурные проблемы, исправление которых займёт почти те же полгода. Всё, спасибо, ваша попытка релиза оказалась прототипом. И либо мы опять релизим отстой, либо срываем сроки.
3. Тестирование бессмысленно без культуры качества в компании
- Ну завели они эти триста багов, и что? Все сущие мелочи!
И не надо потом удивляться, что клиент не доволен, отзывы негативные, репутация испорчена. Пользователям нужны «эти удобные милые кнопочки»*, а не технологии! В одной компании я из версии к версии сталкивалась с одной и той же ситуацией.
Маркетологи, сейлзы: по отзывам пользователей, их больше всего беспокоят две проблемы: низкая производительность и неудобство использования
РМ: Срочно тестируем производительность и юзабилити!
Тестировщики: Пожалуйста, вот 200 багов
РМ: А, это всё мелочи, это до следующей версии подождёт
И к следующей версии маркетологи и сейлзы говорили то же самое, что вполне ожидаемо…
4. Тестирование очень сильно осложняется нехваткой информации
- Сейчас я занят. Я позже расскажу, покажу, всё сделаю. Но пока что не до этого. Вы же тестировщики! Экономьте время, а не тратье его!
Неудивительно, что при нехватке информации о продукте, архитектуре, реализации тестирование значительно менее эффективно. Но иногда эту информацию с клещами не вытащишь!!
Я очень долгое время думала, что всё зависит только от меня.
* Не успели протестировать? Медленно проверяем, оптимизируемся!
* Не поняли ТЗ? Сами непонятливые, будем читать дальше эти жалкие 3 странички на продукт с 2 миллионами строк кода.
* Не отреагировали на изменения, сделанные за 2 дня до релиза? Гибче надо быть, будем готовиться…
* Не смогли объяснить проблемы руководству? Надо прокачивать коммуникативные навыки, плохо объясняла!
Такой подход казался мне логичным: тестирование — процесс зависимый и сервисный, значит, надо адаптироваться. Но всё чаще, сравнивая процессы в множестве проектов, в которых я участвую, я прихожу к выводу, что возможности тестирования далеко не безграничны. Можно и нужно пытаться непрерывно подстраиваться, можно и нужно отстаивать свою точку зрения, можно и нужно оптимизировать тестирование и процесс разработки в целом.
Но есть такой момент, когда надо сказать «СТОП». Из килограмма апельсинов физически нельзя выжать три литра сока. Когда перед нами благодатная почва проекта с хорошо налаженным процессом (где «хорошо налаженный» далеко не обязательно значит «формальный»), мы можем приносить массу пользы. Но если такой почвы нет и понимания не предвидится — не надо пытаться, тестирование только повышает энтропию.
Хочется свершений? Ищите «живые» проекты, не пытайтесь воскресить мёртвые.