Да одно и то же, часто ведь переизобретается велосипед и дается ему уникальное название.
Лет через 5 это назовется каким-нибудь «фасткодом» или «хоткодом» :)
Да, замена ломбока на готовые инструменты языка — это очень хорошо. А есть ли информация, как будут обстоять дела с сериализацией/десериализацией? Зачастую кучку таких классов приходится писать для работы с api-шками и представления объектов в виде json
Если мы говорим про Selenium и прочий веб, то имхо там достаточно ввести требования к верстке с обязательным указанием id-шников всех интерактивных элементов. И это прям значительно повышает тестируемость.
В каком-то идеальном мире это, наверно, есть :)
Просто хочу сказать, что при нормальной организации процесса для наибольшей эффективности тесты необходимо писать как минимум параллельно с разработкой, а еще лучше — до того, как код улетает на dev-стенд :)
Правда, это требует такой культуры разработки, которая пока мало у кого есть :(
Тест-менеджер явно появляется позже, чем компания осознает необходимость проектировать кейсы.
Компания в принципе может не проектировать тест-кейсы (ибо незачем).
И руководителю бизнеса или продукта, повторюсь, вообще неинтересно, есть тест-кейсы или нет. Они оперируют на другом уровне. Писать ли тест-кейсы — это уровень тест-лида/тест-менеджера максимум.
Есть случаи, когда отдельная команда нужна, но как дополнение к тестировщикам внутри команд. Только отдельная команда тестировщиков — ну, так себе решение.
наличие тест менеджеров — как раз говорит, что все идет в наименее эффективном направлении.
В моей практике до сих пор делаются проекты по waterfall в том виде, который я здесь описал.
Ну и ура. Вам дали тонну готовой документации, вы по ним написали тест-кейсы, прогнали, предоставили отчет. Красота! (Или в реальности все не так?)
До сих пор многие менеджеры не в курсе, что такое тестовая документация, что нужно проектировать кейсы и т.д.
Вы имеете в виду тест-менеджера или менеджера продукта? Я думаю, что менеджеру продукта совершенно не обязательно знать, какую именно тестовую документацию вы используете. Но если он знает про это всё — то, конечно, ему плюс.
«Тест-кейсы, чек-листы, майндмапы? Что это? Вы мне лучше скажите, можно ли показывать продукт заказчику?»
Нет, они не противоречивые.
Я имел в виду, что не надо писать автотесты специально для регресса. Надо писать тесты для нового функционала, и со временем эти тесты автоматически станут регрессионными :)
Кроме того автоматизация отлично заходит в ci/cd и в мониторинг какой — нибудь, что действительно означает «пишут автотесты раньше -> они приносят больше пользы»
К сожалению, тут плохо примерно всё, и к современной реальности имеет очень мало отношения.
Например, «Тестировщики занимаются тест-дизайном». Тест-дизайн — это проектирование тестов. Даже если тестировщик не пишет тест-кейсы, а занимается исследовательским тестированием продукта на финальной стадии — он занимается тест-дизайном, он продумывает, что и как он будет тестировать. И новичок, и суперопытный тестировщик этим занимаются — различие лишь в качестве и эффективности этого процесса.
Стадия 2, Waterfall… да закопайте уже waterfall! :(
В том понимании, в каком это указано здесь, его никто не применял последние лет дцать. А более ранней информацией я не владею.
Руководитель ждет от тестировщиков скорости и качества, а понимания необходимости тестовой документации и проведения регрессионного тестирования еще нет. Отсюда типичные проблемы этой ступени эволюции.
Пруфы! У кого нет понимания необходимости? Почему это необходимо?
Тестирование проводится больше интуитивно, чем структурированно. Главенствует принцип «что вижу — то и тестирую».
Это еще почему?
Для потокового производства сайтов или подобных проектов тест-дизайна более чем достаточно.
Окей :(
Мы лучше управляем тестами и получаем новый уровень качества продукта.
По умолчанию не получаем. А если находится больше важных проблем, мы их находим быстрее, быстрее потом фиксим и не добавляем новых — то да, уровень качества повышается.
Автотесты значительно сокращают расходы на регрессионное тестирование и повышают качество конечного продукта.
Абсолютно не факт. Скорее, наоборот, автотесты для регрессии не сокращают расходы и не повышают качество, а просто тратят время и деньги.
Также стоит знать, что автотесты не имеет смысла делать на ранних стадиях проекта. Система быстро меняется, поэтому во избежание фантомных ошибок нужно менять и автотесты, что занимает время.
А как же TDD, Test-First, Shift-left? Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы, а вы говорите, пишите в конце, автоматизируйте регрессию… :(
Например, тест-менеджер больше всех знает о продукте и занимается организацией тестирования на более высоком уровне. Он чаще и более тесно коммуницирует с заказчиками и разработкой, нежели с командой тестирования.
нет, про фреймсет тоже знаю/помню. ифреймы использовались не так активно, конечно, но тоже было…
Да, с годом поторопился, это вроде как закончилось к середине 2000-х.
Первое: в реальной жизни всем без разницы, как вы это называете — смоук или санити, или санитарное, или дымовое. Это все словесная эквилибристика, вы можете, конечно, ей заниматься, и она, вероятно, вам поможет в двух случаях: при сдаче ISTQB и прохождение упоротого интервью. Да, меня даже разок спросили про это, диалог был примерно такой:
— В чем разница между санити и смоук?
— Возможно, есть какие-то нюансы, но я использую их как синонимы.
— Ну да, мы тоже.
Такая вот суровая реальность.
Второе: ре-тест не поддается автоматизации? Вы таки никогда не слышали про TDD? Test-first? очень даже поддается, и лучше, чем регрессионное.
Третье: «Регрессионные: Лучший повод для автоматизации данного вида тестирования» — коряво построенная фраза, но если читать как «надо автоматизировать регрессию», то это очень спорный факт, и вообще в тестировании это уже слегка холиварная тема :)
Лет через 5 это назовется каким-нибудь «фасткодом» или «хоткодом» :)
В каком-то идеальном мире это, наверно, есть :)
Просто хочу сказать, что при нормальной организации процесса для наибольшей эффективности тесты необходимо писать как минимум параллельно с разработкой, а еще лучше — до того, как код улетает на dev-стенд :)
Правда, это требует такой культуры разработки, которая пока мало у кого есть :(
Компания в принципе может не проектировать тест-кейсы (ибо незачем).
И руководителю бизнеса или продукта, повторюсь, вообще неинтересно, есть тест-кейсы или нет. Они оперируют на другом уровне. Писать ли тест-кейсы — это уровень тест-лида/тест-менеджера максимум.
Есть случаи, когда отдельная команда нужна, но как дополнение к тестировщикам внутри команд. Только отдельная команда тестировщиков — ну, так себе решение.
А что не так с тест-менеджерами? :)
Ну и ура. Вам дали тонну готовой документации, вы по ним написали тест-кейсы, прогнали, предоставили отчет. Красота! (Или в реальности все не так?)
Вы имеете в виду тест-менеджера или менеджера продукта? Я думаю, что менеджеру продукта совершенно не обязательно знать, какую именно тестовую документацию вы используете. Но если он знает про это всё — то, конечно, ему плюс.
«Тест-кейсы, чек-листы, майндмапы? Что это? Вы мне лучше скажите, можно ли показывать продукт заказчику?»
Я имел в виду, что не надо писать автотесты специально для регресса. Надо писать тесты для нового функционала, и со временем эти тесты автоматически станут регрессионными :)
Именно так.
Например, «Тестировщики занимаются тест-дизайном». Тест-дизайн — это проектирование тестов. Даже если тестировщик не пишет тест-кейсы, а занимается исследовательским тестированием продукта на финальной стадии — он занимается тест-дизайном, он продумывает, что и как он будет тестировать. И новичок, и суперопытный тестировщик этим занимаются — различие лишь в качестве и эффективности этого процесса.
Стадия 2, Waterfall… да закопайте уже waterfall! :(
В том понимании, в каком это указано здесь, его никто не применял последние лет дцать. А более ранней информацией я не владею.
Пруфы! У кого нет понимания необходимости? Почему это необходимо?
Это еще почему?
Окей :(
По умолчанию не получаем. А если находится больше важных проблем, мы их находим быстрее, быстрее потом фиксим и не добавляем новых — то да, уровень качества повышается.
Абсолютно не факт. Скорее, наоборот, автотесты для регрессии не сокращают расходы и не повышают качество, а просто тратят время и деньги.
А как же TDD, Test-First, Shift-left? Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы, а вы говорите, пишите в конце, автоматизируйте регрессию… :(
Это не очень хороший тест-менеджер.
итд…
Но спасибо, коллеги, вашими усилиями Йошкар-Ола становится все более известной, в том числе и как айтишный город.
Да, с годом поторопился, это вроде как закончилось к середине 2000-х.
Не, реально, в 2020 году писать сайт в фреймами?!
— В чем разница между санити и смоук?
— Возможно, есть какие-то нюансы, но я использую их как синонимы.
— Ну да, мы тоже.
Такая вот суровая реальность.
Второе: ре-тест не поддается автоматизации? Вы таки никогда не слышали про TDD? Test-first? очень даже поддается, и лучше, чем регрессионное.
Третье: «Регрессионные: Лучший повод для автоматизации данного вида тестирования» — коряво построенная фраза, но если читать как «надо автоматизировать регрессию», то это очень спорный факт, и вообще в тестировании это уже слегка холиварная тема :)