Comments 48
в целом любая команда должна складываться из разработчика+тестировщика+дизайнера
без одного из звеньев, мне кажется, проект собрать невозможно
Как разработчик, я не люблю тратить время на тесты, потому что:
Скучно. Это самый весомый фактор. В ряде компаний нельзя сказать при найме "знаете, я умею писать тесты, но не хочу", потому что это красная линия. Но если на разработку тестов я буду тратить значительное количество времени — скорее всего, я задумаюсь над поиском чего-то более интересного. К счастью, сейчас в текущем проекте есть отдельные инженеры, которые занимаются написанием тестов по готовому дизайну программной части. Лучше всего с этим обстоят дела в больших продуктовых энтерпрайзных компаниях. Парадоксально, но медленные циклы разработки как раз не кажутся скучными, а, скорее, обдуманными и взвешенными.
Моё время стоит дороже, чем время тестеров. Нет, я сейчас не волнуюсь за деньги компании. От того, чем я занимаюсь, сильно зависит повышение моей ценности, как специалиста. Скажем, какой смысл серьёзно повышать сотрудника (в финансовом и организационном плане), который тратит значительное количество времени на тесты, с написанием которых справится менее квалифицированные коллеги?
Взгляд замыливается.
Могу быть невнимательным при однообразной работе. Следствие пункта №1.
Довелось побывать в разных ситуациях, и человеком-оркестром тоже. Кесарю - кесарево, как говорится.
P.S. Вышеизложенное никак не касается Free Software, потому что кто ещё напишет нам тесты, как не мы сами?
В ряде компаний нельзя сказать при найме "знаете, я умею писать тесты, но не хочу", потому что это красная линия.
Да, я пару месяцев назад на интервью ляпнул "даже несмотря на то, что не люблю писать тесты, тут я бы точно написал". Дальше было падение в кроличью нору, т.к. оказалось, что один из интевьюирующих ЛЮБИТ писать тесты. Чтобы остановить падение, пришлось предъявить свой код, где я таки написал под пол сотни property-based тестов. Про статью на Хабре заикнуться я так и не решился. :-)
Так что я лично беседовал с человеком, который любит писать тесты. Такие есть!
Во многих проектах сейчас нет тестировщиков как таковых. Мой личный опыт показывает, что как в небольших стартапах, так и в больших серьезных компаниях, например, уровня Мейла, модульные и интеграционные тесты для бекэнд сервисов пишут сами разработчики. С таким подходом проекты живут годами и не испытывают больших проблем с тестированием.
А в чем, собственно выигрыш? Был тестировщик + разработчик, которые закрывали фичу за время T и зарплату 2*X, остался один разработчик-он-же-тестировщик, который закрывает фичу за время 2*T и, опять-же, зарплату 2*X.
Плюс потери времени на переключение контекста и риски из-за отсутствия второго взгляда и авторского предубеждения, что всё должно работать.
Мой личный опыт показывает, что как в небольших стартапах, так и в больших серьезных компаниях, например, уровня Мейла, модульные и интеграционные тесты для бекэнд сервисов пишут сами разработчики.
Можете рассказать как это работает?
Допустим аналитик или тимлид написал требование. Программисты выполнили его и написали тесты на то что выполнили. Но они во-первых не поняли часть задачи, во-вторых учли не все. Если в команде присутствует тестировщик, который по своей сути немного и аналитик, то он может мысленно представить себя в шкуре заказчика и найти множество проблем в результатах выполнения требований. Затем после тестировщика результаты посмотрить тимлид или аналитик, чтобы понять окончательно - получилось ли то что нужно.
Если тестировщика нет, тогда получаем продукт, который проходит тесты. И дальше аналитику или тимлиду надо тратить время на то чтобы выловить все что связано с недопониманием требований и недоучетом всех подводных камней. В итоге эти люди по сути превращаются в тестировщиков.
Значит в команде "немного аналитиками" должны быть или программисты (тогда они не только напишут тесты но и проверят прдукт с точки зрения пользователя) или тестировщики (тогда они заставят программистов довести продукт до замысла, изложенного в требованиях аналитиком).
Вариант когда программисты обходятся автотестами (вы пишете "нет тестировщиков как таковых") я не могу представить практически. Возможно это годится для каких-то специфических задач?
Мы это делаем примерно так https://www.youtube.com/watch?v=DR-lxv5UENg В докладе так же есть примеры из других компаний, которых уже достаточно много, чтобы уже можно было представить это практически :-)
Просмотрел. На мои проблемы не очень ложиться. Возможно прооблема в том, что мы работаем в области автоматизации, где программисту бывает сложно понять проблему целиком и он предпочитает работать в рамках требования. Т.е. если мы пишем интернет магазин, то программисту легко понять задачу. Если пишем некий абстрактный фреймворк, то у программиста нет выбора кроме как понять как этот фреймворк работает, Но мы пишем прикладной софт. Если он простой - проблем нет. Если все становится сложнее, тогда программист плохо понимает что он пишет и с первого раза он пишет лишь бы что, а потом надо много итераций чтобы собрать то что написали разные разработчики в что-то похожее на правду. Эта дыра затыкается постановщиком или тестировщиком. Если тестировщика нет, все валистя на постановщика, ему без конца сдают работу в которой ничерта еще не работает и разработка идет очень туго. Тестировщик прикрывыает более дорогого постановщика от вылавливания тривиальных проблем.
Чувстсвую, что здесь что-то не правильно, но как это улушить - не могу пока найти ответ.
Один вариант - не реализовывать таких сложных прикладных концепций в продукте. Но иногда без них никак.
Другой вариант - заставить программистов лучше понимать предметную область и таким образом повысить изначальное какчество того что они делают. Но в большинстве случаев у программистов сводит зубы от скуки от необходимости изучения всех традиций и тонкостей из предметной области. Т.е. это большой демотиватор для большинства.
Должен быть третий вариант, но я не могу его никак нащупать.
Написание тестов самими разработчиками вполне рабочая парадигма, достаточно часто используемая компаниями, которая стимулирует разработчиков писать более качественный код. Тот же яндекс плавно движется в эту сторону, уже повесив на разрабов написание тесткейсов.
Как писал тут Jef239, если разработчик считает, что 2*2=5, он напишет это и в тесте, и в коде.
Поэтому качестве сервисов Яндекса стало падать, а на фронте того же кинопоиска иногда вылазят абсолютно идиотские ошибки?
Такое чувство, будто сейчас все компании движутся в сторону ускорения поставки продукта. И для этого пытаются оптмизировать процессы. Например, сократив количество тестировщиков, при этом разработчики пишут только функциональные и юнит тесты
Ваша "разъясняющая" статья перестает быть сколь-нибудь полезной в тот момент, когда валит в одну кучу все возможные виды тестирования. Их много и ими должны заниматься несколько разные специалисты.
Ну а если кто считает, что все же разработчик должен заниматься всем тестированием на свете, то такой человек просто отрицает принцип разделения труда.
Раз уж подняли эту тему, вот вам забавное эмпирическое наблюдение про культуру оплаты труда QA:
в командах, где компенсация инженеров тестирования примерно соизмерима с разработчиками, и все об этом знают, последние плодят меньше багов на фичу и лучше тестируют свою работу сами перед "официальной" передачей в тестирование.
В командах, где разработчики получают (или думают, что получают) в разы больше, регулярно встречался с тем, что разработчики не то, что не хотят писать хотя бы unit-тесты, если палкой не заставляют, так могут отдать в тестирование вообще не работающую сборку/несобираемый код итд.
Предпологаю, что фактор психологический, т.к. в первых командах разработчики больше ценят время тестеровщиков как полноценных коллег.
Хотя на истинность наблюдений не претендую.
Я бы еще дополнил тем, что у тестировщика и разработчика противоположные цели. Одному надо сдать готовый код, другому - не допустить этого. Из их противостояния складывается результат.
Я бы разделил мобильную разработку от разработки web(web UI и API). У меня нет опыта мобильной разработки, я знаю что отделы мобильного тестирования в больших компаниях могут достигать размеров в несколько десяток человек, почему так и всегда ли так будет, мне к сожалению, не известно.
Но в web-разработке уже много лет сами разработчики осознанно отходят от практики использования специальных отдельных людей не то что для тестирования, а для обеспечения качества вообще. Я специально собрал несколько таких примеров в докладе про качество и time-to-market https://www.youtube.com/watch?v=DR-lxv5UENg
Процесс тестирования отличается — да, там тоже пишется код, но подход другой. Это как предложить повару из ресторана печь только пирожки
Забавно, что пример корректный, но противоречит общей риторике. Т.е. наверное повар из ресторана уж пирожки то хорошо будет печь, пусть ему и будет скучно )
Разработчик может заменить тестировщика (выполнять его работу, если потребуется), а тестировщик разработчика — нет
Не сможет - ему будет скучно и он предпочтёт уволиться.
Можно или делать всего понемногу, но плохо, или что-то одно, но хорошо
ИМХО, опыт разработки и опыт тестирования синергичны
Соглашусь, что синергичны, и не соглашусь, что тестеровщик не может выполнять работу если потребуется - если опыта тестеровщика достаточно, а задача не рокет-сайнс, то может (при наличие формальных прав конечно). И самому пару раз приходилось, и видел у коллег. Просто такая работа, даже если будет сделана качественно, будет сделана со скоростью джуна-девелопера. Просто из-за того, что QA даже зная "как писать" имеет меньше опыта с инструментами (банально шоткаты в идешке), хуже знает код-базу проекта (будет искать по проекту там, где вы точно знаете где, имеет особенности ментальности из-за которой перепроверит каждый свой метод руками, а потом еще нахлобучит юнитов, даже если это будут единственные юниты в проекте (лол, такое было кстати!)
Так и разработчик, если ему дать действительно сложную задачу в тестировании, например "локализировать плавающий баг в распределенной системе по неполному и неточному описанию от саппорта и настроить стенд с гарантированным воспроизведением" при достаточном опыте справится, но времени потратит в разы больше.
Без дополнительного обучения, увы нет. Т.к. кроме самой простой проверки функциональности с положительным результом, есть ещё и негативные тесты, и не только. Как показывала практика, разработчики умеющие писать хороший код, тестировали плохо.
Но здесь наверное ещё стоит понимать что тестировщик тестировщику рознь, и всё таки в моем понимании, тестировщик это как очень прошаренный пользователь, знающий продукт и понимающий слабые места с точки зрения логики поведения программы. (тоесть не просто тест ради теста, а тестирование, предложение улучшений, иногда даже смена логики или шагов). Всё таки это немного другой тип мышления. И не каждый может стать хорошим тестировщиков, равно как и хорошим разработчиком не каждый. Зато посредственным может стать каждый, даже не отвечающий за продукт человек.
Тесты, это скучно. Это отнимает время от работы над фичами.
Получается, что ты бесконечно пишет код - сначала фичи, потом тесты на них, потом новые фичи, потом...исправляет тесты на первые, так как что-то поменялось. Без передышки. А менеджерам так то пофигу на тесты, им скорее фичи подавай, поэтому в какойн момент можете обнаружить, чтобы вы в мыле.
В идеале конечно, нужен отдельный человек. В стартапах вообще нет смысла в тестах, так как все сильно быстро меняется и надо постоянно внедряь фичи
Юнит- тесты, безусловно, должны писать разрабы. А интергацию и е2е отдельные специалисты. Потому, что:
Это отнимает прилично времени (а если нет, ваши тесты, скорее всего, не очень).
Не должен замыливаться глаз.
Проект автотестов - тоже сложный проект, как правило, со своим или честно сп..ным фреймворком, который надо поддерживать и развивать.
В общем, автотестов - отдельная сфера компетенций, которые требуют актуализации, и где есть свои подводные рифы, известные спецам.
еще, если интеграцию пишет отдельный специалист, и этот специалист найдет баг между двумя модулями, каждый из которых вроде как проходит свои юниты, и написанны двумя разными людьми/командами, он может выступить медиатором между сторонами в переговорах, кто, почему и в какие сроки будет это фиксить. Часто проблема не стоит и выеденного яйца, но иногда прям важно иметь такого человека сразу, а не когда конфиликт уже не управляем.
Господа разработчики, как там, с головы корона не падает? "Скучно", "мое время дороже"
Я попробовал поработать в конторах с самыми разными процессами, и самый лучший вариант, что я видел - это когда овнершип вертикальный - you build it, you test it, you run it. Тестировщики, админы, архитекторы - не нужны, это все прекрасно совмещается в одной роли, а если у кого-то не совмещается - что ж, это ваше направление роста.
Из общедоступных продуктов, сделанных подобным образом, вспоминается только Facebook - и это треш
Ну, я не буду спорить с тем что фб - это отвратительная помойка, и как продукт, и как явление в целом.
Но вы подумайте насчет той гигантской инфраструктуры, что все это крутит - с ней-то у них полный порядок.
А часто ли используются инфраструктурные продукты Facebook за пределами самой Facebook? Пытались они продвинуть в массы React, закончилось фейлом
А причем тут их внешние самостоятельные продукты, тащемта?
За каждой видимой фичей стоят сотни сервисов под капотом, и все это в целом очень хорошо работает, очень сложно обвинять фейсбук в плохой стабильности и доступности.
И это с учетом того, что каждый день они катают, не знаю, тысячи изменений в прод.
В итоге выходит что фб как раз пример, как такой подход работает. По крайней мере, на достаточно большом масштабе :)
Господа разработчики, как там, с головы корона не падает?
Зачем разменивать свой профессионализм на неинтересные вещи, если за углом очередь из HR и разномастных проектов, и есть из чего выбирать?
Тестировщики, админы, архитекторы - не нужны, это все прекрасно совмещается в одной роли
У вас одно видение идеальной команды, у меня другое. Ничего плохого нет в том, что мы найдём себе единомышленников и будем работать в комфортной среде.
а если у кого-то не совмещается - что ж, это ваше направление роста.
Эту фразу можно применить к любой профессии.
Мне вот этот подход "я просто пишу код, я в этом хорош, а тестировать его - эт не мое дело, пусть другие люди этим занимаются" напоминает анекдот про "печатаю со скоростью 4000 знаков в минуту, но такая ерунда получается"
Но да, вы безусловно правы — ситуация такова, что индустрия щас трудоустроит всех кто хотя бы знает с какой стороны на клавиатуру надо жать.
Тесты есть в обоих случаях, только пишут их разные люди. Также предполагается, что есть code review. Поэтому коррелляция между качеством кода и собственноручным написанием тестов неочевидна. В обоих случаях можно написать как полную ерунду (вместе с тестами), так и качественный код.
За ерунду хорошие деньги не платят.
Корелляции действительно может и не быть, однако главные профиты тут:
это ускорение обратной связи за счет убирания заборов, через который все кидают друг другу куски продукта
отсутствие размытия владения продуктом, код не отчуждается от инженера в руки QA, который его протестируют и передаст какому-нить админу, который его подеплоить и поонколлит
Впервые слышу о такой профессии. Есть бета-тестировщики, есть QA.
QA- входить в отдел разработки, и программируют они не меньше программистов.
А бета-тестеры - это не проффессия.
Почему разработчик не может быть тестировщиком (или может?)