Есть у меня рубрика - #очевидные_вещи. Суть - описать коротко и убедительно те вещи, которые понятны любому разработчику с относительно небольшим стажем, но совершенно не очевидны начинающим и людям других профессий.
Эта статья в основном для менеджеров компаний\руководителей стартапов, которым нужно решить — выделять ли отдельный бюджет на должность "тестировщик" или доплатить за часы разработчика?
Тестировщик — это
профессионал, который проверяет, адекватно ли приложение ведет себя в различных пользовательских сценариях на различных устройствах и версиях ОС
Дисклеймер
Да, разработчик может быть тестировщиком. Даже может тестировать результат своей работы. Даже может убеждать вас, что тестировщик не нужен.
Но на мой взгляд есть весомые причины, по которым стоит нанять отдельного специалиста.
Весомые причины нанять отдельного специалиста
Это эмпирические выводы, но полученные на анализе своего опыта коммерческой разработки.
"Умеет разрабатывать" не равно "умеет тестировать"
Учиться тестировать надо отдельно. Далеко не каждый разработчик умеет грамотно писать различные виды тестов, покрывать все юзер-кейсы, автоматизировать процесс.
Да, мы все знаем как это делается в теории, но на практике опыт есть далеко не у всех, потому что это другая профессия.
Soft vs Hard
Для тестировщика крайне важны софт-скилы. По той причине, что тестировщик должен уметь писать хорошие отчеты, структурировать полученные полуэмперические результаты, описывать в подробностях предпосылки и последствия.
Не каждый разработчик захочет и сможет написать хороший лонгрид-вывод по проделанной работе. Он скорее придумает нейросеть, которая будет это писать за него.
Найти ошибки в своей работе всегда сложнее, чем в чужой
Подсознательное "это мое, я не мог ошибиться" и более страшное "я точно уверен, что оно будет работать, ведь я помню все строчки кода, там точно есть все нужные проверки" будут постоянно вызывать желание пропустить какую-то часть тестирования.
Любит разрабатывать, а не тестировать
Большинство программистов гарит желанием именно "разрабатывать" - писать код, строить архитектуру, держать в голове сложные связи макаронного кода, ревьюить код...
Процесс тестирования отличается - да, там тоже пишется код, но подход другой. Это как предложить повару из ресторана печь только пирожки - он может, но, скорее всего, не хочет и будет делать это некачественно.
Профдеформация
Программист видит созданный своими руками продукт насквозь и пользуется им, обладая этим виденьем.
А обычный юзер будет видеть приложение другими глазами. И только тестировщик, не занимающийся разработкой продукта, может взглянуть почти теми же глазами, что и пользователь → тестировщик с большей вероятностью покроет все реальные юзер-кейсы.
Деньги
Тут могу ошибаться, но обычно час тестировщика стоит дешевле часа разработчика (на сколько это правильно - вопрос на ветку в 300кк комментариев). Соответственно, вам просто не выгодно, чтобы разработчик тратил время на тесты.
Весомые причины не нанимать тестировщика
Я смог придумать только две:
никто не знает продукт лучше, чем тот, кто его разрабатывал. именно разработчику известны наиболее слабые или чувствительные точки;
программист может делать хорошие тесты (если потратит время на обучение), но только если будет уверен, что его работу оценят, оплатят и не будут ругать за количество найденных багов (сделанных им же и его коллегами).
Выводы
Я уверен, что на любом проекте должен быть штатный тестировщик. И он должен быть поддерживать тесное общение и с менеджером, и с разработчиком.
Потому что какой-то крутой не был код, главное, чтобы пользователю было не больно пользоваться конечным продуктом. А уследить за этим может только тестировщик. Имхо)
Еще #очевидные_вещи и про мобильную разработку в tg-канале - t.me/dolgo_polo_dev.
Комментарии (46)
Mishima_Zaibatsu
28.12.2021 03:27+4Как разработчик, я не люблю тратить время на тесты, потому что:
Скучно. Это самый весомый фактор. В ряде компаний нельзя сказать при найме "знаете, я умею писать тесты, но не хочу", потому что это красная линия. Но если на разработку тестов я буду тратить значительное количество времени — скорее всего, я задумаюсь над поиском чего-то более интересного. К счастью, сейчас в текущем проекте есть отдельные инженеры, которые занимаются написанием тестов по готовому дизайну программной части. Лучше всего с этим обстоят дела в больших продуктовых энтерпрайзных компаниях. Парадоксально, но медленные циклы разработки как раз не кажутся скучными, а, скорее, обдуманными и взвешенными.
Моё время стоит дороже, чем время тестеров. Нет, я сейчас не волнуюсь за деньги компании. От того, чем я занимаюсь, сильно зависит повышение моей ценности, как специалиста. Скажем, какой смысл серьёзно повышать сотрудника (в финансовом и организационном плане), который тратит значительное количество времени на тесты, с написанием которых справится менее квалифицированные коллеги?
Взгляд замыливается.
Могу быть невнимательным при однообразной работе. Следствие пункта №1.
Довелось побывать в разных ситуациях, и человеком-оркестром тоже. Кесарю - кесарево, как говорится.
P.S. Вышеизложенное никак не касается Free Software, потому что кто ещё напишет нам тесты, как не мы сами?
vkni
28.12.2021 07:13+1В ряде компаний нельзя сказать при найме "знаете, я умею писать тесты, но не хочу", потому что это красная линия.
Да, я пару месяцев назад на интервью ляпнул "даже несмотря на то, что не люблю писать тесты, тут я бы точно написал". Дальше было падение в кроличью нору, т.к. оказалось, что один из интевьюирующих ЛЮБИТ писать тесты. Чтобы остановить падение, пришлось предъявить свой код, где я таки написал под пол сотни property-based тестов. Про статью на Хабре заикнуться я так и не решился. :-)
Так что я лично беседовал с человеком, который любит писать тесты. Такие есть!
dopusteam
28.12.2021 10:38+1А почему бы и нет? Я тоже иногда люблю писать тесты, которые покрывают какой то сложный кусок кода, который при этом хорошо спроектирован и хорошо тестируем. В этом случае писать тесты может быть действительно приятно и интересно. Ну и полезно, само собой.
Sonntex
28.12.2021 04:47+3Во многих проектах сейчас нет тестировщиков как таковых. Мой личный опыт показывает, что как в небольших стартапах, так и в больших серьезных компаниях, например, уровня Мейла, модульные и интеграционные тесты для бекэнд сервисов пишут сами разработчики. С таким подходом проекты живут годами и не испытывают больших проблем с тестированием.
yarric
28.12.2021 12:47+2А в чем, собственно выигрыш? Был тестировщик + разработчик, которые закрывали фичу за время T и зарплату 2*X, остался один разработчик-он-же-тестировщик, который закрывает фичу за время 2*T и, опять-же, зарплату 2*X.
Плюс потери времени на переключение контекста и риски из-за отсутствия второго взгляда и авторского предубеждения, что всё должно работать.
amazed
28.12.2021 13:08+2Мой личный опыт показывает, что как в небольших стартапах, так и в больших серьезных компаниях, например, уровня Мейла, модульные и интеграционные тесты для бекэнд сервисов пишут сами разработчики.
Можете рассказать как это работает?
Допустим аналитик или тимлид написал требование. Программисты выполнили его и написали тесты на то что выполнили. Но они во-первых не поняли часть задачи, во-вторых учли не все. Если в команде присутствует тестировщик, который по своей сути немного и аналитик, то он может мысленно представить себя в шкуре заказчика и найти множество проблем в результатах выполнения требований. Затем после тестировщика результаты посмотрить тимлид или аналитик, чтобы понять окончательно - получилось ли то что нужно.
Если тестировщика нет, тогда получаем продукт, который проходит тесты. И дальше аналитику или тимлиду надо тратить время на то чтобы выловить все что связано с недопониманием требований и недоучетом всех подводных камней. В итоге эти люди по сути превращаются в тестировщиков.
Значит в команде "немного аналитиками" должны быть или программисты (тогда они не только напишут тесты но и проверят прдукт с точки зрения пользователя) или тестировщики (тогда они заставят программистов довести продукт до замысла, изложенного в требованиях аналитиком).
Вариант когда программисты обходятся автотестами (вы пишете "нет тестировщиков как таковых") я не могу представить практически. Возможно это годится для каких-то специфических задач?
oneumyvakin
30.12.2021 13:32Мы это делаем примерно так https://www.youtube.com/watch?v=DR-lxv5UENg В докладе так же есть примеры из других компаний, которых уже достаточно много, чтобы уже можно было представить это практически :-)
Amokmorg
28.12.2021 06:06+3Написание тестов самими разработчиками вполне рабочая парадигма, достаточно часто используемая компаниями, которая стимулирует разработчиков писать более качественный код. Тот же яндекс плавно движется в эту сторону, уже повесив на разрабов написание тесткейсов.
vkni
28.12.2021 07:14+8Как писал тут Jef239, если разработчик считает, что
2*2=5, он напишет это и в тесте, и в коде.
Hivemaster
28.12.2021 09:42+3Поэтому качестве сервисов Яндекса стало падать, а на фронте того же кинопоиска иногда вылазят абсолютно идиотские ошибки?
Thseru
28.12.2021 18:41Такое чувство, будто сейчас все компании движутся в сторону ускорения поставки продукта. И для этого пытаются оптмизировать процессы. Например, сократив количество тестировщиков, при этом разработчики пишут только функциональные и юнит тесты
panzerfaust
28.12.2021 08:46+2Ваша "разъясняющая" статья перестает быть сколь-нибудь полезной в тот момент, когда валит в одну кучу все возможные виды тестирования. Их много и ими должны заниматься несколько разные специалисты.
Ну а если кто считает, что все же разработчик должен заниматься всем тестированием на свете, то такой человек просто отрицает принцип разделения труда.
seonn
28.12.2021 09:20+2Раз уж подняли эту тему, вот вам забавное эмпирическое наблюдение про культуру оплаты труда QA:
в командах, где компенсация инженеров тестирования примерно соизмерима с разработчиками, и все об этом знают, последние плодят меньше багов на фичу и лучше тестируют свою работу сами перед "официальной" передачей в тестирование.
В командах, где разработчики получают (или думают, что получают) в разы больше, регулярно встречался с тем, что разработчики не то, что не хотят писать хотя бы unit-тесты, если палкой не заставляют, так могут отдать в тестирование вообще не работающую сборку/несобираемый код итд.
Предпологаю, что фактор психологический, т.к. в первых командах разработчики больше ценят время тестеровщиков как полноценных коллег.
Хотя на истинность наблюдений не претендую.
s207883
28.12.2021 09:20+1Я бы еще дополнил тем, что у тестировщика и разработчика противоположные цели. Одному надо сдать готовый код, другому - не допустить этого. Из их противостояния складывается результат.
oneumyvakin
28.12.2021 09:22Я бы разделил мобильную разработку от разработки web(web UI и API). У меня нет опыта мобильной разработки, я знаю что отделы мобильного тестирования в больших компаниях могут достигать размеров в несколько десяток человек, почему так и всегда ли так будет, мне к сожалению, не известно.
Но в web-разработке уже много лет сами разработчики осознанно отходят от практики использования специальных отдельных людей не то что для тестирования, а для обеспечения качества вообще. Я специально собрал несколько таких примеров в докладе про качество и time-to-market https://www.youtube.com/watch?v=DR-lxv5UENg
MentalBlood
28.12.2021 09:34Процесс тестирования отличается — да, там тоже пишется код, но подход другой. Это как предложить повару из ресторана печь только пирожки
Забавно, что пример корректный, но противоречит общей риторике. Т.е. наверное повар из ресторана уж пирожки то хорошо будет печь, пусть ему и будет скучно )
MentalBlood
28.12.2021 09:40Разработчик может заменить тестировщика (выполнять его работу, если потребуется), а тестировщик разработчика — нет
yarric
28.12.2021 13:28Можно или делать всего понемногу, но плохо, или что-то одно, но хорошо
MentalBlood
28.12.2021 14:56ИМХО, опыт разработки и опыт тестирования синергичны
seonn
28.12.2021 16:12Соглашусь, что синергичны, и не соглашусь, что тестеровщик не может выполнять работу если потребуется - если опыта тестеровщика достаточно, а задача не рокет-сайнс, то может (при наличие формальных прав конечно). И самому пару раз приходилось, и видел у коллег. Просто такая работа, даже если будет сделана качественно, будет сделана со скоростью джуна-девелопера. Просто из-за того, что QA даже зная "как писать" имеет меньше опыта с инструментами (банально шоткаты в идешке), хуже знает код-базу проекта (будет искать по проекту там, где вы точно знаете где, имеет особенности ментальности из-за которой перепроверит каждый свой метод руками, а потом еще нахлобучит юнитов, даже если это будут единственные юниты в проекте (лол, такое было кстати!)
Так и разработчик, если ему дать действительно сложную задачу в тестировании, например "локализировать плавающий баг в распределенной системе по неполному и неточному описанию от саппорта и настроить стенд с гарантированным воспроизведением" при достаточном опыте справится, но времени потратит в разы больше.
Devakant
28.12.2021 21:12+2Без дополнительного обучения, увы нет. Т.к. кроме самой простой проверки функциональности с положительным результом, есть ещё и негативные тесты, и не только. Как показывала практика, разработчики умеющие писать хороший код, тестировали плохо.
Но здесь наверное ещё стоит понимать что тестировщик тестировщику рознь, и всё таки в моем понимании, тестировщик это как очень прошаренный пользователь, знающий продукт и понимающий слабые места с точки зрения логики поведения программы. (тоесть не просто тест ради теста, а тестирование, предложение улучшений, иногда даже смена логики или шагов). Всё таки это немного другой тип мышления. И не каждый может стать хорошим тестировщиков, равно как и хорошим разработчиком не каждый. Зато посредственным может стать каждый, даже не отвечающий за продукт человек.
themen2
28.12.2021 10:13-2Тесты, это скучно. Это отнимает время от работы над фичами.
Получается, что ты бесконечно пишет код - сначала фичи, потом тесты на них, потом новые фичи, потом...исправляет тесты на первые, так как что-то поменялось. Без передышки. А менеджерам так то пофигу на тесты, им скорее фичи подавай, поэтому в какойн момент можете обнаружить, чтобы вы в мыле.
В идеале конечно, нужен отдельный человек. В стартапах вообще нет смысла в тестах, так как все сильно быстро меняется и надо постоянно внедряь фичи
AlexeyALV
28.12.2021 13:03+3Юнит- тесты, безусловно, должны писать разрабы. А интергацию и е2е отдельные специалисты. Потому, что:
Это отнимает прилично времени (а если нет, ваши тесты, скорее всего, не очень).
Не должен замыливаться глаз.
Проект автотестов - тоже сложный проект, как правило, со своим или честно сп..ным фреймворком, который надо поддерживать и развивать.
В общем, автотестов - отдельная сфера компетенций, которые требуют актуализации, и где есть свои подводные рифы, известные спецам.
seonn
28.12.2021 17:14+1еще, если интеграцию пишет отдельный специалист, и этот специалист найдет баг между двумя модулями, каждый из которых вроде как проходит свои юниты, и написанны двумя разными людьми/командами, он может выступить медиатором между сторонами в переговорах, кто, почему и в какие сроки будет это фиксить. Часто проблема не стоит и выеденного яйца, но иногда прям важно иметь такого человека сразу, а не когда конфиликт уже не управляем.
miga
28.12.2021 20:13+2Господа разработчики, как там, с головы корона не падает? "Скучно", "мое время дороже"
Я попробовал поработать в конторах с самыми разными процессами, и самый лучший вариант, что я видел - это когда овнершип вертикальный - you build it, you test it, you run it. Тестировщики, админы, архитекторы - не нужны, это все прекрасно совмещается в одной роли, а если у кого-то не совмещается - что ж, это ваше направление роста.
yarric
28.12.2021 22:46Из общедоступных продуктов, сделанных подобным образом, вспоминается только Facebook - и это треш
miga
28.12.2021 23:22Ну, я не буду спорить с тем что фб - это отвратительная помойка, и как продукт, и как явление в целом.
Но вы подумайте насчет той гигантской инфраструктуры, что все это крутит - с ней-то у них полный порядок.
yarric
28.12.2021 23:56А часто ли используются инфраструктурные продукты Facebook за пределами самой Facebook? Пытались они продвинуть в массы React, закончилось фейлом
miga
29.12.2021 00:08А причем тут их внешние самостоятельные продукты, тащемта?
За каждой видимой фичей стоят сотни сервисов под капотом, и все это в целом очень хорошо работает, очень сложно обвинять фейсбук в плохой стабильности и доступности.
И это с учетом того, что каждый день они катают, не знаю, тысячи изменений в прод.
В итоге выходит что фб как раз пример, как такой подход работает. По крайней мере, на достаточно большом масштабе :)
yarric
29.12.2021 10:40все это в целом очень хорошо работает
Потому, что тестировщиками работают пользователи из других отделов?
miga
29.12.2021 11:07Они, конечно, могут заметить баги в соседних сервисах, но они не "работают" тестировщиками - не являются частью пайплайна доставки и не ответственны за качество сервиса.
Mishima_Zaibatsu
29.12.2021 21:04Господа разработчики, как там, с головы корона не падает?
Зачем разменивать свой профессионализм на неинтересные вещи, если за углом очередь из HR и разномастных проектов, и есть из чего выбирать?
Тестировщики, админы, архитекторы - не нужны, это все прекрасно совмещается в одной роли
У вас одно видение идеальной команды, у меня другое. Ничего плохого нет в том, что мы найдём себе единомышленников и будем работать в комфортной среде.
а если у кого-то не совмещается - что ж, это ваше направление роста.
Эту фразу можно применить к любой профессии.
miga
29.12.2021 21:08+1Мне вот этот подход "я просто пишу код, я в этом хорош, а тестировать его - эт не мое дело, пусть другие люди этим занимаются" напоминает анекдот про "печатаю со скоростью 4000 знаков в минуту, но такая ерунда получается"
Но да, вы безусловно правы — ситуация такова, что индустрия щас трудоустроит всех кто хотя бы знает с какой стороны на клавиатуру надо жать.
Mishima_Zaibatsu
29.12.2021 22:55Тесты есть в обоих случаях, только пишут их разные люди. Также предполагается, что есть code review. Поэтому коррелляция между качеством кода и собственноручным написанием тестов неочевидна. В обоих случаях можно написать как полную ерунду (вместе с тестами), так и качественный код.
За ерунду хорошие деньги не платят.
miga
29.12.2021 23:22Корелляции действительно может и не быть, однако главные профиты тут:
это ускорение обратной связи за счет убирания заборов, через который все кидают друг другу куски продукта
отсутствие размытия владения продуктом, код не отчуждается от инженера в руки QA, который его протестируют и передаст какому-нить админу, который его подеплоить и поонколлит
arTk_ev
29.12.2021 19:01-1Впервые слышу о такой профессии. Есть бета-тестировщики, есть QA.
QA- входить в отдел разработки, и программируют они не меньше программистов.
А бета-тестеры - это не проффессия.
AndreySlonov
в целом любая команда должна складываться из разработчика+тестировщика+дизайнера
без одного из звеньев, мне кажется, проект собрать невозможно
GospodinKolhoznik
deleted
amazed
А что с аналитиком? Кто будет ставить задачи?