Спасибо!
Мы гибкие, учитываем реальные потребности/особенности Заказчика, и работаем с большой линейкой TMS.
Моя позиция, Zephiyr Scale сейчас, наилучший инструмент управления тестированием на базе JIRA. Поэтому он входит у нас в конфигурацию по-умолчанию.
Здравствуйте, Хабровчане, рада проявленному интересу :)
Не пофиг, хотя бы потому, что когда надо будет одним предложением описать текущий статус разработчику, какое тестирование тут было сделано, то сказать функциональное закончено, регрессионное сделано сделано на половину и надо еще столько-то времени, а нагрузочное еще не начинали и на него надо еще столько-то, то это как минимум намного быстрее и точнее, чем пытаться описать то же самое своими словами
Подписываюсь под каждым словом, спасибо за поддержку позиции.
Нахожусь в стадии осознанной некомпетентности, Савина и Куликова прочитал дважды.
Хочу к вам, возьмете?
Похоже Вы на правильном пути :) У нас весьма увесистая программа обучения и погружения в ходе интернатуы, соответственно количество и размер групп интернов ограничен. Когда в каком-то из отделов тестирования открывается поиск интернов, HR размещают вакансию на всех работных сайтах, а также поднимают резюме, отправленные кандидатами через корпоративный портал. Полагаю, как и другие крупные компании…
Возможно Вы еще не попали в нужную волну, попробуйте провести «активный» поиск. А пока ждете ответов потренироваться на краудсорсинговых платформах — это полезно для понимания профессии и даже можно немножко денег заработать ;)
Не знаю, какую теорию и как спрашивали на собеседованиях у Вас, возможно опрос действительно был избыточным. Лично я на собеседованиях акцентируюсь на опыте и навыках кандидата. В статье есть еще 2 части, кроме теоретической, но раз именно она вызывает резонанс давайте на ней остановимся
Если человек смышленый, но не знает вашей терминологии, это помешает ему в работе настолько сильно, что он не справится от их неужели такого большого количества и сложности?
ну терминология все же не моя личная, и, как мне кажется, смышленный человек без труда осилит одну небольшую книгу ;)
Оглянитесь вокруг, все компьютеризировано — передвижения, связь, платежи, развлечения, медицина, оборонка — все сферы жизни пронизаны системами, среди них есть жизненно важные и бесконечно сложные, и каждая из них кем-то протестирована. Представьте, если тестирование будет не качественным хотя бы в половине случаев, Вы просто огорчитесь, если сломается любимая игрушка, ну а если упадет самолет? Так что не соглашусь, что тестирование — это просто. Цена ошибки может достигать миллионов рублей и человеческих жизней. Погуглите, сколько стоят самые дорогие баги
Теория — это база для будущих навыков, соглашусь, что заучивание терминов, пожалуй последнее, что нужно делать) Теорию нужно… «разобрать», тогда и термины Вы запомните без заучивания.
К примеру, под «фунциональным тестированием черным ящиком» лежат подходы к тест-дизайну с помощю которых Вы будете выполнять полезные тесты, и не тратить время на бесполезные. «Черноящичные» техники самые простые из всех существующих, поэтому стоит начать с них. Под «выбором тестов в ограниченных временных рамках» лежат подходы к приоритезации тестов, а это позволит Вам не выпускать в Prod блокирующие дефекты. Начните изучение и другие теоретические вопросы в списке окажутся не такими уж теоретическими и совсем не про термины
Доброго вечера. Мне жаль, что статья Вас огорчила, чем бы Вы заменили раздражающие термины?
Вообще любая терминология необходима для понимания друг друга. Если Ваша команда решила назвать регрессионное тестирование «охотой на бабочек» и все в точности понимают, что и в какой последовательности будут делать во время этой операции и какой результат получат, смело называйте его своим термином. Однако Вы сможете им пользоваться только внутри своей команды, другие тестировщики и команды Вас уже не поймут.
(Хорошим) Результатом тестирования я все же считаю не столько заведенные дефекты в тесте, сколько НЕ заведенные дефекты после выпуска релиза.
Мы гибкие, учитываем реальные потребности/особенности Заказчика, и работаем с большой линейкой TMS.
Моя позиция, Zephiyr Scale сейчас, наилучший инструмент управления тестированием на базе JIRA. Поэтому он входит у нас в конфигурацию по-умолчанию.
Подписываюсь под каждым словом, спасибо за поддержку позиции.
Похоже Вы на правильном пути :) У нас весьма увесистая программа обучения и погружения в ходе интернатуы, соответственно количество и размер групп интернов ограничен. Когда в каком-то из отделов тестирования открывается поиск интернов, HR размещают вакансию на всех работных сайтах, а также поднимают резюме, отправленные кандидатами через корпоративный портал. Полагаю, как и другие крупные компании…
Возможно Вы еще не попали в нужную волну, попробуйте провести «активный» поиск. А пока ждете ответов потренироваться на краудсорсинговых платформах — это полезно для понимания профессии и даже можно немножко денег заработать ;)
ну терминология все же не моя личная, и, как мне кажется, смышленный человек без труда осилит одну небольшую книгу ;)
Оглянитесь вокруг, все компьютеризировано — передвижения, связь, платежи, развлечения, медицина, оборонка — все сферы жизни пронизаны системами, среди них есть жизненно важные и бесконечно сложные, и каждая из них кем-то протестирована. Представьте, если тестирование будет не качественным хотя бы в половине случаев, Вы просто огорчитесь, если сломается любимая игрушка, ну а если упадет самолет? Так что не соглашусь, что тестирование — это просто. Цена ошибки может достигать миллионов рублей и человеческих жизней. Погуглите, сколько стоят самые дорогие баги
Теория — это база для будущих навыков, соглашусь, что заучивание терминов, пожалуй последнее, что нужно делать) Теорию нужно… «разобрать», тогда и термины Вы запомните без заучивания.
К примеру, под «фунциональным тестированием черным ящиком» лежат подходы к тест-дизайну с помощю которых Вы будете выполнять полезные тесты, и не тратить время на бесполезные. «Черноящичные» техники самые простые из всех существующих, поэтому стоит начать с них. Под «выбором тестов в ограниченных временных рамках» лежат подходы к приоритезации тестов, а это позволит Вам не выпускать в Prod блокирующие дефекты. Начните изучение и другие теоретические вопросы в списке окажутся не такими уж теоретическими и совсем не про термины
Вообще любая терминология необходима для понимания друг друга. Если Ваша команда решила назвать регрессионное тестирование «охотой на бабочек» и все в точности понимают, что и в какой последовательности будут делать во время этой операции и какой результат получат, смело называйте его своим термином. Однако Вы сможете им пользоваться только внутри своей команды, другие тестировщики и команды Вас уже не поймут.
(Хорошим) Результатом тестирования я все же считаю не столько заведенные дефекты в тесте, сколько НЕ заведенные дефекты после выпуска релиза.