×Закрыть

Тестировщики отзовитесь! Помогите расставить по полочкам!

Дорогие друзья, подскажите пожалуйста начинающему тестировщику.
В тестировании есть — Уровни, Типы и Виды тестирования.

Если с Уровнями и Типами все понятно.

Уровни тестирования:
*Приемочное
*Системное
*Интеграционное
*Модульное (компонентное)

Типы тестирования:
*Черный, Серый, Белый ящик
*Статистическое и динамическое тестирования
*Ручное и автоматизированное тестирование

То вот с видами тестирования какая-то беда возникла (по крайней мере у меня).

В некоторых источниках, виды это — функциональное, нефункциональное тестирование и связанное с изменениями.

В других источниках — их еще больше.

Но самое запутанное, это вот:
Например Регриссионное тестирование — это подвид Функционального тестирования или отдельный Вид тестирования?
Точно такая же ситуация меня интересует с Смоук-тестированием, тестирование документации, стресс тестирование, тест установки, юзабилити, безопасности и т.д.

ЭТО все отдельные виды тестирования или подвиды какого-то вида?

Подскажите плиз, а то голова уже кипит, запутался во всем этом.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дивіться на різні категорії, як на різні аспекти.
Поясню.
Регресивне тестування — це перевірка системи після змін. Вона може бути як і функціонально, так і не функціональною.
Смоук це дуже швидке тестування основного функціоналу. Переважно це функціональне тестування, але якщо вам важливі якісь аспекти безпеки\перформансу, можна і роботи смоук тести безпеки\перформансу

От як з автомобілем — є різні аспекти\характеристики як колір, тип кузова, мотор.
Чи може бути червоний седан на дизелі ? так ! і кожен з цих аспектів не залежить один від одного.

Опирайтесь на глоссарий ISTQB docs.google.com/...​4/edit?ts=59a52810#gid=21
Так же рекомендую книгу «Foundations of Software Testing: ISTQB Certification» by Dorothy Graham, понятнее силлабуса, после прочтения первой половины все вопрсосы по теории тестирования будут по полочкам в голове.

Это бюрократия. Тайна — её среда выживания и распространения. Чем больше непонятного — тем ценнее выглядят бюрократы, которые умеют «правильно» говорить «правильные» слова. Только ничего другого они не умеют.

Правильный ответ в том, что тестировать можно вообще всё. Даже тесты. Даже тесты тестов тестов.

Перестаньте стараться всё уложить в бетонножелезное ложе строгой типизации и родительско-дочерних связей.

ru.wikipedia.org/...​ов_и_методов_тестирования — этого списка должно быть достаточно. В это деле нет явного «дерева», от которого отходят явные и однозначные ветви, на которых, как яблоко, расположен каждый вид (тип, уровень, whatever) тестирования, занимал своё однозначное место на однозначной ветке.

Вы имеете дело с абстрактными явлениями, связи между которыми иногда отсутствуют, а иногда наследуются, и всё это вместе — нормально.

Для примера: вы кто? Игорь? Млекопитающее? Мужчина? Украинец? Сын? Тестировщик? Гомосапиенс? Рекрут ВСУ? Водитель? Пассажир? Вас можно классифицировать и, как яблоко, однозначно повесить на какую-то ветвь?

В какой-то момент приемочное тестирование может быть интеграционным, динамическим, автоматизированным.

В другом моменте приемочное тестирование может быть «Белый ящик» (прозрачный, вообще-то, а серого не существует), статистическим, ручным. А иногда динамическим, «прозрачный ящик», и вполне себе ручным.

В тестировании производительности упрятаны и тестирование производительности, и нагрузочное тестирование, и стресс-тестирование. Со стороны вы не поймёте, что именно тестировщик делает, нагрузочное или ненагрузочное. Но если ориентироваться по «какую информацию ему надо получить» — будет всё ясно. Если выясняет, может ли ПО работать под номинальной нагрузкой — это тестирование производительности. Если выясняет, может ли ПО работать под повышенной нагрузкой (и доколе) — это нагрузочное. Что именно выясняет тестировщик, который проводит стресс-тестирование?

Виды, подвиды... Регрессионное тестирование, как и смоук, может использовать абсолютно тот же набор тест-кейсов. Со стороны разницы как будто нет. Разница всегда в том, что разные виды тестирования отвечают на разные вопросы (или же — приносят разную информацию).

Регрессионное тестирование отвечает на вопрос «Не поломалось ли в ПО что-нибудь?» Поломаться оно может и от того, что кто-то изменил код — добавил, отредактировал, убрал,- и от того, что изменилось окружение — и вы плавно переходите в тестирование окружения, и от того, что ничего не менялось, а БД стала слишком большой и ПО его уже не тянет.

Смоук тестирование отвечает на вопрос «Будем ли углубляться в тестирование этого ПО полностью?» Бо если какие-то основные ветви функциональности (или сценариев, тут это неважно) недоступны, то зачем идти по ним вглубь? Остановились.

Еще раз: для обоих случаев можно использовать один и тот же набор тест-кейсов, но это два разных вида или типа тестирования? Да пофигу же!

А на каком уровне можно выполнять регрессионное тестирование? На разных!

А смоук? Тоже на разных? Да.

Классификация нужна, но когда вы одновременно и украинец, и сын, и водитель, но ваша машина сейчас в прицепном вагоне, а вы сидите в пассажирском вагоне с мамой и за руль вернётесь только после прибытия куда вам там надо было доехать — как это классифицировать однозначно?

Дальше вас ждут чудные открытия вроде разницы между smoke, sanity, confidence testing. Слова разные? Значит, и виды тестирования должны быть разные. Дойдёте своим разумением до того, что это три называния одного и того же вида (типа, уровня) тестирования? Вас всегда будут окружать более опытные и сердитые коллеги, которые ЗНАЮ, что это разные виды (типы, уровни), так было и так должно быть! Будете их переубеждать? Будете подстраиваться?

Конечно.

Для примера: вы кто? Игорь? Млекопитающее? Мужчина? Украинец? Сын? Тестировщик? Гомосапиенс? Рекрут ВСУ? Водитель? Пассажир? Вас можно классифицировать и, как яблоко, однозначно повесить на какую-то ветвь?

Мне, например, не нужна классификация в виде дерева. Нужен набор разных групп классификации, но внутри каждой группы равноправные ветви должны быть ортогональны и минимизированы.

Объясню на вашем примере, что такое грамотно составленная, не запутанная классификация:

1. Первое имя. Первое имя может быть Игорь или Вадим, но оно не может быть и тем и другим одновременно. (Игорьвадим будет в крайнем случае просто новым именем) — это хорошая, ортогональная классификация
2. Биологический класс — тоже хорошая классификация. Ты или млекопитающее или рептилия или паукообразное или... но не то и другое одновременно
3. Биологический пол — это тоже ортогональная классификация. С полом юридическим сейчас в мире стало сложнее. Именно потому, что смешали пол биологический с полом психологическим — это пример плохой, неортогональной классификации.

По каждой такой категории можно вполне однозначно классифицировать и повесить на ветвь.

Проблема классификации в тестировании, что такие группы есть далеко не везде. А также нет четкого понимания взаимосвязей. Что может сочетаться, а что — нет.

Биологический класс — тоже хорошая классификация. Ты или млекопитающее или рептилия или паукообразное или...

en.wikipedia.org/wiki/Tunicate

3. Биологический пол — это тоже ортогональная классификация.

en.wikipedia.org/...​Chimera_(genetics)#Humans

Источники расходятся. Единой, полной, ортогональной классификации не существует. Более того, я не вижу большой разницы между словами тип, вид, класс тестирования. Для работы знание классификации практически бесполезно. Если вам нужна эта информация для того чтобы проходить интервью, то я бы рекомендовал хоть как-то систематизировать:

1. По последовательности выполнения: тестирование новой функциональности, регрессионное тестирование, повторное тестирование.
2. По базису тестирования: функциональное=Black Box, White Box, нефункциональное (performance, usability, etc), experience-based
3. По подходу к предполагаемому результату: позитивное, негативное
4. По доступу к конечному объекту тестирования — статическое (не статистическое!) и динамическое
...
Классификация не идеальная. Просто пример систематизированной подачи знаний. п.2 повторяет ISTQB классификацию с которой я не совсем согласен из за запутывающей терминологии и ее неортогональности.

По остальному:
Smoke test — это, скорее, уровень тестирования. По словарю ISTQB отличается от Acceptance testing разве что фиксированным набором тестов.
Регрессионное тестирование — это явно не подвид функционального тестирования, так как регрессия может быть и не функциональной.
Cтресс тестирование — это нефункциональное негативное тестирование. Можно сказать, что это негативное перформанс тестирование.
Установочное тестирование — это просто функциональное позитивное тестирование фичи установки приложения. Не вижу смысла выделять в отдельный вид. Скорей всего будет обязательным компонентом Smoke/Acceptance тестирования.
Usability — вид нефункционального тестирования.
Тестирование документации — вид статического тестирования
С безопасностью зависит от деталей. Может быть и функциональное и нефункциональное. И Black box и experience — based.

Надеюсь помог. Почитайте ISTQB syllabus и Glossary. Полностью вопрос не решают, но чем-то помогут.

4. По доступу к конечному объекту тестирования — статическое (не статистическое!) и динамическое

а с этого момента поподробнее ))))

static testing: Testing of a software development artifact, e.g., requirements, design or code,
without execution of these artifacts, e.g., reviews or static analysis.
dynamic testing: Testing that involves the execution of the software of a component or
system.
Специально для вас процитировал словарик ISTQB.
Если взаимодействуем с конечным объектом тестирования — это динамическое. Если не взаимодействуем напрямую — статическое.

Спасибо что процитировали.
Но судя вашим словам, например если мы тестируем требования — это динамическое тестирование, так как

Если взаимодействуем с конечным объектом тестирования — это динамическое

?

У тебя конечный объект — пользователь, а не бумажка

Пацаны, вы определитесь, что для вас

конечный объект

пользователь или система )

Специально для этого добавил слово «конечный» объект тестирования. Т.к. документация пишется для продукта, а не сама для себя. Конечно, формулировка не идеальная. Точно также как и ISTQB-шная. Особенно в переводе. Особенно если начать уточнять что именно входит в понятие «выполнение» (execution).

В некоторых источниках, виды это — функциональное, нефункциональное тестирование и связанное с изменениями.

Это самый подходящий ответ.

Регрессия, смоук и санити — это тестирование, связанное с изменениями.
Тестирование документации обычно в какой-то отдельный вид не выделяют, это просто часть рабочего процесса, который чаще проходит не так, что есть какие-то требования, кейсы, процессы, а протом собирается какой-то груминг/планинг и все читают требования и задают вопросы. Если это тестовая документация (тест-план, тест-стратегия, кейсы, саммари репорт), то тоже это просто ревью за кем-то, чтобы все было на местах, ап ту дейт и ниче не забыли. Какую-то сложную документацию по сложным проектам обычно не куа, а менеджмент читает, хотя куа тоже могут вовлечь, канеша, но мне не приходилось никогда сталкиваться.
Стресс-тестирование — это один из видов нагрузочного тестирования, которых много (load, performance, recovery) и т.д., это НЕфункциональное тестирование.
Тест установки — пишут, что нефункциональное, но мне это кажется странным. Кажется логичным, что это ж первая функциональность при тестировании приложения, десктоп или мобайл или что там еще. Если не встало, сразу блокер на всю дальнейшую работу.
Юзабилити — НЕфункциональное.
Секьюрити — функциональное.

ЭТО все отдельные виды тестирования или подвиды какого-то вида?

Все подвиды.

Ща попытаюсь ссылки найти, где хорошо описано, чтобы нагляднее было.
www.protesting.ru/testing/testtypes.html — осьо прям вся структура.

ISTQB Foundation level тоже рекомендую, там ниже уже упоминали.
2.3 Test Types ................................................................................................................................. 39
2.3.1 Functional Testing ................................................................................................................. 39
2.3.2 Non-functional Testing .......................................................................................................... 40
2.3.3 White-box Testing ................................................................................................................. 40
2.3.4 Change-related Testing ......................................................................................................... 41
2.3.5 Test Types and Test Levels .................................................................................................. 41

www.istqb.org/...​l-syllabus-2018-v3-1.html

Еще когда-то был офигенный сайт по теории тестирования, в котором и доступно было написано, и на ISTQB многое завязано, но не могу найти... Уже на четвертой странице гугла по запросу types of testing, там уже и про тестирование на коронавирус, на дислексию, тестирование косметики на животных...
Ну короче, пока этого protesting (хоть он и .ru, вэ) должно хватить. ISTQB хорош, но только местами. Много лишней инфы, которую они там сами себе изобрели, которую джуну тяжело осмыслить. На собеседовании сертификат будет за плюс, канеша, но сдавать его слишком рано — это тупо зубрить, лучше б году этак на втором-третьем опыта. Но это так, имхо.

Ну в общем, гуглить все, читать все. Сначала будет казаться, что инфу в голову ногами в грязных ботинках запихивают, а со временем оно начнет по полочкам раскладываться. После каждого проваленного собеседования будет понятно, где зафейлился и что еще подучить надо. Короче, все там были и проходили одинаковый путь.

Ща попытаюсь ссылки найти, где хорошо описано, чтобы нагляднее было.
www.protesting.ru/testing/testtypes.html — осьо прям вся структура.

во многом противоречит ISTQB. Вряд ли это противоречие поможет запутавшемуся ;-)

Ну в общем, гуглить все, читать все. Сначала будет казаться, что инфу в голову ногами в грязных ботинках запихивают, а со временем оно начнет по полочкам раскладываться

Завидую. В мире тестирования разложилось очень слабо, а у Вас, видимо уже все ок.

После каждого проваленного собеседования будет понятно, где зафейлился и что еще подучить надо.

Если автора фейлят на «видах и типах» тестирования, то это проблема интервьюера и фиксить тут нужно его. Ни один адекватный человек не будет наказывать за незнание того, чего в нормальном виде не существует. Главное хоть как-то категоризировать и понимать о чем это.

Завидую. В мире тестирования разложилось очень слабо, а у Вас, видимо уже все ок.

Не соглашусь. Думаю разложилось у большинства.... просто у всех немного по разному )

«Разложилось» — это когда существует хотя бы одна полная ортогональная класификация.
Ее не существует. (обратное утверждение прошу доказать примером).

Вот пример каши из того же ISTQB:
test techniques делятся на Black Box, White box и Experience based. При этом Experience based могут использовать техники из Black box.

При этом Experience based могут использовать техники из Black box.

Это вы, простите, где прочитали?
experience-based test technique — A test technique only based on the tester’s experience, knowledge and intuition.

Это вы, простите, где прочитали?

Это, простите, я прочитал в ISTQB Syllabus 2018. Который я снова изволю процитировать:

Exploratory testing can incorporate the use of other black-box, white-box, and experience-based techniques.

Надеюсь, вы мне поверите наслово, то exploratory testing относится к experienced-based техникам. Это, как говорится, если „в лоб”.

Если чуть-чуть подключить префронтальную кору, то и в Error guessing технике можно найти следы black box:

Error guessing is a technique used to anticipate the occurrence of mistakes, defects, and failures, based on the tester’s knowledge, including:
...
— What types of mistakes the developers tend to make

Где девы часто косячат? На знаках >=, >, <=, <. 0 или 1й элемент. array.GetLength() или array.GetUpperBound(). А еще выбор типа данных и т.д. Это прямой путь к Boundary value analysis, который, снова-таки относится к Black Box.

Убедил?

Если автора фейлят на «видах и типах» тестирования, то это проблема интервьюера и фиксить тут нужно его

Если автора фейлят на «видах и типах» тестирования, то он попал на собес на проект связанный с медициной или чем то подобным.

я к тому, что требовать четкие ответы там, где их не существует — это идиотизм. И скорее говорит о том, что интервьюер сам мало что знает и просто самоутверждается задрачивая по нюансам не имеющим реального значения. Причем, как правило, по своему их пониманию. Даже если в медицине есть своя класификация тестирования, ее знание — это не настолько принципиальный момент, чтобы отсеивать кандидата. Это учится в течение пары дней.

Это учится в течение пары дней.

Все учится в течении пары дней.
Разобраться и понять — уже пару недель
Научится применять и анализировать — уже пару месяцев

нет, пара дней на все. Потому что всего лишь нужно поменять название переменных, а не переписывать код.

во многом противоречит ISTQB. Вряд ли это противоречие поможет запутавшемуся ;-)

Поэтому рекомендую ISTQB первые пару лет не сдавать, у них там своя атмосфера :)

Если автора фейлят на «видах и типах» тестирования, то это проблема интервьюера и фиксить тут нужно его. Ни один адекватный человек не будет наказывать за незнание того, чего в нормальном виде не существует. Главное хоть как-то категоризировать и понимать о чем это.

Та к сожалению нет, особенно на джунов, почему-то считают, что без теории тестирования работать невозможно. И мне часто приходится задавать вопросы про все эти виды, чем отличаются смоук от санити, северити от приорити, верификация от валидации и т.д., ну хоть узнать, что человек вообще готовился. А бывают коллеги, которые «Нет, это сразу отказ, как можно этого не знать».
Как мой завкаф говорил: «Не можна бути професіоналом своєї справи, не знаючи її історії». Можно. Мне даже на собесе на синьора раз удалось зафейлиться на этой базовой теории, потому что моя подготовка была сосредоточена на более технических вещах — апи, скл, командная строка, гит команды и всякие другие умные слова, а все это говно про типы-виды-уровни даже не пришло в голову повторить. Они меня спросили уровни, у меня вообще из головы вылетело, пришлось попросить привести пример одного из списка, чтобы оно в голове всплыло, и они на меня ТАК смотрели и все оставшееся собеседование глаза закатывали, что, наверное, мне там нужно было самовозгореться от стыда, что ли. Ну и к счастью отказали, мне там тоже че-то не понравилось.
Или там сидишь, потные ладони об колени вытираешь, пытаясь вспомнить все филды тест-плана и тест-стратегии, которые ни разу в жизни не приходилось писать и никогда не надо было, а потом приходишь на проект, где это надо, берешь тупо темплейт и заполняешь. Но очень важно прям наизусть все филды помнить и назвать, а не просто понимать смысл и различать их между собой.

чем отличаются смоук от санити

и чем же? Для ISTQB это одно и то же.

Осторожнее на ДОУ с такими вопросами, будет истерика dou.ua/...​rums/topic/13389/#1545011

www.protesting.ru/testing/types/smoke.html
www.protesting.ru/...​testing/types/sanity.html

В ISTQB FL по серчу smoke и sanity вообще результатов нет, там этих слов не используют (по крайней мере в силлабусе). В главе Change-related Testing называют 2 вида — Confirmation testing и Regression testing

А какой силлабус смотрите? Их же там вагон и маленькая тележка. А главное — зачем? Ищите в глоссарии.

Вы уверены в том, что старый (и, конечно, добрый) протестингру — надежный источник?

И что «Санитарный» — адекватный перевод?

Не и не :)

Вы уверены в том, что старый (и, конечно, добрый) протестингру — надежный источник?

Просто почему-то до сих пор на всех собеседованиях, где собеседуют меня и где собеседую я с коллегами, именно эти ответы принимаются как правильные и все удовлетворенно кивают головами.

И что «Санитарный» — адекватный перевод?

Да, перевод фигня, но как по мне, перевод вообще не нужен, все и так на суржеке говорят и знают, что такое смоук и санити. И даже вместо планирования говорят планинг.
При менторинге новичков, канеша, надо во все это вдаваться, объяснять, что все такое разное, у всех все по-своему, каждому свое, жизнь сложная штука... А потом во время работы и набирания опыта уже сами все обрастают. Или избавляются от.

Еще модель CMMi в некоторой мере можно считать стандартом

Есть стандарт ISTQB www.istqb.org/...​l-syllabus-2018-v3-1.html страница 39. Если я не ошибаюсь ISTQB в свою очередь базируется на ISO стандартах

Ага, на старому 9126, який замінили на 25010

И что ?
А вы оба стандарта прочитали?
Они друг другу противоречат и несовместимы ? :)

Так, читав. Не суперечать, але в кількох пунктах розходяться, що особливо ні на що не впливає, оскільки вони несуть рекомендаційний характер

Так и силлабус в 2018 году проапгрейдили

В тестировании полная каша, так как оно не является научной дисциплиной.
Более того, эта вся классификация нужна только чтобы пройти собеседование.
Еще хуже: каждая контора и каждый проект делает все по-своему.

Боюсь, уважаемый

В тестировании полная каша

только в вашей голове :)

Статья на dou это, конечно, это канон тестирования :-)

Подписаться на комментарии