Comments 15
Двойственное впечатление от рекомендации предварительно вручную всё тестировать самому прежде чем отдавать в тестирование. Вроде логично, но тестирование всех комбинаций может занимать много времени. Рационально тратить ли его дважды на одну задачу? Это если предполагать что разработчик и тестировщик тратят одинаковое время на тестирование.
На одинаковом наборе кейсов, тестировщик потратит столько же или больше времени, чем разработчик :) Потому что первому нужно фиксировать баги для передачи второму. Скриншот, описание. Еще потом проверить, что баг исправлен! На возню с багами может уходить до 80% времени выполнения ручных тестов. И это мы еще не говорим про блокеры.
Когда тестирует разработчик, никому никуда иныормацию передавать не надо, он все еще в контексте задачи и может фиксить на лету.
У первого есть тест-план и тест-кейсы, а второй будет смотреть в код и думать, что может пойти не так. В лучшем случае проверит все явно заданные в таске кейсы.
В статье как раз прикольный чеклист того, что можно посмотреть, не привязываясь к код или постановке задачи.
По опыту у тестировщиков такие чек-листы проходить быстрее получается. Причём гораздо быстрее. У них и сами чеклисты в голове такие, и какие-то заготовки тех же строк разной длины, даже хоткеи на их вставку то ли на уровне ОС, то ли на уровне браузера, то ли расширения какие-то… Это с одной стороны. С другой они лучше ориентируются с ожидаемым поведением на конкретном проекте в целом. Я вот понятия не имею нужно ли на трёх последних проектах, где я влезал во фронт, тримить пробелы. Я не тримлю по умолчанию — это неожиданное поведение для меня как для пользователя. Или ошибку использования запрещенного символа покажите, или пропустите не изменяя.
Про тратить время дважды есть несколько мыслей:
Если разработчик и тестировщик общаются, то первый может рассказать, что он уже посмотрел. И тогда второму не надо будет второй раз этой делать. Или же смотреть только отдельные изощерённые случаи, опираясь на свои знания или практику. Но да, я понимаю, что бывают случаи, когда есть сложности коммуникаций между разработкой и тестирование.
И вторая: если разработчик будет хотя бы поверхностно смотреть свою работу по этому списку, то есть вероятность, что он в дальнейшем будет сразу писать с учётом новых знаний, полученных из проверок за собой. И получится, что будет меньше багов. А как упомянул 24twelve, передача данных о каждой ошибке из тестирования — это дополнительные временные затраты.
Про чек-листы и прочее кунг-фу тестирования:
Я не прошу проходить хитровыдуманные кейсы :)
Пройдя по кейсам из заметки, разработчик может закрыть базовые проблемы ещё на этапе создания и, возможно, найти что-нибудь ещё интересное. А это уже плюс к скорости прохождения задачи через весь цикл.
Также можно спросить тестирование, как и что они делают с браузером при тестировании. Обычно люди хорошо делятся своим опытом или инструментами.
Я ж не говорю, что вообще проверять разработчик не должен, написал код и отправил в QA не проверив даже открывается ли вообще страница (хотя и такие люди встречались). А формальные баги, как по мне, гораздо лучше стимулируют при разработке учитывать разные нюансы.
Может этот чек-лист полезен при начальном вхождении в проект, например, когда не знаешь, что по умолчанию в текстовом инпуте должно быть не более 255 символов, а хвостовые пробелы должны тримиться. Но вот мне не хотелось бы работать в окружении, где есть тестировщики, но кучу кейсов должен пройти я сам, прежде чем передать на тестирование. (Ситуация когда разработчик фичу отправляет в продакшен никому не показав — совсем отдельная)
Про инструменты всё не так просто. Делимся, конечно, чем-то, но очень часто неприменимо оказывается. Если я тестированием занимаюсь не более часа в день, причём урывками, то инструменты скорее мешать будут, чем помогать. Грубо говоря, хоткеи не запомнить, а мышкой заметно дольше получается. Так же как при использовании инструментов разработки тестировщиками. Не очень разумно, обычно, приобретать и осваивать на профессиональном уровне профессиональный инструмент, если не собираешься его профессионально использовать.
Я тут даже подумал, по факту я даже не все явно заданные в таске требования проверяю руками перед отдачей в тестирование. Ту же максимальную длину я чаще проверяю в коде — установлен атрибут/свойство или нет. Проверять, что фреймворк и браузер правильно его обрабатывают считаю излишним, если уверен в них.
А как можно не тестировать то, что ты сам написал? Это где так работают?
Спасибо за статью.
Жаль, что не раскрыта мотивация, зачем вообще фронтендерам искать баги самим.
Про верстку не понял. После 2-3 раза сдачи работы, как на скрине, человека просто нужно увольнять. Это либо явный саботаж, либо разработчик просто напросто невменяем.
Не в тему, но насколько же хороший у контура дизайн, запоминается и узнается по одной кнопочке, прям кайфую
А если взять Гайды, то такой же продуманный и клёвый дизайн может быть у каждого :)
Заметка для фронтендеров: что проверить перед тестированием