Всем привет. Меня зовут Серёжа Аксёнов, и я тестировщик. А ещё я пишу стихи, и сегодня мы попытаемся скрестить ежа с ужом.
Шутка. На самом деле и тестированием, и поэзией я занимаюсь довольно долго и хочу поделиться своими наблюдениями о том, как привычные тестировщику навыки и подходы могут быть эффективно применены в области, на первый взгляд, далёкой от IT — литературной критике.
Тестирование – та же критика, только не стихов/прозы, а программ. Но поэзия, хоть и существует пару тысячелетий, в настоящее время является областью глобально менее значимой для человечества, чем программирование. На повышение эффективности литературы не бросаются такие силы и средства, как на разработку ПО. Поэтому молодая наука сегодня учит старую. Хотите поговорить об этом?
Может показаться, что я не люблю поэзию. Нет! Не любят поэзию те, кто не хочет, чтобы она развивалась.
Итак, рассмотрим неумелую литературную критику как набор антипаттернов тестирования ПО. Поехали по пунктам.
0. Для чего нужен тестировщик?
Ответ: чтобы программист написал хорошую программу. Не для того, чтобы сказать программисту, какой он криворукий; не для того, чтобы он перестал писать программы вообще; не для того, чтобы продемонстрировать своё остроумие; не для того, чтобы показать всем, что он и сам умеет программировать. Очевидно? А теперь представьте критика, который говорит подобное автору. Такой критик понятия не имеет, ЗАЧЕМ НУЖНА КРИТИКА. Конечно же, от его комментов никто не станет писать лучше, поэтому такие критики не нужны.
А программист может быть джуниором, стажёром, это не важно. Со временем научится. Программировать всегда идеально – невозможно, потому что это сложный процесс. Писать стихи – попроще, но тоже не бирюльки. Поэтому: ошибки – нормально. Даже глупые. (Ну да, над смешными багами не грех поржать с коллегами за чаем, но – вне рабочего процесса, не в репортах.) Ещё раз - тестировщик нужен, чтобы ПОМОЧЬ программисту.
1. Что такое хорошие программы?
Те, которыми люди пользуются, потому что эти программы делают их жизнь лучше/проще/приятнее. Хорошим стихам тоже подходит это определение.
Но если через 5 минут хочется разбить монитор клавиатурой, то это не хорошие программы. Непроработанные, криво написанные стихи вызывают ровно такое же отторжение. Интерфейс имеет значение для стихов, как и для программ.
2. Тестировщик и программист – разные люди
И мыслят по-разному. Критик и поэт – тоже. Да, большинство тестировщиков умеют кодить что-то простое для своих тестовых нужд. Многие тестеры владеют бОльшим числом языков и технологий, чем средний программист – но на базовом уровне, не углубляясь. Аналогично: начитанность, эрудированность и широкий кругозор гораздо важнее критику, чем поэту. А умение писать хорошие стихи – не обязательно. Хорошие программисты не так уж часто бывают хорошими тестировщиками, из даже хороших поэтов критики зачастую вообще никакие.
3. Тестировщик программирует хуже программиста
Поэтому менторский тон в речах от критиков к поэтам – признак бездарного критика. Тестер – не учитель программиста, он его друг и немножко совесть. Хороший программист сам знает, как надо – если показать ему, как не надо было и почему. Так же и автор лучше знает, как исправить текст, в котором нашлась проблема.
4. Тестировщик – это суперпользователь
Он должен знать программу вдоль и поперёк – и не столько изнутри (хотя и это не возбраняется), сколько снаружи. Если обычный юзер может использовать программу неправильно, то тестировщик обязан это сделать. Если стихотворение содержит двусмысленности, недосказанности, ошибочные толкования, то критик обязан понять его всеми способами, включая неправильные. И если при этом получается какая-то ерунда – отлично, заводим баг.
5. Что такое ошибка?
Ответ: несоответствие результата требованиям. А какие требования к стихам? Да такие же, как к ПО. Отсутствие критических ошибок (нарушений правил русского языка), функциональность (стихотворение должно быть для чего-то), совместимость со средой (культурным контекстом), архитектура (рифмы, ритм), ресурсоёмкость (без воды и без грузилова). Да полно их, требований. Просто в отличие от разработки ПО, бизнесовые и функциональные требования обычно выставляет не отдельный человек (аналитик, менеджер), а сам, так сказать, разработчик текста.
6. Я нашёл ошибку! Что дальше?
Молодец. Заведи тикет, составь багрепорт. Как правильно описать ошибку? Локализовать (см. ниже) и описать, почему это является ошибкой, сославшись на требования – явные или неявные. Например, на правила русского языка; на статью энциклопедии; на стихотворение другого автора (широко известного); на число совпадений выдачи Яндекса/Гугла и т. д. Иначе говоря, без ссылки на объективные источники – незачёт. (Разве что очевидные можно опустить.)
7. Декомпозиция, декомпозиция, декомпозиция
Программы состоят из подсистем. Стихи – тоже вещь не такая уж монолитная. Проще понимать, какие могут быть ошибки не в стихотворении целиком, а в рамках отдельной подсистемы. Например, я выделяю: грамматика (ну всё же); ритм; фонетика (рифмы и другие звуковые приёмы); лексика (уместность в теме, тавтологичность); поэтические средства (метафоры и прочие рюшечки); основная идея; сеттинг (его непротиворечивость); сюжет и логика его развития. Баг можно и нужно локализовывать в проблемной подсистеме - что в программе, что в стихах.
8. Интеграционные тесты
А бывает, по частям всё отлично – и форма идеальная, и содержание полно глубоких мыслей, но всё вместе это колыбельная в ритме марша.
Ещё стрёмный тренд – когда критик хвалит метафору или рифму, не поняв смысла стихотворения целиком. Какой толк в кусках? Программа всё одно не запускается.
9. Тестирование требований – тоже тестирование
Иногда сами требования (изначальный замысел) программы или стихотворения имеют проблемы с обоснованностью, непротиворечивостью, полезностью и т. д. Это очень тяжёлые баги, которые необходимо устранять до начала написания кода. Да, в поэзии заказчик и разработчик – как правило, одно и то же лицо. Но это слабое оправдание.
10. Баг или фича?
Иногда не понятно. Автор художественного текста - особенно сразу после написания - часто имеет искажённое восприятие: только что написанное самим собой кажется ясным и понятным, хотя, вполне вероятно, какие-то важные логические связки остались в воображении автора и не дошли до бумаги. А бывает и так, что какой-то неочевидный фрагмент текста специально запутывает читателя - например, чтобы раскрыть оставленную загадку позднее. Так же, как в программах, непонятное условие может быть как ошибкой, так и необходимым магическим хаком. Поэтому хороший критик/тестировщик должен держать контакт с автором/разработчиком. Если автор действительно задумывал такое поведение героя или функции – ну, хорошо.
11. Кажется, я знаю, как это улучшить
Предложи. Но именно в такой формулировке. Без слов «кажется», «по-моему», «предположительно» и подобных высказанное будет не предложением, а неграмотно (невежливо) заведённым багом. И вообще, лучше не злоупотреблять.
В заключение хочу лишь добавить, что тестирование - это не просто поиск ошибок в программах, но и своего рода культура оценки качества чего угодно. Я верю, что следование этим культурным кодам помогает улучшать мир вокруг нас с максимальной эффективностью. А применение их в других смежных областях помогает наглядно увидеть, насколько они важны, какими бы привычными и очевидными нам ни казались.
С прошедшим Днём тестировщика, коллеги!
