Комментарии 73
Разработчики не умеют тестировать
Они не просто не умеют тестировать. Они тестируют то, что работает.
Все дело именно в том, что разраотчик писал этот код. Если бы ему пришла в голову мысль, что здесь что-то может пойти не так, он бы поправил это в коде. А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Разработчики должны писать внутренние тесты. Но они не для проверки, а для будущей разработки — рефакторинга, доработки.
А внешние тесты, для проверки должен и писать внешний человек — тестировщик.
Они тестируют то, что работает— согласен, но автор статьи писавший провокационный заголовок, об этом забыл и сосредоточился на профитах:
- облегчить жизнь тестировщикам (ошибка — их человекочас обычно дешевле чем человекочас разработчика)
- ускорить выпуск релизов за счет устранения регресса (ошибка — разработчик покроет тестом фичу, но интегрально приложение развалится в неожиданном месте)
Мораль: от регресса производимого тестировщиками не уйти
Но в данном случаи речь речь не про облегчение или усложнение жизни или уход от регресса, как правило регресс можно просто покрыть автоматизаций, были бы свободные руки и желание. Речь о процессе в целом, в данном случаи нужно оценивать общий профит или его отсутствие, а не конкретного звена :D
Это если сначала код писать.
Если сначала написать тесты, то они будут тестировать то, что будет работать. То, что не будет — все равно останется за бортом.
Отчего же? Я пишу не только положительные случаи, но и пачку quick property based. Написать их легко, кейсы придумывать не надо. Только свойства описывать, которые и есть инварианты программы.
Так же ж… Я про то, что мешает добавлять quick тестирование, которое сродни whitebox fuzzing.
Если разработчик сообразил, что кто-то может указать там 0, то он и проверку в коде сделает и тест с 0 напишет.
Если не сообразил — не сделает ни того, ни другого.
Мы начали с того, что разработчик если будет писать тесты, то напишет только на положительные кейсы.
Собственно, если начинаешь с тестов, то нет никакого "сообразил-не сообразил", есть описание спеки в виде тестов. Часть их них превратится в инварианты для более глубокого тестирования перебором.
Если же разработчик не в состоянии начать со спеки, то это уже фигак и в продакшн, тут медицина бессильна.
В спецификации написано — «вес коробки». Всем же известно, что в реальной жизни вес положительный. Так?
Немного не так работает. Начав с теста поймёшь, что нет описания веса коробки — тест не написать. Придется писать письма, топать ножками и дорабатывать спеку и переносить в тесты. Где система типов помощнее, там сразу в тип.
Хорошо, если условие такое очевидное — 0. А если 3,14? Или -1?
Да, в коде (или в ТЗ) будет деление (например) на x+1. Если разработчик это заметит, то он и в коде проверку напишет и в тесте. Если нет — ни там, ни там. И это не зависит от того, что он пишет сначала — код или тесты.
Т.е., тесты, написанные разработчиком, не найдут его ошибки.
А значит, нужно независимое от разработчика тестирование.
Вот все, что я хочу сказать.
Но, так-то, да. Хорошо бы сначала написать подробное ТЗ со спецификациями, потом тесты, потом код, потом документацию. Где-то в идеальном мире…
Я только про то, что тесты все равно будут написаны только на те случаи, что обработаны в коде. Не выявят ошибок, неожиданных для программиста.
Типов тестов много разных и каждых из них решает свои задачи.
Ну не выявят неожиданных ошибок. Выявит тестировщик или пользователь, будет заведен дефект при закрытии которого появится новый тест. Обычный процесс.
Поэтому требовать от разработчика написания тестов именно для проверки новой функциональности — бессмыслено.
Также новая функциональность может быть разная по сложности тестирования, к примеру если добавляется новый фильтр в приложение и нет ни одного теста на другие фильтры — в этом случаи могут возникнуть вопросы по тестированию. И наоборот, если добавляется новый фильтр и уже есть тесты на все остальные фильтры — в этом случаи написать тесты будет просто. Чем больше кодовой базы в автоматизации, тем проще писать последующие тесты на новый функционал(:
Про Unit-тесты, хорошее замечание, но как показывает практика часто они вовсе отсутствуют.
Стратегия тестирования это скорее работа QA, чем тестировщика и там не только тесты. Задача тестировщика вовремя предоставлять качественную обратную связь, и она не сводится к одной лишь автоматизации.
А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Тестировщик подскажет :)
Можно сначала согласовать приемочные тесты командой, потом, разработчик разрабатыает пишет тесты, потом exploratory тестирование тестировщиком, если находит глюки разработчик фиксит и пишет тесты.
То, что кто-то пишет тесты не означает что он их придумывает с самого начала.
А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Есть непроверенная гипотеза, что сам процесс написания теста вынуждает подумать о граничных условиях. Кроме того, написанный тест позволяет быстро прогнать свой код на разных входных данных — мне случалось так ловить ошибки столь же элементарные сколь и неочевидные
это антипаттерн "позитивное тестирование". Далеко не все разработчики ему подвержены
Ошибка.
Именно так и происходит: когда разработчик начинает писать тест, его мозг переключается из "созидательного" в "критический" режим, и он начинает придумывать разные ситуации, в которых его код может сломаться. Это помогает не только тесты написать, но и тут же улучшить код, не дожидаясь всего этого долгого процесса релиза/установки/тестирования/багфикса.
См. https://www.youtube.com/watch?v=8u6_hctdhqI&feature=youtu.be&a
2. Тестировщики пишут системные тесты.
3. Сценарии тестов (и функциональных и системных) обсуждаются тестером и разработчиком, чтобы:
- не пропустить какой-нибудь кейс;
- не писать дорогой системный тест на то, что можно проверить функциональным;
- подложить соломку в том месте, где в будущем потенциально может что-нибудь сломаться (когда есть какие-нибудь хитрые взаимосвязи фронта и бэка).
Функциональные тесты может и тестировщик писать и разработчик.
Системные тесты пишет тестировщик
Тестировщики должны придумывать тестовые случаи, о которых PM и разработчики даже не подумали бы – собственно для этого они и нужны.
Есть старый холивар на тему, кто же должен писать тесты: разработчики или тестировщики. Вроде как если в команде есть тестировщики, то логично, что тесты пишут они, правда?Подобная формулировка вопроса заранее предполагает холивар, либо автор просто не разбирается в различных видах тестирования.
И тесты которые отлавливают регрессию разработчики вполне себе успешно пишут.
Другое дело, что я предпочитаю у себя в командах разделять тех кто пишет код и тех кто этот код покрывает тестами. Так эффективнее получается.
И да, я не против тестировщиков :)
Разработчику полюбому придется писать тесты, иначе как понять, что то, что написано, как минимум работает. Плюс хороший разработчик должен уделить какое-то время, перед тем как передвигать задачу в review, "а что если произойдет то, или это", нестандартные какие-либо ситуации, написать тесты на эти ситуации, проверить ожидаемое поведение.
Разработчик сможет протестировать низкоуровневые части, тестировщику на это потребуется слишком много времени и головной боли.
Тестировщик, в свою очередь, может отлично протестировать высокоуровневые вещи, написать интеграционные тесты на том же python.
Часто разработчик может не обладать достаточным профессионализмом в той сфере, в которой работает компания. И тот третий человек, кто разбирается в узкой специализации, но не разработчик или тестировщик, вместе с описанными выше профессионалами, в идеале, имхо, должны работать вместе, создавая идеальный продукт.
А) аналитики должны писать тест-кейсы, а не все остальные.
Б) тесты разные бывают. Есть те, где только разработка справится. Есть те, где разработчики только мешают.
И время не выделяют, и денег всегда недостаточно…
Кто требования продумывает, тот тест-кейсы и должен писать, бо он знает, что ему нужно получить в итоге и как убедиться в том, что достигнут нужный результат.
Профессия тест-аналитика идëт следом, как и профессия тест-дизайнера.
В наше время всë то, что касается тестирования, сведено к одному юниту, вроде как бизнес-оптимизация получилась. Заявить "А я тест-дизайнер" уже кагбэ глупо, что там дизайнить, вас что, пэирвайз укусил? Просто протестируйте это чертово приложение…
В башнях-близнецах, которые схлопнули 9/11, сидели очень грамотные бизнес-аналитики, которые для Reuters софт и требованиями, и тест-кейсами обкладывали. Проходить их было скучно, бо очень уж детально всë и годами ничего не изменяемое, но это были, наверное, лучшие тесты ВООБЩЕ. Но те аналитики умерли, а новые башни не выстроили.
В обычном IT аналитики такого уровня не нужны так же, как и отдельные тест-дизайнеры, поэтому [дальше ваша схема без изменений]…
Кто требования продумывает, тот тест-кейсы и должен писать, бо он знает, что ему нужно получить в итоге и как убедиться в том, что достигнут нужный результат.
И часто вы видели людей, которые придумывая требования — продумывает не только основой набор сценариев, как должно работать, но и сценарии, как обрабатывать не стандартные ситуации? Т.е. понято что в итоге спрашивать придется у этих людей, но должен же быть кто-то, кто задаст такие вопросы?
Профессия тест-аналитика идëт следом, как и профессия тест-дизайнера.
В наше время всë то, что касается тестирования, сведено к одному юниту, вроде как бизнес-оптимизация получилась. Заявить «А я тест-дизайнер» уже кагбэ глупо, что там дизайнить, вас что, пэирвайз укусил? Просто протестируйте это чертово приложение…
Проверить одно и то же 10 тестами или 50-ю? Действительно, чего там дизайнить.
В башнях-близнецах, которые схлопнули 9/11, сидели очень грамотные бизнес-аналитики, которые для Reuters софт и требованиями, и тест-кейсами обкладывали. Проходить их было скучно, бо очень уж детально всë и годами ничего не изменяемое, но это были, наверное, лучшие тесты ВООБЩЕ. Но те аналитики умерли, а новые башни не выстроили.
Не очень понял к чему тут это.
В обычном IT аналитики такого уровня не нужны так же, как и отдельные тест-дизайнеры, поэтому
… поэтому х-к, х-к и в продакшен.
И часто вы видели людей…
Редко. Но мы говорим о том, как оно должно быть, или о том убожестве, которое бытует в современных офисах?
Люди, которые умеют работать с требованиями, тестируют их намного лучше тестировщиков. И обрабатывают сценарии во все стороны, и находят нестандартные ситуации намного лучше, чем сторонние тестировщики, бо они в теме (в отличие от).
В итоге сложные решения не тестируют всеобъемлюще, для бизнеса Happy path это good enough. Каждое решение имеет свою цену («Just avoid holding it in that way» Steve Jobs).
Действительно, чего там дизайнить.
Много чего.
Я раньше состоял в секте свидетелей пэирвайза, который каким-то хитрым образом позволяет вместо тысячи тысяч тестов сделать всего условно 30, при этом волшебным образом обеспечивая полное покрытие и счастье всех тестировщиков. Потерял на этом здоровье и квартиру, от меня ушёл мой несуществующий пёс и весь мой биткоин превратился в простой молдавский лей.
Но потом я прозрел, бросил эту секту неудачников и записался в секту тестировщиков, подозрительных к пэирвайзу (она ближе к метро, очень удобно). Там мне стало понятно, что само по себе тестирование — ерунда, и что всё тестирование начинается и делается там, где работают с требованиями. Это первоисточник, из которого начинаются и верификация, и валидация, и S.M.A.R.T, и тест-дизайн, и как работают все техники тест-дизайна, и прочее.
Вступайте в нашу секту аналитики в тестировании!
х-к, х-к и в продакшен.
Да, в большинстве случаев приложение имеет заказчика, у которого средства могут исчерпаться в любой момент.
Заказ на разработку почти никогда не делается в режиме «У нас есть мешок денег, сделайте нам ПО». Это больше похоже на подписку на ипотеку — мы хотим что-то, что в принципе будет стоить большой мешок, давайте начнём это делать частями, частями же и будем оплачивать.
Разработка действует в том же стиле. Вон, Роберт Мартин писал, что в доисторические времена программисты очень обрадовались идее ватерфолла, мол, наконец-то придёт порядок, сперва будет работа с требованиями, затем кодирование по ним (а не по внезапным добавкам с изменениями), затем релиз, граждане довольные расходятся по домам. Но нет, не работает это дело, и не будет работать по ряду причин, среди которых первое — человеки. Всегда приходится что-то куякать в продакшн и надеяться, что не поломается.
Затем приходит поколение, которому с самого начала втолковывают, что надо писать софт ровно до того места, как он пройдёт юнит-тесты (не факт, что адекватные), и на этом объявлять задачу выполненной. В прод.
Затем приходит поколение, которое закомментирует уже эти юнит-тесты, бо они раздражают и мешают работать. Сразу в прод. Там фреймворк, там леший бродит, мы туда не вмешиваемся.
Где и кому (и для чего) во всей этой схеме нужны тестировщики?
Тесты должна писать разработка.
Прод должно писать тестирование.
Конечно, всё в меру. В случае с тестами от разработчиков в этой статье кейс рассмотрен. В целом, профит есть. И как я думаю, прежде всего от плотной коммуникации между разработчиками и тестировщиками. Запросто, можно представить как тестировщик, глядя на результаты тестов, предлагает разработчикам решение фичи, с определённой степенью детализации. А для этого он должен погрузится в устройство прода поглубже с помощью/обучением от разработчиков.
Встречал когда тесты перекидывали на тестировщиков.
Разработчики писали небрежный код зная, что тестировщики отловят.
Встречал когда тесты вешали на разрабов. Саботировали — добавляли на тесты неадекватное время, чтоб не делать скучную работу.
Важен тренинг и диалог между тестером и разрабом, когда разраб при работе над тикетом выбирает тестировщика и в паре закрывают тикет.
Получалось продуктивно.
каждая строка имеет условие для выпадения в ошибку
github.com/mpak2/bmf/blob/master/bmf.cpp
Разработчики уже тестируют свой код. И я сейчас не про юнит тестирование. Я работаю в сфере, где юнит тестирование не возможно.
Но все разработчики проверяют свои модули на определенных тестовых данных.
Берут типичные модели запросы и прочее и тестируют свою программу. Более того. От части это правда, что разработчику проще писать тесты. Они видит всю цепочку взаимодействий и может исходя из нее предположить ошибку.
Но против того, чтобы на него и возложить эту ответственность есть 3 НО.
Отсутствие комплектности
Как правило люди до серверов, а иногда и после сеньоров. Работают на одном конкретном модуле. И разрабатывая один модуль, ты знаешь только его, поверхностно знаешь остальные модули, и даже не знаешь как тестировать свой код на взаимодействия с ними? Какие там могут быть опасные ситуации? Какие негативные данные от туда могут прийти?
Да не знает никто. И по опыту скажу.
Как только пишется взаимодействие двух модулей, жди 100500 ошибок. Будет вот так.
![image](https://habrastorage.org/getpro/habr/comment_images/872/02d/bb7/87202dbb7908e7930e9807896d69559d.webp)
В то время как даже джуниор тестировщики уже начинают работать с программой комплексно. То один модуль то другой модуль, идут по пользовательским цепочкам и т.д.
И если разработчик может еще тестировать свой модуль. Тестировать ВСЮ систему он не способен.
НО. Для тестирования нужен свежий взгляд. Один человек должен проверять другого человека. Именно по этому есть Альфа тестирование и бета тестирование. Помимо массовости это в первую очередь дает взгляд будущих простых пользователей. Люди ошибаются в первую очередь не в коде. А в гипотезах. Я думал что пользователь может ввести цифры. А он еще может ввести буквы.
НО. Тестирование — все же не свойственное занятие для разработчика. Да он может писать тесты. Он может хоть версткой заниматься, что я ему как начальник скажу то он и будет делать.Но это во-первых нервирует его, как и любая не свойственная работа. А самое главное тест который сделает тестировщик за час, разработчик сделает за 3 часа. А платить ему надо как разработчику.
Понимаете?
Это очень дорого заставлять разработчика писать тесты.
Ровно по этой причине ни один стартап не может позволить себе «разработку через тестирование». И написание юнит тестов на каждый метод класса. На написание и поддержку нужно безумное количество часов. Цена ошибки копейки по сравнению с затратами на это.
Вот 3 «НО». Но я согласен что разработчиков хорошо бы учить тестированию. Это ускорит разработку. Но заменить разработчик тестера не может.
Я работаю в сфере, где юнит тестирование не возможно.
Почему?
То есть фактически 90% функций не будут работать если эта программа не запущена. С точки зрения методологии юнит тестирования, все внешние объекты должны эмулироваться стабами или моками, ну не суть.
Эмулировать работу этой внешней подсистемы, задача непомерно сложная, фактически соизмеримая с написание это самой системы.
При этом даже если это все эмулировать то нет никакой гарантии, что ты эмулируешь правильно. Потому что фактически, тестироваться будет не реальная система. А твоя эмуляция.
Но предположим мы это эмулировали. Выясняется что продукт тоже развивается. Каждый год у него выходит новая версия. И переход кода на новую версию это целое событие требующее существенного времени. Но не все же клиенты переходят на новую версию? Значит нужно поддерживать старые. ПОтому что клиенты ой как не хотят переходить на новые версии.
И вот мы например поддерживаем версии автокада с 2012 по 2020.
Это 8 версии. При этом
12-14 версии компилируются 2012 вижуал студией.
14-16 компилируется 15 студией.
16-18 2017 студией.
2019 компилируется 19 студией.
Это не мы наркоманы. Это так устроено апи автокада. Старые апи не модифицируются и не совместимы с новыми студиям.
Получается нужно эмулировать моками и стабами все внешние компоненты.
Модифицировать эмуляцию под каждую конкретную версию.
Написать юнит тесты с учетом конкретной версии. И поддерживать все это.
Ну скажем так. ̶П̶р̶о̶щ̶е̶ ̶з̶а̶с̶т̶р̶е̶л̶и̶т̶ь̶с̶я̶.̶ приходится писать комплексные тесты. А в коде вместо тестирование юнитов. Тестировать инварианты через assert() каких либо величин в дебаге.
Обычно рекомендуют архитектуру ports and adapters. Не надо эмулировать автокад, надо делать порт у вашего приложения, который декларирует только то подмножество интерфейса, которое нужно именно ему от автокада.
Отдельно пишутся интеграционные тесты на адаптеры (на то, что они выполняют контракт порта)
Но в данном случае это 90% работы конкретно с этим апи и где-то там внутри есть отдельные функции. Это скорее даже не АПИ а полноценный фреймворк. С Системой классов и сущностей от которых надо наследоваться. То есть фактически все тесты и будут интеграционными.
А поскольку они все связанны с графическим представлением объектов. Уже само по себе трудно построить условия. Потому как условия очень часто визуальные.
Ну я хочу нарисовать трубу. Подаю в автокад данные, он кода ошибки нет все норм. А трубу не нарисовал. Какой тест тут сделать?
Ну как бы если кто-то скажет у нас есть миллионы долларов, и годы на разработку. Да возможно это сработает. Ну никто так не говорит)
Тесты должна писать разработка (?)