Содержание
Именно потому, что смешали пол биологический с полом психологическим — это пример плохой, неортогональной классификации. Я к тому, что требовать четкие ответы там, где их не существует — это идиотизм. И скорее говорит о том, что интервьюер сам мало что знает и просто самоутверждается задрачивая по нюансам не имеющим реального значения.
Еще когда-то был офигенный сайт по теории тестирования, в котором и доступно было написано, и на ISTQB многое завязано, но не могу найти… Уже на четвертой странице гугла по запросу types of testing, там уже и про тестирование на коронавирус, на дислексию, тестирование косметики на животных… Биологический пол — это тоже ортогональная классификация. С полом юридическим сейчас в мире стало сложнее.
- Сначала нужно было протестировать сайт.
- Что может сочетаться, а что — нет.
- Только ничего другого они не умеют.
- Более того, эта вся классификация нужна только чтобы пройти собеседование.
- Конечно, формулировка не идеальная.
Если не встало, сразу блокер на всю дальнейшую работу. Специально для этого добавил слово «конечный» объект тестирования. Документация пишется для продукта, а не сама для себя. https://deveducation.com/ Конечно, формулировка не идеальная. Особенно если начать уточнять что именно входит в понятие «выполнение» . Правильный ответ в том, что тестировать можно вообще всё.
Тестировщики отзовитесь! Помогите расставить по полочкам!
Ну короче, пока этого protesting (хоть он и .ru, вэ) должно хватить. Много лишней инфы, которую они там сами себе изобрели, которую джуну тяжело осмыслить. На собеседовании сертификат будет за плюс, канеша, но сдавать его слишком рано — это тупо зубрить, лучше б году этак на втором-третьем опыта. Тест установки — пишут, что нефункциональное, но мне это кажется странным. Кажется логичным, что это ж первая функциональность при тестировании приложения, десктоп или мобайл или что там еще.
Регрессионное тестирование отвечает на вопрос «Не поломалось ли в ПО что-нибудь? В другом моменте приемочное тестирование может быть «Белый ящик» (прозрачный, вообще-то, а серого не существует), статистическим, ручным. А иногда динамическим, «прозрачный ящик», и вполне себе ручным.
Співбесіда з QA. 250+ запитань для Junior, Middle, Senior
С безопасностью зависит от деталей. Может быть и функциональное и нефункциональное. И Black box и experience — based. Cтресс тестирование — это нефункциональное негативное тестирование. Можно сказать, что это негативное перформанс тестирование.
Smoke test — это, скорее, уровень тестирования. По словарю ISTQB отличается от Acceptance testing разве что фиксированным набором тестов. Ru.wikipedia.org/…ов_и_методов_тестирования— этого списка должно быть достаточно. Точно такая же ситуация меня интересует с Смоук-тестированием, тестирование документации, стресс тестирование, тест установки, юзабилити, безопасности и т.д.
Не вижу смысла выделять в отдельный вид. Скорей всего будет обязательным компонентом Smoke/Acceptance тестирования. Стресс-тестирование — это один из видов confirmation testing это нагрузочного тестирования, которых много и т.д., это НЕфункциональное тестирование. Регрессия, смоук и санити — это тестирование, связанное с изменениями.
Теорія тестування
Только ничего другого они не умеют. В тестировании есть — Уровни, Типы иВиды тестирования. Джун мог об этом что-то слышать, если изучал в институте.
Если автора фейлят на «видах и типах» тестирования, то это проблема интервьюера и фиксить тут нужно его. Ни один адекватный человек не будет наказывать за незнание того, чего в нормальном виде не существует. Главное хоть как-то категоризировать и понимать о чем это. В некоторых источниках, виды это — функциональное, нефункциональное тестирование и связанное с изменениями.
Со стороны разницы как будто нет. Разница всегда в том, что разные виды тестирования отвечают на разные вопросы (или же — приносят разную информацию). Мне, например, не нужна классификация в виде дерева. Нужен набор разных групп классификации, но внутри каждой группы равноправные ветви должны быть ортогональны и минимизированы. Та к сожалению нет, особенно на джунов, почему-то считают, что без теории тестирования работать невозможно. А бывают коллеги, которые «Нет, это сразу отказ, как можно этого не знать».
Теорія тестування
И то, ответ скорее всего будет «слышал, могу расшифровать». Ну в c# такие слова тоже есть, правда смысла такое спрашивать на собесе не вижу. Плюс еще — думать наперед, какие задачи и процессы приносят деньги бизнесу (и сколько), а какие — нет.
Співбесіда з QA. 250+ запитань для Junior, Middle, Senior
В какой-то момент приемочное тестирование может быть интеграционным, динамическим, автоматизированным. Сначала нужно было протестировать сайт. Вот просто взять и протестировать. Все протестировать, включая нагрузочное.
При менторинге новичков, канеша, надо во все это вдаваться, объяснять, что все такое разное, у всех все по-своему, каждому свое, жизнь сложная штука… А потом во время работы и набирания опыта уже сами все обрастают. Просто почему-то до сих пор на всех собеседованиях, где собеседуют меня и где собеседую я с коллегами, именно эти ответы принимаются как правильные и все удовлетворенно кивают головами. Просто пример систематизированной подачи знаний. П.2 повторяет ISTQB классификацию с которой я не совсем согласен из за запутывающей терминологии и ее неортогональности.
Тестировщики отзовитесь! Помогите расставить по полочкам!
Причем, как правило, по своему их пониманию. Даже если в медицине есть своя класификация тестирования, ее знание — это не настолько принципиальный момент, чтобы отсеивать кандидата. Если это тестовая документация (тест-план, тест-стратегия, кейсы, саммари репорт), то тоже это просто ревью за кем-то, чтобы все было на местах, ап ту дейт и ниче не забыли. Какую-то сложную документацию по сложным проектам обычно не куа, а менеджмент читает, хотя куа тоже могут вовлечь, канеша, но мне не приходилось никогда сталкиваться. Установочное тестирование — это просто функциональное позитивное тестирование фичи установки приложения.