Комментарии 16
Что значит провести функциональное тестирование черным ящиком?
Я бы слово «функциональное» убрал отсюда. Никому и никогда в реальной жизни эти странные слова толком не пригождаются, а на некоторых собеседованиях прям заваливают вопросами типа «какие типы тестирования вы знаете \ чем отличаются тестирование Х от Y» — абсолютно бесполезные имхо. Какая, собственно, разница, UX ли или «функциональное», если в итоге вы один фиг сабмитите багу с описанием.
Или там мучают вопросами аля «расскажите про регрессионное тестирование» — да блин, любое тестирование после первого взгляда на фичу в некотором смысле регрессионное, вот не пофигу ли, как его называть.
Доброго вечера. Мне жаль, что статья Вас огорчила, чем бы Вы заменили раздражающие термины?
Вообще любая терминология необходима для понимания друг друга. Если Ваша команда решила назвать регрессионное тестирование «охотой на бабочек» и все в точности понимают, что и в какой последовательности будут делать во время этой операции и какой результат получат, смело называйте его своим термином. Однако Вы сможете им пользоваться только внутри своей команды, другие тестировщики и команды Вас уже не поймут.
(Хорошим) Результатом тестирования я все же считаю не столько заведенные дефекты в тесте, сколько НЕ заведенные дефекты после выпуска релиза.
Вообще любая терминология необходима для понимания друг друга. Если Ваша команда решила назвать регрессионное тестирование «охотой на бабочек» и все в точности понимают, что и в какой последовательности будут делать во время этой операции и какой результат получат, смело называйте его своим термином. Однако Вы сможете им пользоваться только внутри своей команды, другие тестировщики и команды Вас уже не поймут.
(Хорошим) Результатом тестирования я все же считаю не столько заведенные дефекты в тесте, сколько НЕ заведенные дефекты после выпуска релиза.
Слишком много теории. Мне кажется ту теорию которую спрашивают, особенно терминологическую, нужно знать только для прохождения собеседования, дальше она не работает.
Большинство трудовых задач решаются тем что их решают, независимо от того работал ли ранее с областью или нет. Главное, чтобы входило с специфику работ. А в тестировании, что там такого прям сложного.
Если человек смышленый, но не знает вашей терминологии, это помешает ему в работе настолько сильно, что он не справится от их неужели такого большого количества и сложности?
Эти определения описываются парами фраз. Большинство из них достаточно услышать один раз, а после показа первого реального теста где он оказывается именно таким, вообще не забываются.
Насколько я знаю, программистов берут на новую работу с новым специфичным языком для соискателя спокойно, в расчете на самообучение в процессе.
Не знаю, какую теорию и как спрашивали на собеседованиях у Вас, возможно опрос действительно был избыточным. Лично я на собеседованиях акцентируюсь на опыте и навыках кандидата. В статье есть еще 2 части, кроме теоретической, но раз именно она вызывает резонанс давайте на ней остановимся
ну терминология все же не моя личная, и, как мне кажется, смышленный человек без труда осилит одну небольшую книгу ;)
Оглянитесь вокруг, все компьютеризировано — передвижения, связь, платежи, развлечения, медицина, оборонка — все сферы жизни пронизаны системами, среди них есть жизненно важные и бесконечно сложные, и каждая из них кем-то протестирована. Представьте, если тестирование будет не качественным хотя бы в половине случаев, Вы просто огорчитесь, если сломается любимая игрушка, ну а если упадет самолет? Так что не соглашусь, что тестирование — это просто. Цена ошибки может достигать миллионов рублей и человеческих жизней. Погуглите, сколько стоят самые дорогие баги
Теория — это база для будущих навыков, соглашусь, что заучивание терминов, пожалуй последнее, что нужно делать) Теорию нужно… «разобрать», тогда и термины Вы запомните без заучивания.
К примеру, под «фунциональным тестированием черным ящиком» лежат подходы к тест-дизайну с помощю которых Вы будете выполнять полезные тесты, и не тратить время на бесполезные. «Черноящичные» техники самые простые из всех существующих, поэтому стоит начать с них. Под «выбором тестов в ограниченных временных рамках» лежат подходы к приоритезации тестов, а это позволит Вам не выпускать в Prod блокирующие дефекты. Начните изучение и другие теоретические вопросы в списке окажутся не такими уж теоретическими и совсем не про термины
Если человек смышленый, но не знает вашей терминологии, это помешает ему в работе настолько сильно, что он не справится от их неужели такого большого количества и сложности?
ну терминология все же не моя личная, и, как мне кажется, смышленный человек без труда осилит одну небольшую книгу ;)
Оглянитесь вокруг, все компьютеризировано — передвижения, связь, платежи, развлечения, медицина, оборонка — все сферы жизни пронизаны системами, среди них есть жизненно важные и бесконечно сложные, и каждая из них кем-то протестирована. Представьте, если тестирование будет не качественным хотя бы в половине случаев, Вы просто огорчитесь, если сломается любимая игрушка, ну а если упадет самолет? Так что не соглашусь, что тестирование — это просто. Цена ошибки может достигать миллионов рублей и человеческих жизней. Погуглите, сколько стоят самые дорогие баги
Теория — это база для будущих навыков, соглашусь, что заучивание терминов, пожалуй последнее, что нужно делать) Теорию нужно… «разобрать», тогда и термины Вы запомните без заучивания.
К примеру, под «фунциональным тестированием черным ящиком» лежат подходы к тест-дизайну с помощю которых Вы будете выполнять полезные тесты, и не тратить время на бесполезные. «Черноящичные» техники самые простые из всех существующих, поэтому стоит начать с них. Под «выбором тестов в ограниченных временных рамках» лежат подходы к приоритезации тестов, а это позволит Вам не выпускать в Prod блокирующие дефекты. Начните изучение и другие теоретические вопросы в списке окажутся не такими уж теоретическими и совсем не про термины
Мне вот любопытно, а как конкретно вы представляете себе "большинство трудовых задач"?
Я не согласен с тем, что определения достаточно услышать один раз. Ниже в комментариях уже есть случай, когда человек не понимает смысла регрессионного тестирования, хотя наверняка слышал его определение.
Если определения такие простые, почему бы не запомнить их до устройства на работу, а не после?
Ага, именно, вы все правильно говорите, что терминология просто хаос вокруг. Конкретно в этом случае я вроде написал — я бы просто убрал слово «функциональное», ибо оно не несет смысловой нагрузки, но при этом бросается в глаза. Из вашего же предложения, там есть слово «черный ящик» — вот оно, хоть и не менее бесполезное на практике, но является вполне себе устоявшимся и общеизвестным понятием в отрасли, по крайней мере, можно увидеть, в курсе ли человек, что вообще происходит вокруг.
А вот если меня спросят про «регрессионное» или «функциональное» тестирование на собеседовании — первые пару минут я совершенно осознанно порассказываю про хаос терминологий =) А на одном собесе так жесть была, когда собеседующие начали спорить и самоутверждаться, говоря, что я неправ (да, компания была русскоговорящая). Но зато стало понятно, куда идти не стоит. Для меня это скорее как красно-желтый флаг на собесе о компании — если говорят\спрашивают что-то про «функциональное»\«регрессионное» тестирование — что-то здесь не так.
И если, например, хаос в уровнях тестирования (юнит\интеграция\систем | маленькие\средние\большие) еще понятно, что употребляется время от времени в почти всех командах, и стоит смотреть на терминологию, то вот про «функциональное» все не так просто. За годы реальной работы мне не встречался, в общем-то, кейс, когда мы серьезно обсуждали эту терминологию просто потому, что она не нужна в реальной работе (обсуждали именно в контексте хаоса терминологии, не больше). Абсолютно ни разу за 7 лет работы в тестировании не нужны были слова ни «регрессионное», ни «функциональное», ни там «юзабилити» -тестирование. Ну т.е. конечно полезно понимать, что приложение-то можно проверить с разных сторон, но вроде как для смышленного человека это очевидно, о чем тут говорить-то.
Ну вообще оно и так некачественное, это видно, особенно если вы сами — тестировщик :D Еще скажите, что неправда?
А вот если меня спросят про «регрессионное» или «функциональное» тестирование на собеседовании — первые пару минут я совершенно осознанно порассказываю про хаос терминологий =) А на одном собесе так жесть была, когда собеседующие начали спорить и самоутверждаться, говоря, что я неправ (да, компания была русскоговорящая). Но зато стало понятно, куда идти не стоит. Для меня это скорее как красно-желтый флаг на собесе о компании — если говорят\спрашивают что-то про «функциональное»\«регрессионное» тестирование — что-то здесь не так.
И если, например, хаос в уровнях тестирования (юнит\интеграция\систем | маленькие\средние\большие) еще понятно, что употребляется время от времени в почти всех командах, и стоит смотреть на терминологию, то вот про «функциональное» все не так просто. За годы реальной работы мне не встречался, в общем-то, кейс, когда мы серьезно обсуждали эту терминологию просто потому, что она не нужна в реальной работе (обсуждали именно в контексте хаоса терминологии, не больше). Абсолютно ни разу за 7 лет работы в тестировании не нужны были слова ни «регрессионное», ни «функциональное», ни там «юзабилити» -тестирование. Ну т.е. конечно полезно понимать, что приложение-то можно проверить с разных сторон, но вроде как для смышленного человека это очевидно, о чем тут говорить-то.
Представьте, если тестирование будет не качественным хотя бы в половине случаев,
Ну вообще оно и так некачественное, это видно, особенно если вы сами — тестировщик :D Еще скажите, что неправда?
Не пофиг, хотя бы потому, что когда надо будет одним предложением описать текущий статус разработчику, какое тестирование тут было сделано, то сказать функциональное закончено, регрессионное сделано сделано на половину и надо еще столько-то времени, а нагрузочное еще не начинали и на него надо еще столько-то, то это как минимум намного быстрее и точнее, чем пытаться описать то же самое своими словами
Вы сможете в двух словах описать грань между функциональным и регрессионным? В какой момент автотест на новую фичу переходит в категорию «регрессионных»? Откуда это будет знать разработчик?
Мои разработчики обычно заинтересованы в конкретных вещах, типа «я тут ПР на прошлой неделе залил, ты потестил?» или «есть проблемы в коде, который мы в препрод пушнули?». И ответы уровня «все ок», «вроде работает, но я ж вон десяток багов тебе повесил», «основная фича работает, сейчас смотрю в деталях, к вечеру закончу», «блин, руки не доходили посмотреть еще», «вообще все плохо, вон два Critical же висит» — более чем достаточные и понятные и мне и разработчику.
Но, конечно, если вы в вашей команде договорились, что у вас есть уровень тестирования «кошки», «бананы» и «крокодилы», то да, можно сказать «кошки ок, бананы в процессе, к крокодилам не приступал» и в рамках вашей конкретно команды это будет норм. Но быстро сломается, если вы попробуете говорить с другими человеками из других команд. И в этом случае разницы между «регрессионным», «интеграционным» и «кошками» нет никакой, ибо и те и другие от команды к команде могут отличаться целиком и полностью и требуют объяснений перед началом разговора, про какие же тесты вы говорите. А то ведь то, что у вас «интеграционное» у других называется «регрессионное», а у третьих «крокодилы». Без переводчика не обойтись.
Мои разработчики обычно заинтересованы в конкретных вещах, типа «я тут ПР на прошлой неделе залил, ты потестил?» или «есть проблемы в коде, который мы в препрод пушнули?». И ответы уровня «все ок», «вроде работает, но я ж вон десяток багов тебе повесил», «основная фича работает, сейчас смотрю в деталях, к вечеру закончу», «блин, руки не доходили посмотреть еще», «вообще все плохо, вон два Critical же висит» — более чем достаточные и понятные и мне и разработчику.
Но, конечно, если вы в вашей команде договорились, что у вас есть уровень тестирования «кошки», «бананы» и «крокодилы», то да, можно сказать «кошки ок, бананы в процессе, к крокодилам не приступал» и в рамках вашей конкретно команды это будет норм. Но быстро сломается, если вы попробуете говорить с другими человеками из других команд. И в этом случае разницы между «регрессионным», «интеграционным» и «кошками» нет никакой, ибо и те и другие от команды к команде могут отличаться целиком и полностью и требуют объяснений перед началом разговора, про какие же тесты вы говорите. А то ведь то, что у вас «интеграционное» у других называется «регрессионное», а у третьих «крокодилы». Без переводчика не обойтись.
Если в двух словах, но функциональное тестирование — тестирование намеренно измененного или нового функционала. Регрессионное — тестирование на возможные проблемы в уже имеющемся прочем функционале. Разработчик прекрасно видит эту разницу хотя бы потому, что он знает, планировал ли он изменение конкретно в этом функционале, или это поменялось что-то другое где-то в другом месте, чего он не планировал.
Ну грань-то где? На вопрос-то ответите? ;)
В какой момент автотест на новую фичу переходит в категорию «регрессионных»?
в момент когда фичу зарелизили и пофиксили пострелизные баги, и фича получила набор неизменных тестов которые рутинно прогоняются каждый последующий релиз.
Я уже ответил выше. Новый относящийся к конкретной фиче функционал / прочий уже имеющийся функционал. Я не знаю, как утрировать еще больше и объяснить еще проще.
Терминология нужна для нахождения общего языка.
Агрессивное пренебрежение общепринятыми терминами фактически значит, что вы не хотите находить общий язык со специалистами в своей сфере.
Если вы не хотите перенимать общий язык, то и в повседневной работе с вами тоже скорее всего будут конфликты на ровном месте.
Нахожусь в стадии осознанной некомпетентности, Савина и Куликова прочитал дважды.
Хочу к вам, возьмете?
Хочу к вам, возьмете?
Здравствуйте, Хабровчане, рада проявленному интересу :)
Подписываюсь под каждым словом, спасибо за поддержку позиции.
Похоже Вы на правильном пути :) У нас весьма увесистая программа обучения и погружения в ходе интернатуы, соответственно количество и размер групп интернов ограничен. Когда в каком-то из отделов тестирования открывается поиск интернов, HR размещают вакансию на всех работных сайтах, а также поднимают резюме, отправленные кандидатами через корпоративный портал. Полагаю, как и другие крупные компании…
Возможно Вы еще не попали в нужную волну, попробуйте провести «активный» поиск. А пока ждете ответов потренироваться на краудсорсинговых платформах — это полезно для понимания профессии и даже можно немножко денег заработать ;)
Не пофиг, хотя бы потому, что когда надо будет одним предложением описать текущий статус разработчику, какое тестирование тут было сделано, то сказать функциональное закончено, регрессионное сделано сделано на половину и надо еще столько-то времени, а нагрузочное еще не начинали и на него надо еще столько-то, то это как минимум намного быстрее и точнее, чем пытаться описать то же самое своими словами
Подписываюсь под каждым словом, спасибо за поддержку позиции.
Нахожусь в стадии осознанной некомпетентности, Савина и Куликова прочитал дважды.
Хочу к вам, возьмете?
Похоже Вы на правильном пути :) У нас весьма увесистая программа обучения и погружения в ходе интернатуы, соответственно количество и размер групп интернов ограничен. Когда в каком-то из отделов тестирования открывается поиск интернов, HR размещают вакансию на всех работных сайтах, а также поднимают резюме, отправленные кандидатами через корпоративный портал. Полагаю, как и другие крупные компании…
Возможно Вы еще не попали в нужную волну, попробуйте провести «активный» поиск. А пока ждете ответов потренироваться на краудсорсинговых платформах — это полезно для понимания профессии и даже можно немножко денег заработать ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стань тестировщиком, если хочешь