— Постоянно эти мысли посещают. У меня есть ряд навыков, которые помогут перейти мне на плюс/минус стандарт-разработчика. Но пока я чувствую, что область большая, есть куда расти: например, тестирование безопасности, в котором я вообще не бум-бум. Область очень широкая и смысл прыгать туда-обратно, если ты в этой области ещё не реализовался до конца.

Ещё есть UI/UX — очень мало тестировщиков, которые это могут нормально делать. Но это направление надо развивать. Во-первых, это даст тебе очень большой профит, когда ты будешь просто тестировать. Чем отличается опытный тестировщик от неопытного? Опытный уже очень много видел и он плюс-минус знает, как система будет себя вести. Если нажмёшь кнопку «create» — она откроет новое окошечко. Когда приходит джуниор, для него каждая новая форма — это вход в новый мир. Если ещё не дай бог «Dropdown» есть.

Для тестировщика важен ещё и скилл аналитики — понимать систему, как она должна работать. Бизнес-аналитик расписывает юзкейсы, спецификацию — тестер должен всё это понимать.

Например, делали мы один проект для организации матчей в школах. В школах висят большие табло (красивые, со счётом): ты полностью конфигурируешь команду, спорт, можешь создавать соревнования. Начинается игра и табло выводится на телевизор (есть отдельная страничка в браузере) и там всё это админится. Сели расписывать спринты в Asana: нужно сделать авторизацию, нужно создать команду. Мы там всё насоздавали классно-прикольно, а потом: «Стоп, а во что играть то будем?». Уже все спринты распланировали, а спорт мы не создали нигде. А потом в спорте оказалось, что вот таких и таких полей не хватает. Это всё вылазило на этапе тестирования.

— Если тестировать UX, то лучше A/B-тестирования в UX ничего нет — моё личное мнение. У тебя всегда есть группа одних людей, которая пользуется одним интерфейсом, группа людей, которая пользуется другим интерфейсом — и ты можешь что-то понять. Была в Технопарке одна компания: у них была балалайка, которая позволяла понять, куда смотрит человек за счёт тепловой карты взгляда. И там можно было понять: «Аха, вот этот элемент забирает слишком много внимания, а вот этот элемент ключевой, а на него никто не смотрит».

Круг «тестировщик-аналитик-дизайнер» должны тесно взаимодействовать, чтобы не упустить детали. У дизайнера своё видение, он может уйти в свои фантазии: нагородит там всего. Так что в итоге твоё приложение получится крайне неудобным с точки зрения юзабилити.

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

— Иногда создаётся ощущение, что твоя работа нужна только тебе самому. Ты что-то делаешь, убиваешься, находишь идеи, а всем вокруг без разницы. Тестировщика может расстроить, что он баг ложкой выковыривал откуда-то из глубин, четыре часа жизни потратил, десять раз покурил, а ему: «Ладно, потом пофиксим». И он полгода потом ещё висит.

Не надо воспринимать человека как данность. Однажды я тимлидил в отделе из нескольких QA—у меня парни постоянно получали [внимание и заботу]. Но где [внимание и забота], там и похвала — например, я всегда зарплату хорошо выбивал для них. Потом я ушёл и они перестали получать [внимание и заботу]: в итоге у них появилось ощущение, что ничего не движется. Те, кого я набрал в команду, до сих пор работают, потому что была правильная система поощрения и [заботы]. Но [забота] всегда должна быть аргументирована.

— Первый кейс: поделить на ноль. Второй: можно поделить 10 на 3 и получить период — как обработает калькулятор это значение? Ты можешь попробовать «переполнить стек», то есть сделать переполнение типа: написать очень большое число и посмотреть, что он с ним будет делать — может он просто грохнется. При том же делении на ноль должна быть корректная обработка ошибки. С точки зрения UX-тестирования должно показаться как минимум сообщение: «Парень, ты не можешь делать такую операцию». Чем больше разработчик может назвать таких кейсов рассказать, тем лучше. Было очень много кандидатов, которые не додумывались на ноль поделить — это признак того, что парень не особо может перебирать варианты. Однажды меня собеседовали и был прикольный вопрос со снековым аппаратом. Там уже побольше вариантов: например, тестирование безопасности — взять молоток и разбить стекло. Или с телефоном: что будет, если человек решит погрызть батарею в телефоне, как в том смешном видео? Примерно так себя должен вести тестер: взял батарейку и погрыз. Это полуавтоматизация получается.

Чем больше тестер может придумать вариантов, как что-то сломать, тем лучше. Есть второе качество, которое не менее важное: чтобы он сильно этим не увлекался. Он должен видеть грань, когда нужно перестать. И, конечно, важно знание теории.

— Главное уметь объяснять людям важность тестирования. Если у тебя есть куча знаний и ты знаешь кучу методов тест-дизайна, но не можешь донести до человека, как это сделать, то грош цена твоим знаниям.

Часто бывало на собеседованиях, что приходит человек с опытом 4 года в ручном тестировании. Спрашиваешь его о том, что выходит за рамки его должностной инструкции — он не знает. Всё это время сидел и тестировал то, что говорили. Или: «У нас был свой фреймворк, который делают ребята в другом отделе — мы им пользовались».

К этому приводит такое отношение людей: «Ты тестер и должен тестировать». Но зачем человека загонять в рамки? Он посидит у вас 2 года и уйдёт. Потом пойдёт в другую компанию весь такой уверенный, что у меня опыт 2 года, а окажется, что реального опыта нет. Была девушка с опытом 10 лет в крупной продуктовой компании, но без опыта автоматизации. Пришла и сказала: «Хочу быть джуниором за 100К., но опыта автоматизации нет». Я так вежливо людям ещё никогда не отказывал.

— Написал первую строчку спецификации и можно сразу подключать QA. Сначала он может тестировать спецификацию, далее может сразу накидывать чек-листы, писать тест-кейсы. Если спецификация сделана в виде юзкейсов — это вообще сказка. Можно сразу же в готовые кейсы писать. Если проект длинный и большой, то имеет смысл сразу сделать автоматизацию. Она поможет выявить на восьмом спринте то, что сломалось на втором и что никто не трогал. Частая ситуация: учётка лежит в базе, через неё все логинятся. В восьмом спринте оказалось, что регистрация отвалилась — её никто не трогал никогда, потому что она во втором спринте была сделана. Это плохой кейс на самом деле — за такое тестировщику по рукам надо надавать.

Тестирование нужно закладывать на старте проекта с точки зрения качества приложения. Это сильно снижает риски.

— Был прикольный проект «Голод» (Москва) — один из успешных проектов, в которых я участвовал. Ребята запустили экспресс-доставку еды. Ты заказываешь и получаешь еду за 8 минут. Я не знаю, как они это делают, но у них планируется ежедневное меню, есть курьеры в разных точках.

Недавно нашёл интересный проект — Welltory. Приложение включает вспышку на камере, ты подносишь палец и он мерит твой пульс — приблизительно нормально. По пульсу он мерит всякие параметры. Например, я недавно мерил перед сном и он показывает: нет стресса, не мобилизирован. У него дизайн прикольный: можно потыкать, поискать. Такие приложения мне нравятся. Нравится мобильное приложение Альфа-Банка. Есть приложение Slack — оно мне не нравится. Первое время мне было плохо от этого приложения — я не знал куда тыкать. Мне нравится, когда ты заходишь и сразу видишь, куда нажимать.

— Люди хотят накрутить, чтобы было круто, круто, круто. Ещё это происходит из-за высокой конкуренции на рынке. Кто-то прёт на рынок и говорит: «У меня есть приложение». А ему говорят: «А у нас уже есть такое приложение. Почему мы должны использовать твоё?». «А у меня тут есть ещё вот это и это» — из этого рождаются огромные интерфейсы.

Возьми WhatsApp. Когда я начал пользоваться WhatsApp— было вообще супер. Но потом они стали добавлять лишние функции и теперь я стал пользоваться Telegram. Я бы вообще пользовался ICQ— там всё шикарно было.

— У меня есть давняя идея сделать «холодильник». Ты заходишь и посередине холодильник. Ты можешь в него добавлять продукты. У тебя есть список, где ты можешь поискать продукты. Ты добавляешь продукты и потом у тебя выскакивает список рецептов, которые ты можешь сделать из этих продуктов.

Ещё есть идея — точнее потребность. Я нигде не могу найти нормальный планировщик расходов. Мне нужно реально 2 кнопки: «добавить деньги» и «отнять деньги». Без всяких статей расходов. Можно сделать поле, сколько я потратил на хлеб, но нужно сделать его необязательным. Я наверное штук десять перепробовал планировщиков расходов и в каждом из них начинал блудить. Однажды я купил масло в автомобиль, а в приложение было только «ремонт автомобиля». Но это не ремонт автомобиля и там не было другой статьи. Я сидел и не хотел добавлять это в ремонт, потому что это не ремонт, а создать свою статью расходов я не мог. Решу я в конце года посчитать, сколько я потратил на ремонт, а в ремонте и бензин, и всё остальное: буду сидеть и палочкой выковыривать, что ремонт, а что не ремонт.

Чаще всего так происходит, потому что дядя, который хочет такое сделать — хочет, чтобы у него было круче всех. Сейчас, когда тебе попадает в руки простое приложение — ты сидишь и думаешь, как классно.