Комментарии 19
К сожалению, тут плохо примерно всё, и к современной реальности имеет очень мало отношения.
Например, «Тестировщики занимаются тест-дизайном». Тест-дизайн — это проектирование тестов. Даже если тестировщик не пишет тест-кейсы, а занимается исследовательским тестированием продукта на финальной стадии — он занимается тест-дизайном, он продумывает, что и как он будет тестировать. И новичок, и суперопытный тестировщик этим занимаются — различие лишь в качестве и эффективности этого процесса.
Стадия 2, Waterfall… да закопайте уже waterfall! :(
В том понимании, в каком это указано здесь, его никто не применял последние лет дцать. А более ранней информацией я не владею.
Пруфы! У кого нет понимания необходимости? Почему это необходимо?
Это еще почему?
Окей :(
По умолчанию не получаем. А если находится больше важных проблем, мы их находим быстрее, быстрее потом фиксим и не добавляем новых — то да, уровень качества повышается.
Абсолютно не факт. Скорее, наоборот, автотесты для регрессии не сокращают расходы и не повышают качество, а просто тратят время и деньги.
А как же TDD, Test-First, Shift-left? Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы, а вы говорите, пишите в конце, автоматизируйте регрессию… :(
Это не очень хороший тест-менеджер.
итд…
Например, «Тестировщики занимаются тест-дизайном». Тест-дизайн — это проектирование тестов. Даже если тестировщик не пишет тест-кейсы, а занимается исследовательским тестированием продукта на финальной стадии — он занимается тест-дизайном, он продумывает, что и как он будет тестировать. И новичок, и суперопытный тестировщик этим занимаются — различие лишь в качестве и эффективности этого процесса.
Стадия 2, Waterfall… да закопайте уже waterfall! :(
В том понимании, в каком это указано здесь, его никто не применял последние лет дцать. А более ранней информацией я не владею.
Руководитель ждет от тестировщиков скорости и качества, а понимания необходимости тестовой документации и проведения регрессионного тестирования еще нет. Отсюда типичные проблемы этой ступени эволюции.
Пруфы! У кого нет понимания необходимости? Почему это необходимо?
Тестирование проводится больше интуитивно, чем структурированно. Главенствует принцип «что вижу — то и тестирую».
Это еще почему?
Для потокового производства сайтов или подобных проектов тест-дизайна более чем достаточно.
Окей :(
Мы лучше управляем тестами и получаем новый уровень качества продукта.
По умолчанию не получаем. А если находится больше важных проблем, мы их находим быстрее, быстрее потом фиксим и не добавляем новых — то да, уровень качества повышается.
Автотесты значительно сокращают расходы на регрессионное тестирование и повышают качество конечного продукта.
Абсолютно не факт. Скорее, наоборот, автотесты для регрессии не сокращают расходы и не повышают качество, а просто тратят время и деньги.
Также стоит знать, что автотесты не имеет смысла делать на ранних стадиях проекта. Система быстро меняется, поэтому во избежание фантомных ошибок нужно менять и автотесты, что занимает время.
А как же TDD, Test-First, Shift-left? Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы, а вы говорите, пишите в конце, автоматизируйте регрессию… :(
Например, тест-менеджер больше всех знает о продукте и занимается организацией тестирования на более высоком уровне. Он чаще и более тесно коммуницирует с заказчиками и разработкой, нежели с командой тестирования.
Это не очень хороший тест-менеджер.
итд…
Я написал о своем опыте. В моей практике до сих пор делаются проекты по waterfall в том виде, который я здесь описал. До сих пор многие менеджеры не в курсе, что такое тестовая документация, что нужно проетировать кейсы и т.д. Повторюсь, это мой опыт. Основан он на сотрудничестве с несколькими сотнями компаний за последние лет 10. Возможно в вашем случае, в вашей компании ситуация другая )
Я различал и буду различать тестировщиков, которые при тестировании отталкиваются от требований, проектируют кейсы… и тех, кто просто проверяет то, что видит. Вы можете считать, что и те и другие занимаются тест-дизайном — окей, ваше право. Лично я так не считаю )
Я различал и буду различать тестировщиков, которые при тестировании отталкиваются от требований, проектируют кейсы… и тех, кто просто проверяет то, что видит. Вы можете считать, что и те и другие занимаются тест-дизайном — окей, ваше право. Лично я так не считаю )
В моей практике до сих пор делаются проекты по waterfall в том виде, который я здесь описал.
Ну и ура. Вам дали тонну готовой документации, вы по ним написали тест-кейсы, прогнали, предоставили отчет. Красота! (Или в реальности все не так?)
До сих пор многие менеджеры не в курсе, что такое тестовая документация, что нужно проектировать кейсы и т.д.
Вы имеете в виду тест-менеджера или менеджера продукта? Я думаю, что менеджеру продукта совершенно не обязательно знать, какую именно тестовую документацию вы используете. Но если он знает про это всё — то, конечно, ему плюс.
«Тест-кейсы, чек-листы, майндмапы? Что это? Вы мне лучше скажите, можно ли показывать продукт заказчику?»
Дали документацию, прогнали кейсы, дали отчет. Тут все хорошо. Проблема же в другом там, если вы конечно читали текст статьи) В частности при таком подходе срываются сроки из-за того, что все баги находятся в самом конце работы.
Тест-менеджер явно появляется позже, чем компания осознает необходимость проектировать кейсы. Я писал про руководителей (всего бизнеса или отдельного продукта\проекта), которые принимают решение о судьбе тестирования в тот момент. Есть много небольших компаний, где руководство набирает тестировщиков по объявлению, ждет чудес и абсолютно не понимает зачем нужно выделять время и вообще делать какую-то там документацию для тестирования)
Тест-менеджер явно появляется позже, чем компания осознает необходимость проектировать кейсы. Я писал про руководителей (всего бизнеса или отдельного продукта\проекта), которые принимают решение о судьбе тестирования в тот момент. Есть много небольших компаний, где руководство набирает тестировщиков по объявлению, ждет чудес и абсолютно не понимает зачем нужно выделять время и вообще делать какую-то там документацию для тестирования)
Тест-менеджер явно появляется позже, чем компания осознает необходимость проектировать кейсы.
Компания в принципе может не проектировать тест-кейсы (ибо незачем).
И руководителю бизнеса или продукта, повторюсь, вообще неинтересно, есть тест-кейсы или нет. Они оперируют на другом уровне. Писать ли тест-кейсы — это уровень тест-лида/тест-менеджера максимум.
Компания в целом может не тестировать, может не нанимать тестировщиков и тем более может не разбираться в тестировании… но зачем вы про эти компании? Или может быть вы считаете, что руководители компаний при найме первого тестировщика в штат интуитивно понимают какой из 100 кандидатов хороший и сразу разрешают ему делать что угодно? О чем вы вообще? Что вы пытаетесь мне доказать?
В частности при таком подходе срываются сроки из-за того, что все баги находятся в самом конце работы.
При нормальном эстимировании и выставлении сроков сроки не срываются, потому что они учитывают вероятность появления багов. Другими словами, если вы планируете тестить в самом конце, то и баги получать вы планируете в самом конце, соответственно баги фиксы ретесты закладываются или должны закладываться в сроки.
вы пишете:
Вам не кажется, что это немного противоречивые заключения?
Регресс может содержать в себе и автоматизированные тесты и ручные, а основная цель автоматизации — ускорить выполнение кейсов и минимизировать риски человеческого фактора (усталость, рассеяность, изматывающая монотонность выполнения). Кроме того автоматизация отлично заходит в ci/cd и в мониторинг какой — нибудь, что действительно означает «пишут автотесты раньше -> они приносят больше пользы»
автотесты для регрессии не сокращают расходы и не повышают качество, а просто тратят время и деньги.и
Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы
Вам не кажется, что это немного противоречивые заключения?
Регресс может содержать в себе и автоматизированные тесты и ручные, а основная цель автоматизации — ускорить выполнение кейсов и минимизировать риски человеческого фактора (усталость, рассеяность, изматывающая монотонность выполнения). Кроме того автоматизация отлично заходит в ci/cd и в мониторинг какой — нибудь, что действительно означает «пишут автотесты раньше -> они приносят больше пользы»
Нет, они не противоречивые.
Я имел в виду, что не надо писать автотесты специально для регресса. Надо писать тесты для нового функционала, и со временем эти тесты автоматически станут регрессионными :)
Именно так.
Я имел в виду, что не надо писать автотесты специально для регресса. Надо писать тесты для нового функционала, и со временем эти тесты автоматически станут регрессионными :)
Кроме того автоматизация отлично заходит в ci/cd и в мониторинг какой — нибудь, что действительно означает «пишут автотесты раньше -> они приносят больше пользы»
Именно так.
А как же TDD, Test-First, Shift-left? Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы, а вы говорите, пишите в конце, автоматизируйте регрессию… :(
Ну оно то конечно да, но первые 2-3 месяца UI-тесты действительно нет смысла писать, потому что проект часто изменяется и получится что будешь постоянно занят восстановлением работоспособности только что написанных тестов.А вот спустя месяца 3 — там да, уже имеет смысл — к этому времени проект обычно устаканивается и правки, ломающие GUI тесты случаются значительно реже.
А для проектов какой длительности это применимо?
Ну как можно увидеть из моего комментария — для проектов длительностью меньше 2-3 месяцев автотесты писать вообще особо смысла нет(ну кроме каких-то исключительных случаев). Я бы сказал что автотестами стоит заниматься если проект от полгода и дольше по длительности. Ну а до полугода — внимательно рассматривать каждый конкретный случай. Потому что иногда бывают нужны автотесты и на 3-г=недельный проект, но все же это не часто случается)
Ок.
Просто хочу сказать, что при нормальной организации процесса для наибольшей эффективности тесты необходимо писать как минимум параллельно с разработкой, а еще лучше — до того, как код улетает на dev-стенд :)
Правда, это требует такой культуры разработки, которая пока мало у кого есть :(
Просто хочу сказать, что при нормальной организации процесса для наибольшей эффективности тесты необходимо писать как минимум параллельно с разработкой, а еще лучше — до того, как код улетает на dev-стенд :)
Правда, это требует такой культуры разработки, которая пока мало у кого есть :(
Ну в идеале — да. Но вот для юнит тестов к примеру гораздо проще быть написанными параллельно с разработкой, или даже до, потому что им не нужен GUI, с другой стороны GUI тесты очевидно чувствительны к изменениям в GUI и потому часто пишутся уже после разработки. С другой стороны когда проект достаточно длинный, интерфейс уже стандартизированный и кардинально меняется скорее логика, чем интерфейс — то в этом случае и GUI тесты могут быть написаны до разработки.
НЛО прилетело и опубликовало эту надпись здесь
Отдельные команды тестировщиков, автоматизаторов
Есть случаи, когда отдельная команда нужна, но как дополнение к тестировщикам внутри команд. Только отдельная команда тестировщиков — ну, так себе решение.
наличие тест менеджеров — как раз говорит, что все идет в наименее эффективном направлении.
А что не так с тест-менеджерами? :)
Ну вот, профессиональные тестировщики налетели тестировать статью. Сейчас оформят багрепорты и переведут в reopen, как несоответствующую их представлениям об идеальном мире ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 этапов эволюции тестирования в компании