Comments 29
По степени важности тестируемых функций
Скорее по степени детализации. Смоук тест покажет наличие условного дыма. А важное или неважное было затронуто, все пропало или кто-то просто решил закурить - это отдельные вопросы, требующие потом более детальной проработки. А вообще шикарная работа, утащил в закладки.
Весьма комплексный подход к классификации различных типов тестирования. Полезен как для новичков, так и для опытных специалистов. А примеры из реальной жизни прекрасно дополняют и позволяют примерить тему к своим задачам!
Спасибо!
Братюня, все эти классификации — для ярких глазами дурней, которым хочется ощущения ясности, уютности и весомой грубой зримой последовательно. Ты бы занялся изучением этих явлений, а не из систематизацией, потому что ты сейчас сам себе выковал, залил бетоном и обустроил схему понятий на всё твоё будущее. Позже ты будешь биться в её жёстких границах в поисках решения противоречий, которые сейчас тебе незаметны, но в будущем станут яркими и болезненными — и не найдёшь выхода, потому что вот такую основу ты себе придумал и сомневаться в основе (своей же) ты не будешь. И тогда бросишь ты это дурное дело и будешь круглосуточно генерировать картинки в нейросетях.
Вместо классификации всего этого вороха ты мог бы сосредоточиться в поисках определения термина «регресс» — сам по себе, а не в тестировании, и тогда ты понял бы однозначно, почему есть такой вид тестирования, зачем он нужен и когда его есть смысл применять. И почему его назвали именно так.
Или врубился бы, что нет никакого «санитарного тестирования» — спроси об этом у любого санитара.
И уж точно не стал бы закатывать smoke строго как подвид регрешна.
И понял бы, почему ad hoc тестирование так называется (к слову, где оно в твоей схеме?).
И, возможно, познакомился бы с термином «метафора».
И спросил бы, почему альфа называется альфой, а не буквой любого другого алфавита. И если есть альфа и бета, то где гамма тестирование? Сперва ты снисходительно похихикал бы над этим вопросом, а потом узнал бы, что их было даже больше… (здесь была ссылка, которую я удалил, бо ты сам до неё должен дойти)
Так что добро пожаловать в большое тестирование, но помни о том, что тестировщики сперва спрашивают и сомневаются, и только потом классифицируют. И то — с пометкой о её временности и неоднозначности.
Моя статья – это систематизация основных видов тестирования для облегчения понимания классификаций и большей наглядности, чтобы не приходилось метаться между разными источниками в поиске определения или примера. У меня не было цели проводить глубокое исследование всех видов или определенных терминов.
Кто-то найдет пользу для себя в этой статье, кто-то захочет копать глубже изучая другие виды.
С опытом, возможно, я взгляну иначе на эту статю или ее фрагменты, в любом случае спасибо за мнение, есть повод задуматься!
Да, разумеется, это было понятно.
А, к слову, почему «ad hoc тестирование» называется таким странным названием?
Кто-то переводит ad hoc как "ситуативный, случайный". Также прочитал, что данный термин применяют только к каким-то конкретным, спонтанным задачам, для которых нет универсальных решений и к которым не готовятся заранее.
Поделитесь, если есть другие значения
Это юридический термин, пришедший из древнеримского подхода к организации заседаний, судов и всего такого прочего — https://ru.wikipedia.org/wiki/Ad_hoc
Любое заседание должно идти по регламенту — списку вопросов, которые надо обсудить (набор тест-кейсов для выполнения), и без отклонений, иначе никакое заседание никогда не завершится. Могут возникнуть темы, которые следует обсудить СРОЧНО, поверх уже согласованного списка или вопреки ему — галлы наступают без предупреждения, Карфаген прислал оскорбительный емайл, в ларёк рядом со зданием суда завезли свежий лимонад (сунуть нос куда-то помимо уже существующих тест-кейсов).
ВНЕЗАПНАЯ тема для обсуждения вносится в регламент с пометкой ‘ad hoc‘ (в зависимости от срочности — в моменте или вносится в конец списка), отрабатывается, затем все возвращаются к теме обсуждения из регламента.
Без этого контекста логично подумать, что тестирование ad hoc — полная противоположность регламентированному тестированию, и делается всегда без оглядки на требования, в свободном, бессистемном, поэтическом режиме. Это заблуждение, потому что без требований нет ожидаемого результата, а без ожидаемого результата нет тестирования, есть исследование, изучение, выяснение, не более. Ad hoc testing всегда дополняет регламентированное тестирование, а не заменяет его (и не противопостоит ему), и, конечно же, нуждается в понимании общего контекста и в учёте требований.
Название очевидно метафоричное, переносящее смысл. В тестировании вообще много терминов являют собой метафоры, которые устоялись до потери смысла. Почему регрессионное тестирование называется регрессионным? «Да не всё ли равно, у нас на проекте это знать не требуется!» ©)
Ещё есть менее известное латинское же (когда-то меметичное) выражение Ab hoc et ab hoc — так и сяк, без толку. И ещё множество других ad ***, которые были известны людям с классическим образованием на базе древних текстов на латыни и греческом — те самые древние инженеры, которые придумывали компьютеры.
Так что ещё раз вопрос — где в предлагаемой классификации ad hoc testing? В какой раздел он должен быть насильно втиснут?
Кому-то походит дедуктивный подход в изучении нового, кому-то - индуктивный. Классификация чего-то по схожим признакам является хорошим способом успокоить шум в голове для тех, кто еще не знаком с изучаемой информацией, а также для тех, кто давно использует её, но не до конца владеет терминологией. На мой взгляд, труд не бесполезный, с примерами в тестировании всегда туго, и автор постарался от души. Не думаю, что стоит нападать на него
Почему UX и l18n не относятся к функциональным?
Интернационализация может быть.
А вот тестирование UX - это совсем другая область и тестировщики, которые обычно работают в отделах тестирования, не имеют к ней никакого отношения.
Как минимум, потому что для тестирования UX нужно очень хорошо разбираться в том, как устроены пользовательские интерфейсы и почему они устроены именно так. Разбираться в usability, проектировании информационной архитектуры и в interaction design-е. А еще иметь информацию о целях пользователей, их проблемах, модели монетизации продукта, приоритетах в развитии продукта, планах по использованию dark patterns. Ну и еще о куче всего такого, что не входит в компетенции QA-инженера.
Без этого всё, что вы сможете протестировать - это нравится лично вам или не нравится. А ваше мнение (вы не пользователь и не ЦА) не может быть основанием считать ту или иную ситуацию дефектом UX.
А тестирование UX обычно называется исследованием. И занимаются этим совершенно другие специалисты - UX исследователи.
С одной стороны - да, супер-крутая классификация!
А с другой стороны - практический смысл такой классификации не понятен: кому и зачем она нужна?
А с третий стороны споры по повлжу почему классификация тпкая, а не иная могут стать как главным холиваром еслине месяца, то недели точно! :-)
Мне так проще было изучать виды, хотелось все уложить на одной схеме, чтобы не прыгать по разным источникам
Цель ваша понятная, но, боюсь, большинству читателей ваша детальная классификация не зайдёт ибо у них свои есть классификации.
Так смысла изучать нет, специализированные виды тестирования требуют отдельного и большого объема знаний.
Та же безопасность или производительность ... хоть заизучайся, но без глубоких знаний в лучшем случае "покорми собак и ничего не трогай"
Стрессовое от нагрузочного отличается целью. Стрессовое - это когда мы хотим поломать тестируемый продукт.
Нормально, я похожий список себе в заметках сам писал) в целом приемлемо, кратко и с примерами, как для собеса отличная инфа)
(П.С. Пример с маршрутами и вертолетом выдаёт в тебе падавана практикума :-D)
Супер:) спасибо за труд. Так же составлял, но у вас полноценнее получилось.
Мне не нравится такое определение модульного тестирования. Оно очень широкое и в него можно запихнуть много примеров (например пример данный в этой статье). Вообще фраза "отдельная часть приложения" недостаточно конкретная. Например фронтенд можно назвать отдельной частью приложения. Неужто мы будем считать что тестирование всего фронтенда приложения это модульное тестирование?
Отсюда идёт и неправильно определение интеграционного тестирования
Забавно, у нас на курсе шерится студентам очень похожая https://drive.google.com/file/d/13rjEGYP9cjcHbDp_0K_UVW33UV6Qnkyu/view?usp=sharing
Как мне захотелось систематизировать виды тестирования