Как стать автором
Обновить

Как жить без документации. Если бы реальность тестировщика была сюжетом аниме

Разработка веб-сайтов *Тестирование IT-систем *Разработка мобильных приложений *Тестирование веб-сервисов *Тестирование мобильных приложений *
Из песочницы

Наверное, любой тестировщик хоть раз в жизни слышал фразу «‎Тестирование нужно начинать как можно раньше»‎. И это правда. Чем раньше у отдела качества появится информация о проекте, тем меньше вероятность пропуска логических ошибок. Но жизнь — не сказка, и очень часто продукт попадает в руки тестировщика на предпоследнем этапе. Разумеется, и так можно работать, и весьма продуктивно. Но что делать в ситуации, когда отдел QA еще и не получает информации, ибо ее попросту нет. Весь проект в голове лида/менеджера, там все стройно, четко, красиво. Но как только он порционно выдает задачи команде, начинается то, о чем я хочу рассказать. Поэтому давайте попробуем поднять ставки и погрузиться в фантастическую вселенную, где каждая ошибка фатальна.

Итак, есть мир, который похож по форме на песочные часы.

В двух сферах находятся два королевства: DEV и QA. А в горловине располагается Великий Поток, разделяющий страны. Третьей стороной является гильдия LEAD, которая должна следить за всеми передвижениями в Потоке. Должна. А вот какие ситуации могут произойти.

Пустой шаттл

Из страны DEV вылетает шаттл. Стандартный красивый шаттл. Есть в нем только один недостаток он абсолютно пуст. Ни бортовых журналов, ни свидетельств, ни лицензий, ни журнала операций. Шаттл минует Великий Поток и долетает до страны QA, но вот незадача: жители QA не понимают, что делать с этим шаттлом. Они отправляют корабль обратно с огромным знаком вопроса. Весь путь шаттла был проделан впустую.

О чем это

Любимая всеми тестировщиками история про то, как менеджер поставил задачу разработчикам. Разработчики задачу приняли и сделали. До QA информацию никто не донес, более того, в репорте, который они получили, информации тоже нет. Абсолютно пустая единица.

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

Таинственный шаттл

Из страны DEV вылетел шаттл. Однако, на сей раз проблема грандиознее этот шаттл пунктирный. Примерно как фьючерсная свинина в книгах Пратчетта, что-то такое загадочное, что еще не придумали. Это нечто долетает до страны QA. Но жители QA не могут выпустить подобный экземпляр, поэтому из их страны уже вылетает четко оформленный шаттл. Проблема в том, что он совершенно другой  формы. И когда этот шаттл достигает страны DEV и гильдии LEAD, оказывается, что все это время имелся в виду шаттл вообще третьей формы. Такой и отправляется снова из страны DEV с огромными восклицательными знаками.

О чем это

Все очень просто. Это случай, когда лид и разработчики задачу обсудили, тестировщикам что-то примерно рассказали. Нигде данная информация письменно не зафиксирована.

Как итог, у QA нет четкого ТЗ, им не на что опереться, кроме общих устных формулировок. Соответственно, появляется риск несоответствия фактического и ожидаемого результатов. Технически вроде бы все работает, но изначальным требованиям не соответствует. Да и на отношениях команды такая ситуация будет сказываться не лучшим образом. Потому что выглядит все так, как будто все всё понимают, а тестировщики глупенькие. Но тестировщики не обязаны постоянно догадываться, что имелось в виду, у них на руках должны быть четкие требования.

Неуверенный шаттл

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

О чем это

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

Не спасет здесь и плотное сотрудничество и общение разработчиков и тестировщиков. Потому что включается человеческий фактор. Лид может изменить мнение, передумать. И даже если QA пытались на основе услышанного что-то фиксировать и вести документацию, они не смогут доказать, что ошибки и несоответствия — не их вина. В идеале лид все же должен фиксировать свои мысли по поводу проекта, чтобы не подставлять собственную команду.

Что такое шаттл?

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

О чем это

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

Мутирующий шаттл

Вновь гильдия LEAD отправляет шаттл в страну DEV. Шаттл четкой формы, все просто и понятно. Казалось бы. Но так случается, что из страны DEV вылетает шаттл весьма похожий, однако несколько иной конструкции. Отличия минимальны. Однако, прибыв в страну QA, шаттл вновь меняет форму. Она похожа на второй вариант, но уже существенно отличается от первого. И именно в таком мутировавшем виде он возвращается в гильдию.

О чем это

Это происходит когда лид объяснил задачу разработчикам, и они ее выполнили. Тестировщики выясняют подробности у разработчиков и тоже свою работу делают. Что может пойти не так?

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

Взрыв шаттла

Мы дошли до самой грустной главы истории этого странного мира. Грустная она в первую очередь для страны QA. Из DEV вылетел шаттл и, минуя противоположное королевство, сразу направился в гильдию LEAD. Что случилось с этим кораблем дальше, мы не можем сказать. Известно только то, что со стороны QA раздался взрыв.

О чем это

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

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

Делаем выводы

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

А теперь вернемся из нее в реальность. Ведь не так сложно принять тот факт, что нельзя держать весь проект только у себя в голове. Как бы продуман он не был, в момент донесения информации она обязательно исказится. Не стоит думать, что разговор будет таким же полным, четким и внятным, как ТЗ. Лид, не фиксирующий свои же задачи, рискует увязнуть в бесконечных переделках, фиксах, объяснениях по третьему кругу. А если еще и его команды разобщены, и разработчики считают, что тестирование им не особо нужно, то скорее всего продукт выйдет неполноценным и непродуманным. Ведь простая истина в том, что лид, разработчики и тестировщики смотрят на проект под разными углами. И единственный верный путь — принимать все эти точки зрения, а не игнорировать ту, что кажется неудобной и тормозящей процесс.

Автор иллюстраций Иван Андреев

За вдохновение спасибо аниме Last Exile — © ラストエグザイル, 

Студия Gonzo

Режисер Koichi Chigira

Дизайн персонажей Range Murata

Дизайн Mahiro Maeda

Теги:
Хабы:
Всего голосов 4: ↑0 и ↓4 -4
Просмотры 9.7K
Комментарии Комментарии 4