Про тратить время дважды есть несколько мыслей:
Если разработчик и тестировщик общаются, то первый может рассказать, что он уже посмотрел. И тогда второму не надо будет второй раз этой делать. Или же смотреть только отдельные изощерённые случаи, опираясь на свои знания или практику. Но да, я понимаю, что бывают случаи, когда есть сложности коммуникаций между разработкой и тестирование.
И вторая: если разработчик будет хотя бы поверхностно смотреть свою работу по этому списку, то есть вероятность, что он в дальнейшем будет сразу писать с учётом новых знаний, полученных из проверок за собой. И получится, что будет меньше багов. А как упомянул 24twelve, передача данных о каждой ошибке из тестирования — это дополнительные временные затраты.
Про чек-листы и прочее кунг-фу тестирования:
Я не прошу проходить хитровыдуманные кейсы :)
Пройдя по кейсам из заметки, разработчик может закрыть базовые проблемы ещё на этапе создания и, возможно, найти что-нибудь ещё интересное. А это уже плюс к скорости прохождения задачи через весь цикл.
Также можно спросить тестирование, как и что они делают с браузером при тестировании. Обычно люди хорошо делятся своим опытом или инструментами.
Но есть несколько вопросов:
1) Как вы убеждали разработку начать активно писать тесты? Или они и раньше это делали?
2) Качество тестов разработчиков как-нибудь проверяется?
3) Тестирование ковыряется с Селениумом и, прости господи, BDD. Как они определяют отсутствие дублирования проверок, которые можно автоматизировать на более нижних слоях пирамиды?
4) Если я правильно понял, то разработка один раз причесала фрейморк. А дальше она как-нибудь вообще взаимодействует с UI тестами?
Поддержу за YT. Что меня покорило: простой с виду и при этом хорошо так настраиваемый. Ну и достаточно быстрый (standalone).
lingvo
Вели там всякое: как обычные баги (спринты-минты) так и запилили систему хранения соискателей. Обмазались workflow по самое — половина рутинных вещей просто не успела даже появиться.
Но надо понимать, что YT — не серебряная пуля и есть всякие недостатки. Надо примерять его к своим реалиям.
Пока лучшая статья из тех, что читал про шрифты. Наглядная демонстрация развития — это нечто! Всё не просто «так сложилось», оказывается, а люди специально сидели и думали про шрифты.
Очень круто сделано преобразование Экспедиции. От невнятного курсива к чёткой эмблеме.
Ну и кончено СибТрансНавигация. Вот тут уж воистинну просто поиграли шрифтами.
Про тратить время дважды есть несколько мыслей:
Если разработчик и тестировщик общаются, то первый может рассказать, что он уже посмотрел. И тогда второму не надо будет второй раз этой делать. Или же смотреть только отдельные изощерённые случаи, опираясь на свои знания или практику. Но да, я понимаю, что бывают случаи, когда есть сложности коммуникаций между разработкой и тестирование.
И вторая: если разработчик будет хотя бы поверхностно смотреть свою работу по этому списку, то есть вероятность, что он в дальнейшем будет сразу писать с учётом новых знаний, полученных из проверок за собой. И получится, что будет меньше багов. А как упомянул 24twelve, передача данных о каждой ошибке из тестирования — это дополнительные временные затраты.
Про чек-листы и прочее кунг-фу тестирования:
Я не прошу проходить хитровыдуманные кейсы :)
Пройдя по кейсам из заметки, разработчик может закрыть базовые проблемы ещё на этапе создания и, возможно, найти что-нибудь ещё интересное. А это уже плюс к скорости прохождения задачи через весь цикл.
Также можно спросить тестирование, как и что они делают с браузером при тестировании. Обычно люди хорошо делятся своим опытом или инструментами.
Но есть несколько вопросов:
1) Как вы убеждали разработку начать активно писать тесты? Или они и раньше это делали?
2) Качество тестов разработчиков как-нибудь проверяется?
3) Тестирование ковыряется с Селениумом и, прости господи, BDD. Как они определяют отсутствие дублирования проверок, которые можно автоматизировать на более нижних слоях пирамиды?
4) Если я правильно понял, то разработка один раз причесала фрейморк. А дальше она как-нибудь вообще взаимодействует с UI тестами?
lingvo
Вели там всякое: как обычные баги (спринты-минты) так и запилили систему хранения соискателей. Обмазались workflow по самое — половина рутинных вещей просто не успела даже появиться.
Но надо понимать, что YT — не серебряная пуля и есть всякие недостатки. Надо примерять его к своим реалиям.
Ну и кончено СибТрансНавигация. Вот тут уж воистинну просто поиграли шрифтами.
Скажите, а часто так бывает, что клиент отказывается от первого результата логотипа и начинает придумывать новые концепции?