Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>19 дек 2022</li>

3 <li>0</li>

4 </ul>Инженер по тестированию разрушает миф о том, что QA - это легко и весело.

5 Фото: StockLite / Shutterstock

6 Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

7 За последние двадцать лет программист перестал быть восьмируким божеством, которое выполняет функции целой фабрики. Роль "‎одного незаменимого" ушла за кулисы. Ны рынке IT появилось множество специализаций, а старые профессии были модифицированы и потребовали освоения новых навыков. Теперь тестировщик не просто monkey cliсker. Он стал QA-инженером - специалистом по обеспечению качества. Такой сотрудник занимается проверкой продукта на всех этапах работы - от составления документации до финального релиза.

8 В этой статье я не буду рассказывать о том, какие языки программирования надо знать тестировщику и почему ему нужно уметь работать с базами данных. Вместо этого мы поговорим о кризисных ситуациях, с которыми специалист может встретиться в работе. Я поделюсь своим опытом: как из них правильно выходить, чтобы сохранить репутацию надёжного сотрудника и не навредить рабочему процессу.

9 Советы будут особенно актуальны для тестировщиков, которые трудятся в стартапах и аутсорсных командах - мой опыт получен именно на таких проектах. В этой статье поговорим:

10 <ul><li>о <a>неприятном сценарии</a>, который может возникнуть в работе QA-инженера;</li>

11 <li>о том, почему в команде иногда<a>придётся брать на себя роль проджект-менеджера</a>;</li>

12 <li><a>как не стать крайним</a>, если проект отстаёт по срокам;</li>

13 <li>почему тестировщику иногда важно<a>побыть оратором и даже психологом</a>;</li>

14 <li>как<a>рассчитать сроки реализации проекта</a>, чтобы снизить риск срыва дедлайнов.</li>

15 </ul>Кадр: фильм "Люди в чёрном 2"Представим себе картину. Вы приходите на проект в совершенно новую команду. Знакомитесь с аналитиками, разработчиками, девопс-инженерами. Все на удивление оказываются очень приятными людьми. Вас знакомят с задачами, обозначают их сроки, после чего вы с нетерпением и энтузиазмом, засучив рукава приступаете к…

16 Нет. Не к тестированию. Вы начинаете заниматься всем чем угодно, кроме проверки качества ПО. Просто потому, что доступов нет, аналитики ещё не подготовили спецификацию, а разработчика на проект нашли только в последний момент.

17 "Хорошо", - думаете вы и, сделав всё от вас зависящее, с нетерпением ждёте следующего спринта. Пока, наконец, программист не выложит вам первую сборку на тестовый стенд, и вы не начнёте проходить ранее написанные сценарии.

18 Проходит ещё две недели, и вы понимаете, что тест-кейсы уже не актуальны - требования поменялись. Разработчик внешнего сервиса полностью изменил API, и вообще - ждать выкладки на UAT не стоит.

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

20 Всё чаще вы начинаете слышать слово "‎тестирование", хотя эстафетную палочку вам ещё не передали. И тут вы понимаете: что-то пошло не так. Конечно, вы знали это ещё месяцем ранее, когда руководитель проекта вдруг разрешил разработчикам не писать unit-тесты. И сказал, что пользовательское тестирование вы будете проводить уже на следующей неделе, даже без проведения smoke. Но именно сейчас вы поняли, что совершили промах. Но где именно?

21 Ведь вы обозначали риски, вовремя говорили о необходимости регресса и о доработках кейсов, которые понадобятся в связи с изменением документации. И всё равно тень недовольства бросилась на вас. Давайте разбираться почему.

22 Представим логичное продолжение нашей истории. К вам приходит руководитель проекта и недовольным голосом спрашивает: "Почему нужно так много времени на тестирование, и по какой причине оно ещё не начато?"

23 Вы делаете круглые глаза и говорите, что ещё неделю назад не было даже готовой документации. А разработка не загрузила итоговую сборку на стенд.

24 Руководитель отвечает, что технолог Клара уже давным-давно выложила итоговый файл спецификации, а разработчик Петя ещё две недели назад сообщил вам о необходимости тестировать всю интеграцию через mock-сервисы и снифферы, не дожидаясь выкладки на стенд.

25 Пытаясь оправдаться, вы распинаетесь про важность тестирования E2E-кейсов, и говорите что вы вообще такую информацию не получали. На что руководитель заявляет: "Промах твой, так как ты недосмотрел за проектом и не довёл его до логического завершения. А в качестве кнута вот тебе минус 50% премии". Занавес опустился, в зале тишина…

26 Кадр: мультипликационный сериал "Человек-паук""Карикатурный пример и не имеет ничего общего с реальностью", - скажет читатель и будет наполовину прав. Настолько сильную концентрацию несправедливости вы вряд ли встретите на реальном проекте. С другой стороны, с этими проблемами по отдельности вы столкнётесь не раз. Что делать в этой ситуации? Действовать самостоятельно.

27 Побуду адвокатом дьявола и скажу, что начальник выше прав. Его не интересуют ваше мнение о правильности тестирования и применении техник дизайна. Также его не волнует отсутствие опыта в создании mосk-серверов, незнание снифферов или методологии разработки ПО по V-модели. Его интересует лишь результат, а он не достигнут.

28 На вашем проекте может потребоваться даже<a>нагрузка</a>или автоматизация. И вы узнаете об этом в самый последний момент. Как и о том, что демо должны будете проводить именно вы. И будьте уверены: ни руководитель проекта, ни кто-то другой вам об этом не скажет.

29 И это будет справедливо, так как именно вы ответственны за итоговый результат продукта. Вы - последний оплот благоразумности во всех смыслах: должны донести информацию и предостеречь о возможных проблемах сами.

30 При этом вы не должны быть дирижёром симфонического оркестра - для этого есть руководитель проекта. Но вам нужно быть концертмейстером, задавать общий темп команде и подстёгивать её там, где руководитель не видит необходимости или не может этого сделать.

31 Чувствуете, что разработка захлёбывается в задачах и молчит в тряпочку, - обозначаете это на статусе. Понимаете, что техническая документация не соответствует разработке, - помечайте все моменты и выносите их на обсуждение. Видите, что программист не может наладить контакт с вендором, а у вас есть для этого свободные руки - устраивайте общий конф-кол с коллегами.

32 Многие подумают, что такой человек в команде занимается не своими обязанностями, пытается изобразить что-то непонятное и вообще… Однако всё вышеперечисленное есть не что иное, как роль QA в команде (не путать с QC). А это нечто большее, чем два притопа, три прихлопа. Ведь свободную неделю, пока пишется документация, можно потратить на написание тест-кейсов. Понимая, что они через две недели опять поменяются. Либо наладить коммуникацию, сделать часть работы за аналитиков и разработчиков, получив бесценный опыт.

33 Тут, конечно же, стоит добавить два больших "‎НО". Если у вас есть лид в команде, то все шишки полетят на него, а не на вас. Но ведь мы хотим вырасти профессионально и достичь карьерного роста? Значит, рано или поздно придётся брать ответственность на себя.

34 Ну и второй момент. Руководитель проекта всё равно виноват так же, как и вы. Даже если вы оба не виноваты. Бессмыслица? А вот и нет. Руководитель выбирает себе сотрудника, ответственного за проект, который будет ведущей скрипкой всего тестирования. Соответственно, если ведущий инженер не тянет позицию, значит, сплоховал именно начальник - выбрал слабое звено. Хотя, стоит признать, что иногда выбор и вовсе отсутствует.

35 Но вернёмся к нашим нехорошим коллегам. Выдуманным аналитику Кларе и разработчику Пете, которые взяли да и свалили всю вину на нас. Можно ли винить их за это? Наверное, можно. Но так уж ли они неправы в том, как поступили?

36 Ведь первая сказала, что документация была готова ещё неделю назад, а второй - что нужно всё это дело тестировать на моках, пусть даже и шёпотом. Суть в том, что вам нечем крыть. Вы можете апеллировать к неправильности подходов к тестированию, разработке ПО в целом и к нечестности ваших коллег. Однако все ваши призывы без подтверждения будут не более чем сотрясанием воздуха.

37 Кадр: фильм "Красная жара"Вспоминаем фразу из одного известного кинофильма: "Какие ваши доказательства?" А они должны быть. Причём всегда и на каждый случай. Хороший тестировщик не тот, кто находит все до единого бага перед релизом - это невозможно. Хороший тестер - тот, кого нельзя уличить в его виновности.

38 Завтра на проект придёт новый аналитик и попытается переложить всю вину на вас, но во второй раз этот фокус провернуть не удастся. Просто потому, что у вас на руках будет доказательная база - спецификация неделю назад не была готова. И вы на просьбу получить вменяемые сроки о готовности получили в письме "будет готово, когда будет готово".

39 И в следующий раз разработчик подумает трижды, прежде чем заявлять вам о тестировании на моках, когда увидит письмо с просьбой подтвердить готовность фронтенд-части сервиса на тестовом контуре.

40 Мы уже поняли, что тестировщик должен быть проактивным, немного параноиком и обладать качествами лидера. Или хотя бы к ним стремиться. Дальше - больше. Для следующего примера придётся обратиться к игровому опыту читателя - в жанре классических RPG. Обычно в подобного рода играх у персонажа можно улучшать различные характеристики. В реальности такой характеристикой будет красноречие.

41 А зачем инженеру по обеспечению качества красиво говорить? Возможно, десять лет назад такой вопрос был бы логичен. Но не теперь, когда появилось новомодное словосочетание<a>soft skills</a>.

42 Agile привнёс не только гибкую модель разработки, но и ежедневные совещания и конференции, которые требуют коммуникативных навыков. Если вы услышите где-то шутку, что разработчик днём разговаривает, а ночью работает - знайте, это не шутка.

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

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

45 Узнали, что разработка сдвигает планы по выкладке доработки на стенд? Обозначаем сроки сдвига начала тестирования и риски. Узнали, что заказчик захотел новую фичу, никому об этом не сообщив? Разработка возмущена. Но вашему возмущению нет предела. Стуча кулаком по столу, требуйте прислать письмо, чтобы зафиксировать новые требования.

46 Руководитель проекта говорит, что можно тестировать функциональность без фронтенда? Вы тут же парируете, что само API ещё даже не описано.

47 Вы не должны поддаваться на указания и просьбы смежных подразделений. Ни аналитика, ни разработка, ни руководитель проекта не могут напрямую вмешиваться в процесс тестирования и диктовать условия. Они могут лишь предложить свой вариант. Но принимать его или нет - тестировщик решает сам, опираясь на свои возможности и ресурс.

48 Только представьте реакцию, если QA начнёт учить разработчика писать код или будет управлять проектом за начальника. Чтобы всё это объяснить, завернуть в красивую обёртку и никого не обидеть, и нужно обладать пресловутыми soft skills.

49 Рассмотрим ещё одну ситуацию. Вы узнаёте, что необходимо пойти в релиз к определённому сроку. И у вас всё шло по плану до тех пор, пока разработчик не уволился, а на его место не пришёл другой. И вот проблема за проблемой, и вы теряете месяц, который нужен как воздух. И вам тут же хотят предложить альтернативу решения проблемы.

50 Кадр: фильм "Волк с Уолл-стрит"Вы выслушиваете её и где-то глубоко в сознании одобряете, но… нет, не соглашаетесь с ней. Скажите сейчас "‎ок", а завтра получите недовольство от вышестоящих, что сами на это подписались. А не подписаться вы уже не сможете. Парадокс, однако.

51 Зато вы можете поступить как бывалый торговец и произвести сделку наилучшим для вас образом. В психологии есть такой приём, называется "‎От большего к меньшему". Апеллируйте к возможным ошибкам на проде, к первоначальному плану, который пошёл под откос, к обозначенному ранее сроку тестирования и опасности выпуска задачи в релиз. Говорите об огромном количестве времени, которое на всё это уйдёт. А затем непринуждённо переходите к путям решения, к рискам и тем самым альтернативам.

52 Появляется резонный вопрос. В чём отличие от того, что предложил сам руководитель проекта пятью минутами ранее? Как минимум в том, что вы постелили себе немного соломы. И теперь, в случае обнаружения багов на проде (а они будут, это неизбежно - вспоминаем один из главных принципов тестирования), вы произнесёте своё долгожданное "‎я же говорил". И упрекнуть вас будет не за что. Ведь вы не забудете после обсуждения задокументировать всё это дело письмом.

53 К тому же люди легче и даже с радостью воспримут ваши предложения после пятиминутного спича, в котором вы нагоните страху и пообещаете вагон и маленькую тележку критов на продуктиве.

54 Можно сказать точно: поработав таким образом пять лет вы научитесь, словно заправский шпажист, с лёгкостью парировать атаки всех ваших оппонентов, будь то коллеги или заказчики. Правда, стоит предостеречь. Не пытайтесь навешать лапши всей команде. Ваши обоснования и опасения должны быть адекватны и подкреплены здравой аргументацией, которую вы сможете отстоять.

55 Ещё одно занятие, с которым вы столкнётесь (или уже столкнулись), - оценка ваших и чужих трудозатрат. С этим неизбежно работает каждый лид и не только. Первый и один из главных навыков профессионала в любой сфере - оценка своего труда. И казалось бы, что может быть проще, чем прикинуть человеко-часы по функциональному тестированию?

56 Есть десять форм. Если на одну форму мы тратим три дня, значит, в итоге потратим тридцать человеко-дней. Спешу огорчить - это так не работает. Рассмотрим на примере. Вы даёте те самые три дня на форму, а разработчик закладывает по два дня на каждую. Тайминг объясняется простотой реализации и тем, что есть наработки с предыдущих форм. Сказано - сделано.

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

58 В итоге выясняется, что разработчик не успел посмотреть последние изменения по спецификации и внести их в последнюю сборку. Все три формы по большей части возвращаются на доработку. Вы потратили целый день, а в итоге не протестировали ничего. На деле, конечно, протестировали, но это не отменяет того, что изменения будут большими и вам придётся прогонять тест-ран с нуля.

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

60 Кадр: фильм "Стажер"Но вот незадача. Вечером того же дня к вам приходит руководитель проекта и спрашивает, заложили ли вы время на исправление дефектов? Написана ли тестовая документация для пользователей с подготовкой тестовых данных? Заложено ли проведение обязательного регресса на дополнительном стенде? Выпучив глаза, вы понимаете, что первый пункт вы, допустим, закладывали, но о вторых двух слышите впервые.

61 Как не допустить такой ситуации? Задавать правильные вопросы. Представьте, что вы пришли на новый проект и заказчик хочет, чтобы вы провели тестирование. Ваши вопросы не должны ограничиваться запросами на предоставление доступов к тестовым контурам и банковским системам. Вот темы для беседы:

62 <ul><li>общий процесс разработки ПО;</li>

63 <li>жизненный цикл релиза и из чего он состоит;</li>

64 <li>возможность тестирования на заглушках;</li>

65 <li>подготовка тестовых данных пользователя;</li>

66 <li>процесс сопровождения пользовательского тестирования;</li>

67 <li>необходимость<a>нагрузочного тестирования</a>, автоматизации и регресса.</li>

68 </ul>Это лишь вершина айсберга. Без этих знаний вы не сможете дать вменяемую оценку трудозатрат. Помимо этого, не стоит забывать ещё о двух вещах. Они встречаются практически на каждом проекте. Разработка часто оценивает своё время без учёта накладок. Когда они случаются, несут ответственность именно те, кто стоит с правого края цепочки разработки программного продукта.

69 И вот до выпуска в прод у вас остаётся две недели, разработчики только сегодня выложили свою часть доработки, глубоко выдохнув. Затем прибегает руководитель проекта, рвёт на себе волосы и что-то кричит про тестирование, а у вас на тестовом контуре ещё конь не валялся.

70 Можно ли избежать такой ситуации? Разумеется - нет. Вы не Господь Бог, вы не можете отвечать за действия всей проектной команды, за неожиданные хотелки заказчиков и скупой менеджмент с коммуникацией.

71 Однако, даже если вы не Господь Бог, вам можно и нужно надеть на себя мантию пророка. Ибо просчитать аховую ситуацию, в которую катится проект, вы запросто сможете. Достаточно просто посмотреть на дорожную карту проекта со сроками окончания разработки.

72 Главное, что стоит понять сразу, - оценка и риски неразрывно идут друг за другом. Аналитика и особенно разработка не будет волноваться о рисках - просто потому, что ни первым, ни вторым не сдавать продукт в релиз. И не они будут находиться у финишной черты перед его выпуском в продакшен. Думать о рисках - именно ваша задача. Желаю успехов в тестировании!

73 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>