Заебавшийся QA engineer

Среди непосвященных в IT, да и внутри него, например среди разработчиков, бытует мнение, что тестирование является одной из самых простых областей в нашей драгоценной отрасли.

Я больше 10 лет работаю в тестировании, работал и в аутсорсе, и в продукте, успел ощутить на собственной шкуре прелести Waterfall и Agile, побыть и менеджером, и Scrum Master и чертом лысым. И могу с уверенность сказать, что страшнее и сложнее области нет и быть не может. Но обо всем по порядку.

Итак, откроем описание любой вакансии QA, что мы там видим в обязанностях:

• —  Анализ требований

• —  Составление планов и стратегий тестирования

• —  Написание тестов и их поддержка

• —  Проведение тестирования

• —  Составление отчетов о качестве и анализ рисков

• —  Определение и анализ метрик качества продукта

• —  и так далее по списку в том же роде.

  Что имеем по факту:

  Требования должен писать либо бизнес-аналитик, либо Product Owner, который не сильно переживает на эту тему, так как ответственность за качество этих требований всегда можно переложить на тестировщика. Конечно, тестировщик же проверял, что там все понятно и все случаи учтены, а не проверил — так сам виноват, с него и спрос. Допустим, что тестировщик таки правда делает этот анализ качественно, задает массу вопросов и предупреждает о всех возможных рисках. На что часто (читай: всегда) получает ответ, что ну да, тут не очень понятно, да и тут, безусловно, можно бы сделать по уму, а не быстро, но у нас сроки горят, нам на вчера надо, так что как-нибудь так. У нас же есть QA, а значит проблем быть не должно. Надо просто потестить получше, тыжесениор!

  Планирование тестирования почему-то ожидается четким, привязанным к датам и описывающим все возможные случаи. При этом разработка ведется в условиях полной неопределенности и работа на спринт планируется так, что последние стори доделывается аккурат в день релиза. Будто бы все будет выполнено четко в срок и без единой серьезной ошибки. Вы же помните, у нас же сениор инженер за качество отвечает, а значит багов быть не может, тем более критических, тем более в день релиза. Ну есть же у нас 40 стори-поинтов, вот на спринт их 40, на все две-три недели. С первого до последнего дня. Как и когда тестер в этой ситуации должен все еще и проверить, да и все найденные и починенные баги по 20 раз перетестить, и о регрессии не забыть, потому что приложунька у нас сложная, зависимости между модулями проявляются самым заковыристым образом, а документации отродясь не было. У нас же Agile, и половина фич пилится на костылях, потому что надо на вчера, потому что Sales уже продали потенциальным заказчикам то, что еще даже в разработку не попало, потому что же у

менеджеров в Power Point уже красивые графики. А тут ты со своим вечно недовольным лицом. Мыжеменяеммир!!! Ауу, зануда!

Написание тестов. Отдельная большая тема. Не, я вообще двумя руками за то, чтоб все записывать, чтоб ничего не забыть. И чтоб база знаний была, и чтоб если я вдруг скоропостижно заебусь и уволюсь, как-то можно было продолжать и тестировать дальше. И тут начинается самое веселое. У нас же Agile, все помнят? То есть требования мы меняем на ходу, приложение быстренько и на коленке подстраиваем под то, что сейчас нужно юзерам, меняя, улучшая, делая полезнее. Все так, ок. А тестировщик не упорется, если все свои красивые тесты быстро побежит и поправит с учетом изменений. Ну что, разве трудно поправлять, пока тестируешь?
А тебе непонятно, как должно быть? Требований об этом четких нет? Ну так следуй здравому смыслу! Что неясно? А если вдруг окажется, что здравый смысл твой подвел, ты что-то там не так понял, так мы тебя носом ткнет, потому что надо было спросить, потому что Agile, а он у нас о коммуникациях. Мыжекоманда, епт! Но вообще, друг, нехорошо разработчиков отвлекать, тебе уже сто раз на ретроспективе говорили. Держись как-то золотой середины, тыжепрофессионал.

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

Отчеты — отдельная больная тема. Менеджерам в Power Point очень нравится вставлять красивые скриншоты с красивыми графиками о результатах тестирования. А значит ты эти графики будешь рисовать. Считать на бумажке и рисовать. Ага, ну потому что тулов у тебя нет, а гуглодоки сами себя считать не умеют. И да, деточка, у нас Agile, так что отчет ты должен предоставить в любой момент, когда попросят. Будь гибким, сука! Как это у тебя времени нет? Требования проверил, тесты написал, протестировал, подредактировал, баги завел, с разработчиками поспорил о том, как надо, еще на две сотни митингов сходил, неужели не нашел часик сгенерить отчет из своих сотен кейсов? А, да, там я вон на конференции о каком-то супер-пупер фрейморке слышал, давай посмотри, пора автоматизацию написать. А то что это, ты тут на той неделе сдох и на работу не пришел, а мне вот этот весь ворох своими ручками пришлось проходить. Нехорошо. Да, и разберись как это все на CI прикрутить, девопсов у нас нет и пока не предвидится, но тыжесениор, мы тебя для того и наняли, забыл, да? Сам говорил, что лучше избегать человеческого фактора, надо автоматизировать, так сделай!

Метрики. Цели. OKR. И много еще всякой красивой херни. Мы хотим, чтоб через год на проде не было багов. Вообще. Так что придумай метрики и как их достичь. Вот, на тебе статью, почитай.

И это вот все не считая того факта, что программист обычно работает довольно долго с одной технологией, пишет он там на Java и пишет себе. Учится, безусловно, разбирается в чем-то новом. Но тестировщику везет куда больше. Сегодня у тебя проект на одной технологии, завтра на другой, послезавтра на третьей. Вчера был Unix, сегодня Azure или AWS. Вчера энтерпрайз с легаси, завтра микросервисы. Тыжесениор, не знаешь — иди гугли. Ты должен развиваться. И ничего, что в рабочее время ты тестируешь и тушишь пожары, ночами ты переписываешь тесты и готовишь отчеты. Останови время что ли, сядь и разберись, что ты как лох. И вообще ты какой-то странный, глаз у тебя дергается, не брился уже месяц, жена твоя приходила, говорит, что сын забыл как выглядит папа. Но ты на митинге был, он через стеклянную дверь на тебя посмотрел.

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

В общем, дорогие друзья, особенно желающие войти вайти через тестирование, очень советую подумать. Хорошо подумать. Всем чмоки!