Qa test: Путь QA бойца / Хабр

Содержание

Тестовое задание QA / Хабр

Некоторое время назад я проходил собеседование на позицию QA инженера в одной известной российской IT-компании. Мне была предложена задача, свое решение которой с позволения компании я опубликовал в своем блоге. Пост оказался очень популярным, за короткое время набрав несколько тысяч просмотров, и мне показалась светлой мысль продублировать его на Хабре. По правилам Хабра текст публикуется без смайликов.

Итак, задача звучала следующим образом: необходимо описать шаги для всестороннего тестирования простого карандаша с резинкой на одном из концов.

Решение — под катом.

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

Итак, имеем карандаш:

По условию задачи, поскольку никаких дополнительных условий не задано, поэтому полагаем, что:

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

2. Изначально неизвестно, заточил ли производитель карандаш на фабрике или нет — рассмотрим оба случая.

3. Резинка несъемная и расположена на противоположном конце карандаша.

4. Если предположить, что у нас в наличии имеется только один экземпляр карандаша, то тестирование можно провести не по всем пунктам — функционал тестирования заметно сузится, т.к. карандаш, увы, ресурс не восстанавливаемый — его нужно точить, им надо писать, а также делать с ним разные другие интересные вещи.

5. Ничего не сказано про упаковку, производителя и параметры карандаша. Предполагаем, что мы их все-таки имеем/знаем/видим. При обратном функционал тестирования будет несколько меньше.

Общие критерии оценки тестов:

Основными критериями оценки будем считать выполнение / невыполнение условий указанных тестов. В случае если тест выполняется, можно оценить результат по неким заранее заданным правилам (например, по десятибалльной шкале, 0 — ужасно, 10 — превосходно; а в целом критерий оценки может быть задан как угодно). Некоторые параметры дополнительно попытаемся представить в числовом выражении. На основе полученных данных можно создавать сводные характеристики различных моделей карандашей.

Основные Test Cases для тестирования карандаша будут выглядеть примерно так.

Начальные свойства «из коробки» или «беглый осмотр» (primary testing):

— Если карандаш изначально заточен: удостоверимся, что им можно писать «by default». Некоторые производители карандашей умудряются заточить их таким образом, что их необходимо предварительно затачивать еще раз, ибо при заточке по умолчанию они попросту не пишут.

— Если карандаш изначально не заточен: удобно ли нам в текущих условиях иметь не заточенный «по умолчанию» карандаш (например, когда под рукой нет точилки или канцелярского ножа)? Т.е. потребуется ли дополнительная «инициализация» карандаша в виде его предварительной заточки.

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

— Есть ли на карандаше маркировка, обозначающая (степень твердости, диаметр стержня, назначение, специфические параметры)? Указан ли производитель?

— Какая форма стержня: круглый, шестиугольный, треугольный, овальный с широким грифелем? На практике карандаши с круглым стержнем больше подходят для рисования, шестиугольные — для письма и черчения (при рисовании рука меньше устает при круглой форме, при письме и черчении — при шестиугольной). Карандаши с треугольным стволом удобны для детей и людей с ограниченными возможностями — в случае когда рука плохо держит карандаш.

— Стержень из древесины или из пластика?

— Есть ли на карандаше лаковое покрытие?

— Обращаем внимание на коробку и упаковку, а также маркировку на них: производитель и все параметры карандаша.

Качество изделия (quality estimation):

— На карандаше нет заусениц, неровностей, потеков от лака, прочих неопрятностей и заводских браков.

— Маркировка (если она есть) нанесена качественно, надписи не расплываются и четко читаются.

— Держатель резинки ровный, не цепляется за одежду и кожу.

Удобство использования (usability testing):

— Карандаш удобно держать в руке. При работе он не выскальзывает и не выпадает.

— Есть ли на карандаше «зона захвата» (gripp zone) — специальные шашечки из краски, не позволяющие карандашу скользить в руке ( 2001, Faber Castell). См. предыдущий пункт.

— Для слабовидящих: актуально использование карандашей с шестигранным или треугольным стволом. Карандаш с круглым стволом, укатившийся под стол, часто представляет для слабовидящего человека серьезную проблему.

Использование (functional testing):

Порисуем на бумаге.

— Убеждаемся, что карандаш вообще рисует.

— Убеждаемся, что цвет текста / качество рисунка / чертежа соответствует твердости карандаша (насыщенный, бледный, ретушь, etc…

— Проверим поведение карандаша при сильном надавливании грифелем карандаша на бумагу. Убедиться, что карандаш не сломается.

— Потянем за грифель карандаша. Он не должен выходить из ствола.

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

— Грифель не ломается и не крошится и непосредственно при рисовании.

— Карандаш не пачкает руки и одежду, не оставляет дополнительных следов на рисунке.

— При рисовании ствол карандаша чистый, он не собирает на себя микробы и грязь с рук. Лучше всего в этом смысле карандаши с лакированным стволом.

Используем резинку на карандаше.

— Насколько резинка на конце карандаша вообще имеет смысл — она больше в работе или же больше мешает?

— Резинка стирает записи/рисунки, не размазывает и не «грязнит».

— Резинка со временем не «дубеет» и продолжает исполнять свои функции.

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

— Карандаш пишет на тех местах, на которых были стерты записи резинкой.

— То же самое проделаем с резинкой, взятой не от карандаша.

— Теперь будем чертить, а затем писать карандашом: все те же действия, но в немного других исходных условиях (до этого мы рисовали). Разные карандаши предназначены для различных целей: школьные, канцелярские, чертежные, рисовальные (в мире выпускается более 370 (!) разных типов и видов карандашей, так что простор для фантазии весьма богатый).

— Далее попробуем рисовать/чертить/писать не на бумаге, а на альтернативных материалах — плотная бумага, картон, газета, деревянный брусок, стены, пол (актуально при ремонтных и строительных работах).

— Порисуем через копирку. Не должно возникнуть каких-либо специфических проблем.

— Хранение и транспортировка: помещается ли карандаш в подставку для карандашей (соответствуют ли параметры)? Насколько удобно он помещается и переносится в кармане, в сумке? Не колется ли при этом, не ломается, не крошится?..

Экологичность (ECO testing):

— Если ствол карандаша покрыт лаком: используется лак на полимерной или на водной основе?

Этот пункт также можно отнести к тестированию безопасности изделия. К сожалению, выяснить на 100% для всех карандашей невозможно — на коробке это пишется далеко не всегда. Разве что химический анализ поможет.

Это требование весьма актуально, ибо очень часто дети (и не только!) попросту «съедают» карандаши. По моим подсчетам, я сам съедаю по несколько карандашей в год. Сколько при этом я получу вредных веществ от такой привычки, если карандаш не безопасен — науке доподлинно неизвестно. При желании можно было бы попытаться подсчитать, но что-то не хочется…

С точки зрения экологичности самые лучшие карандаши — нелакированные и без резинки (они, кстати в великом множестве встречаются в магазинах Ikea, Leroy Merlen и т.п.). И именно по этой причине лично я недолюбливаю карандаши с резинкой на конце — ИМХО есть ее, а особенно железный держатель есть неудобно вдвойне.

Безопасность (security testing):

— Можно ли пораниться карандашом (поцарапаться, порезаться при заточке, опасен ли карандаш для глаз)?

— Можно ли дать карандаш ребенку? Существуют «безопасные» виды карандашей (например, специальные «детские», часто — с треугольным стволом), которые можно давать детям без опаски (естественно, руководствуясь возрастом, общим развитием и особенностями ребенка).

— Безопасен ли карандаш для людей с ограниченными возможностями (например, для слабовидящих)?

— Соответствует ли карандаш принятым стандартам (ISO, ГОСТ, etc…).

Внеший вид (appearance, ergonomic and usability testing):

— Цвет карандаша. «Классический» ствол желтого цвета в стиле «Koh-I-Noor» или же альтернативная не-классика? При выборе карандаша люди руководствуются разными соображениями.

— Общая привлекательность, оформление и дизайн.

— Ствол круглый, треугольный или шестигранный.

— Упаковка/дизайн приносит или не приносит эстетическое удовлетворение и в целом радует глаз или нет.

Здесь можно иметь дополнительные данные и сделать дополнительные выводы: какова потенциальная целевая аудитория покупателей данной модели, насколько хорошо он будет продаваться и в каких местах, каковы его основные маркетинговые свойства, нужно ли рекламировать, каким образом и сколько денег тратить на рекламу и т.п. Я не маркетолог, но могу предположить, что за этим скрывается отдельная большая тема, которую здесь трудно будет раскрыть.

Заточка карандаша.

Возможные вариации заточки:

— Затачиваем точилкой для карандашей.

— Затачиваем шкуркой (актуально для мягких карандашей и карандашей для ретуширования).

— Затачиваем опасной бритвой.

— Затачиваем канцелярским ножом.

— Затачиваем кухонным ножом (тесаком, медицинским скальпелем, etc.)

— В отсутствии инструментов заточки затачиваем (пытаемся) неподходящими для этого средствами (например, зубами, куском стекла или вилкой). В результате, вероятнее всего, будет epic fail, но тем не менее имеет место быть.

Критерии оценки заточки (для каждого инструмента):

— Карандаш вообще затачивается данным инструментом. Например, заточить карандаш с пластиковым стволом с помощью шкурки или опасной бритвы будет весьма затруднительно. Заточить маленький (сточенный) карандаш с помощью охотничьего тесака также будет проблематично.

— Карандаш затачивается легко. Очень актуальный тест: некоторые карандаши при заточке оказываются абсолютно «железными» и заточке не поддаются в принципе (лично наблюдал такой пример на карандашах одного известного производителя).

— В процессе заточки и после нее грифель не нарушил свою целостность.

— В процессе заточки и после нее карандаш не ломается и не крошится.

— Ствол карандаша не расслаивается, после заточки нет заусениц, неровностей и других повреждений.

— Грифель не выпадает из ствола.

— Для залакированных карандашей: лак не отслаивается кусками от ствола и не крошится.

— Заточенный карандаш успешно функционирует (можно писать, рисовать, чертить).

— Коэффициент успешности заточки K = M / N, где M — количество удачных заточек, N — количество неудачных заточек. Чем меньше K, тем хуже карандаш затачивается с помощью данного инструмента.

Далее действуем по принципу «Пытаемся поломать все, что ломается» (чтобы потом все правильно работало, конечно).

Использование в экстремальных условиях (stress testing):

— Уронить карандаш на пол несколько раз. В идеале грифель не должен сломаться или раскрошиться. Ствол карандаша не должен иметь повреждений.

— Попытаться согнуть карандаш, приложив усилие: сломается или нет?

— Будем грызть карандаш с особым усердием. Конец карандаша не должен быть «съеден». Многие производители уделяют этому моменту особое внимание.

Мы любим карандаши Ikea!

Они маленькие — помещаются в маленькую сумку.

Они крепкие — можно уронить несколько раз.

Они вкусные — можно погрызть

— Поместим карандаш в воду, затем высушим.

— Поместим карандаш в кислотную, щелочную среду ненадолго.

— Заморозим, а затем отогреем. Вариант — положить в снег на морозе.

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

— Если бюджет тестирования не ограничен или тестирование хорошо оплачивается производителем в рекламных целях — проведем испытания в условиях невесомости. Космонавты на МКС по специфическим причинам, возникающим в невесомости, кстати, пользуются обычными грифельными карандашами…

Каждая из манипуляций, описанных выше, так или иначе окажет определенное воздействие на карандаш. После каждой из итераций тестируем использование карандаша (см. functional testing), производим заточку. Внешний вид тестировать больше не будем — есть подозрения, что если произвести над карандашом все перечисленные манипуляции, то это будет уже не карандаш, а в лучшем случае некое его подобие.

Тестирование производительности (performance testing, или напоследок немного простейшей математики):

Попытаемся измерить производительность карандаша: на сколько страниц текста/рисунков его хватит. Можно это сделать вручную, однако проблема заключается в том, что это будет весьма долгий и трудоемкий процесс, поскольку «изрисовать» целый (особенно качественно сделанный) карандаш достаточно трудно. Можно проделать все операции вручную, а можно воспользоваться элементарной математикой.

Представим, что есть некие эмпирически подсчитанные усредненные показатели: сколько страниц текста/рисунков можно нарисовать карандашом определенной длины, твердости, определенной формы и с определенным диаметром стержня. Пусть это будет называться «КПД карандаша» и будет составлять X страниц A4 (или X километров текста) для карандаша длины Y см. (данные берем: у производителя, в Google, в библиотечных источниках — нужное подчеркнуть). Допустим также, что эмпирические расчеты немного неточны и используют длину карандаша «под ноль», а так как пользоваться карандашом длиной менее 4 см весьма затруднительно, плюс 1 см на резинку с держателем, то на «реальную» работу у нас остается (Y — 5) см. Одно затачивание «отнимает» у карандаша около 1 см длины, поэтому на один карандаш стандартной длины 18 см. у нас есть приблизительно 13 заточек. При заточке карандаш может сломаться. Считаем, сколько было неудачных заточек за время работы карандаша; пусть это число будет равно N. Пусть длина карандаша равна L см. Тогда:

Реальный КПД карандаша = (L — 5 — N) * (X/Y)

Можно предположить, что после того, как карандаш уже сточен наполовину, число неудачных заточек некоторым образом увеличится, например с коэффициентом K. Тогда:

Реальный КПД карандаша = ((L — 5 — N)/2 + (L — 5 — K*N)/2) * (X/Y)

Можно и по-другому: посчитаем количество удачных заточек, исходя из реальных данных, полученных опытным путем в ходе заточки карандаша. Пусть это будет V. Тогда:

Реальный КПД карандаша = V * X / Y

Понятно, что расчеты весьма условны, и при желании можно усложнить расчеты, придумать более точные критерии — этот пример не делает целью точно подсчитать КПД карандаша, а попросту показывает, что данное измерение подвержено математическим расчетам.

P.S.:

Можно придумать еще много чего. Наверняка.

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

Результат тестирования можно представить в графическом виде.

Кто ты, QA-инженер или тестировщик?

Оригинальная публикация

Автор: Евгений Иванченко

QA и QC — как камыш и рогоз. Конечно, есть ботаники, которые их различают, но большинство людей всё-таки путают. Иногда самим QA и QC легче согласиться с представлением обывателей, чем пускаться в долгие объяснения, в чём же всё-таки разница. Предлагаю сделать усилие над собой, разобраться с терминами и понятиями, увидеть отличия и больше никогда их не путать.

Больше трёх лет я занимаюсь обеспечением качества продуктов. И всё это время наблюдаю за эволюцией процессов тестирования в компании.

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

До текущих процессов с ~~блэкджеком~~ Scrum-Less и автотестами на Selenium.

Накопленный опыт и черты характера типичные для моей профессии привели к размышлениям о том, кто такие тестировщики, QA и QC. Разные это суть сущности или пересекающиеся? В статьях и конференциях я часто сталкиваюсь с какой-то путаницей, мне это не нравится. Поэтому я решил поделиться своими мыслями на этот счёт. Осторожно, данная статья не является истиной в первой инстанции. Данная статья — мысли вслух и желание найти единомышленников.

QA, QC и тестировщики: три большие разницы?

Начнём наши поиски и копания с обращения к Международному стандарту системы менеджмента качества ISO 9000:2015. В каждой статье, в каждом видео на тему отличия этих понятий есть ссылка на этот документ, моя статья не исключение.

В пункте 3.2 стандарта раскрываются два определения:

Обеспечение качества (3.2.10) — часть управления качеством, направленная на обеспечение уверенности в том, что требования к качеству будут выполнены.
Оригинал
Quality assurance (3.2.10) — part of quality management focused on providing confidence that quality requirements will be fulfilled.

Контроль качества (3.2.11) — часть управления качеством, ориентированная на выполнение требований к качеству.
Оригинал
Quality control (3.2.11) — part of quality management focused on fulfilling quality requirements.

Из этих определений следует, что мы либо обеспечиваем качественный продукт, либо проверяем продукт на соответствие качеству.

Отмечу, что в стандарте ISO 9000:2015 вообще нет понятия tester как такового. Я искал.

Так каким же образом взаимосвязаны понятия Quality assurance, Quality control и Тестирование между собой?

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

Но лично мне кажется, что раз в стандарте нет понятия tester или testing, а QC — это и есть разного рода тестирование, то и иллюстрации должны быть такими:

Однако стандарт есть стандарт, а у нас тут реальная жизнь. И в реальной жизни IT-индустрии встречаются только два названия нашей профессии:

QA-инженер.

Тестировщик Программного обеспечения (ПО).

Причём очень часто эти понятия взаимозаменяются и путаются. Неразбериха начинается ещё на этапе описания вакансий.

Ищу Тестировщика ПО (QA-инженера)

Я бы не писал эту статью, если бы в индустрии не смешивали эти роли и не называли тестировщиков QA-инженерами и наоборот. По моим наблюдениям, в России не разделяют две профессии. Всех для простоты (а может по незнанию) называют тестировщиками. И ладно бы таким грешили только работодатели, но путаницу поддерживают и сами тестировщики. Например, на Хабре можно встретить статьи, где авторы на протяжении всего текста называют одних и тех же людей тестировщиками, QC-инженерами, QA-специалистами, инженерами по тестированию и тестерами.

Масла в огонь подливают HR-менеджеры: часто для увеличения охвата аудитории они пишут в названии вакансии «Тестировщик ПО (QA инженер)». Шапкой вакансии дело не заканчивается, винегрет продолжается и в самом описании.

Давайте обратимся к вакансиям QA-инженеров:

Все задачи связаны с тестированием и нацелены на поиск багов, хотя компания ищет «QA-инженера».

Или ещё один красочный пример:

И ещё:

И на сладкое:

По факту многие работодатели ищут тестировщика ПО (если ориентироваться по описанию обязанностей), но в названии обозначают, что находятся в поисках QA-инженера.

Если вы помните, в ISO 9000:2015 есть QA и QC. Что будет, если выполнить запрос на hh.ru по ключевому слову QC? А ничего не будет. Вы не увидите вакансий ни QA, ни тестировщика. По такому запросу появятся вакансии, связанные с производством и контролем качества выпускаемой продукции.

Получается, что в IT-индустрии нет профессий QC, их заменили на тестировщиков ПО, а в других сферах деятельности нет QA-специалистов, зато есть QC. В описании вакансий QA-инженеров не указывают обязанности по улучшению качества продуктов и недопущению багов, наверное, считают это само собой разумеющимся.

Что такое обеспечение качества

Прежде чем продолжить, давайте замутим небольшой интерактив. Перейдите по ссылке и посмотрите на сайт конференции QualityConf. Побродите пару минут по темам выступлений и ответьте для себя на несколько вопросов:
Для кого эта конференция?

С чем она у вас ассоциируется?

Конференция QualityConf целиком и полностью посвящена качеству, а не тестированию. Однако при подготовке очередной конференции организаторы провели исследование и задали вопрос своим посетителям: «С чем у вас ассоциируется конференция?».

Как вы все уже, наверное, догадались, главные ассоциации были исключительно с тестированием.

Получается, что сегодня, говоря слово «качество», многие слышат «тестирование», и очень часто это функциональное тестирование, хотя понятие качество гораздо шире.

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

Оригинал

Quality is a customer determination, not an engineer’s determination, not a marketing determination, nor a general management determination. It is based on the customer’s actual experience with the product or service, measured against his or her requirements — stated or unstated, conscious or merely sensed, technically operational or entirely subjective — and always representing a moving target in a competitive market (Armand Feigenbaum «Total quality control»).

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

QA ≠ QC: как их различить

QC: кто эти люди, какие у них задачи, какие у них ограничения

Кто эти люди? Люди, которых называют тестировщиками, тождественны контролю качества QC. По логике вещей они на последнем этапе разработки проверяют качество продукта (любым видом и типом тестирования — ручным, автоматизированным, нагрузочным, тестированием безопасности и т.д.).

Какая у них задача? Их задача — провести валидацию продукта и предоставить информацию бизнесу и разработчикам о соответствии продукта заявленным требованиям.

Какие у них ограничения? Какие могут быть недостатки, если у вас все сотрудники проверяют продукт на соответствие:

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

Зачастую такие сотрудники не могут давать рекомендации, как сделать продукт лучше. Потому что поезд ушёл и уже поздно. Им остаётся лишь сверять соответствие продукта требованиям. FYI: хотя на самом деле тестировщикам есть что сказать по поводу улучшений, которые необходимо сделать.

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

Они не могут взять на себя полную ответственность за качество продукта.

Очень часто между тестировщиками и разработчиками возникают конфликты. Так бывает, когда разработчики считают свой код самым лучшим и работающим, а в тестировщиках видят лишь попытки его сломать и показать, что код не работает. Такое положение дел порождает всем известные мемы «Это не баг, а фича».

QA: кто эти люди, какие у них задачи, какие у них ограничения

Кто эти люди? Инженеры по обеспечению качества (QA) — это люди, которые помогают командам разработки выпускать качественный продукт, как можно быстрее за как можно меньшие деньги. Ведь все мы знаем, что чем раньше найден баг, тем дешевле его пофиксить. Лучше всего фиксить баги ещё на уровне идеи.

QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это.

Какая у них задача? Задача QA-инженера — не допустить несоответствия продукта предъявляемым требованиям. QA-инженер замеряет качество продукта, знает его актуальное состояние и что нужно сделать, чтобы его поднять не только на этапе тестирования, но и на этапе разработки, дизайна или составления требований.

Какие у них ограничения? Сложно оценить качество работы QA-инженера, потому что если он хорошо выполняет свою работу, то до этапа тестирования будет доходить минимальное количество багов не влияющих на функциональность и запуск продукта в прод.

В отличие от QA, работу QC оценить можно, особенно если отталкиваться от самого простого и оценивать эффективность по количеству багов — сколько багов нашёл и сколько багов пропустил на прод.

Как дальше жить?

Большой штат тестировщиков не сможет существенно улучшить качество продукта. Но сможет улучшить саму проверку качества. Если же вы, коллеги-тестировщики, хотите поднимать именно качество на новый уровень, задумайтесь о переходе в QA-инженеры.

Только не ждите, когда вас позовут на встречу, где обсуждают фичи с разработчиками или дизайнерами, придите на неё сами. Высказывайте своё мнение касательно любого аспекта качества продукта. Не позволяйте сложившимся правилам, должностным инструкциям и прочей фигне мешать вам делать продукт ещё более качественным, чем сейчас.

Я знаю, что большинству из вас не всё равно на то, что вы тестируете. И вы искренне хотите поставлять хороший продукт, которым приятно будет пользоваться.

Обсудить в форуме

«Подготовка к собеседованию QA» starter pack или самая большая шпаргалка вопросов-ответов по тестированию / Хабр

Библия QA это 200++ страниц обновляемой смеси ответов на вопросы с реальных собеседований на QA, перевода интересного контента с зарубежных ресурсов и агрегации материала с отечественных. Уже на начальной стадии имеет несколько тысяч уникальных просмотров репозитория и огромный положительный фидбэк от коммьюнити, что даёт некоторые гарантии для сомневающихся, доверять ли этому материалу или контрибьютить ли сюда.

ВНИМАНИЕ! Для того, чтобы увидеть материал целиком, нужно открыть первую или вторую часть в файлах на гитхабе (Manual part 1 или Manual part 2).

Оказалось, что такой объем практически нереально предоставить общественности. К сожалению, Хабр пока не умеет парсить исходники больше 150кб, а это означало бы разбиение материала на 8 статей (разработчики пообещали исправить, задача уже в активных).
В первую очередь хочу подчеркнуть, что в данный момент этот материал от джуна – джунам, от intermediate – таким же, но будет полезен всем грейдам, тем более что часть материала далеко не начального уровня. Качество материала (особенно перевода) будет улучшаться по мере вычитки и вклада сообщества.
Что касается источников и ресурсов, то список не полный. В первоначальном конспекте для себя я не сохранял ссылки, так что, если увидели авторский контент, прошу не ругаться, напишите — добавлю в источники. Список полезных ресурсов я не пытался сделать всеобъемлющим, а лишь указал те, что пригодились лично мне, на самом деле их в разы больше.
Также отмечу, что и сам материал пока что далеко не всеобъемлющий. Предполагается, что это некий гибрид ответов на вопросы и базовой теории и здесь темы раскрыты в той мере, что требуется на собеседовании. То есть ориентир и какая-то база есть, но при необходимости копаете дальше уже сами. Каждый термин, каждая тема представляется мне как трехмерный объект и не всегда можно достичь понимания, глядя в лоб (один источник). Порой требуется посмотреть под разными углами (в разных источниках).
Если есть что исправить или дополнить – пишите в tg @VA610/создавайте issue/форкайте и коммитьте! Любые замечания, любые запросы на недостающие темы постараюсь обработать как можно скорее!

Manual part 1

HR-часть

Вопросы с реальных собеседований с этапа HR

Общее о тестировании

Что означает тестирование ПО?

Почему требуется тестирование ПО?

Что означает обеспечение качества (Quality Assurance — QA) при тестировании ПО?

Что означает контроль качества (Quality Control — QC) при тестировании ПО?

Что означает качество ПО? (Software Quality)

Объясните отличия в QA, QC и тестировании

Что означает Verification при тестировании ПО?

Что означает Validation в тестировании ПО?

Разница между Design Verification и Design Validation?

Принципы тестирования?

Критерии выбора тестов?

Что подразумевается под тестовым покрытием? (Test Coverage)

Что такое модель зрелости тестирования (TMM — Test Maturity Model)?

Что такое тестирование со сдвигом влево? (Shift left testing)

Что такое независимое тестирование? (Independent testing)

В чем разница между превентивным и реактивным подходами в тестировании? (Preventative and Reactive approaches)

Перечислите типичные возможные обязанности инженера по обеспечению качества?

Что такое аудит качества?

Почему тестирование делится на отдельные этапы?

Почему невозможно полностью протестировать ПО?

Как вы тестируете продукт, если требования еще не зафиксированы?

Как вы узнаете, было ли создано достаточно тестов для тестирования продукта?

Как вы понимаете инспекцию?

Какие есть роли/должности в команде?

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

Кто такой SDET?

Что такое тестирование как сервис? (TaaS – testing as a Service)

Что подразумевается под тестовой средой? (Test Environment/Test Bed)

Что подразумевается под тестовыми данными?

Основные фазы тестирования?

Подробнее про бета-тестирование?

Что означает пилотное тестирование? (Pilot)

В чем отличие build от release?

Что такое бизнес – логика (domain)?

Ты – единственный тестировщик на проекте. Что делать?

Основные инструменты тестировщика?

Виды тестирования

Какие существуют основные виды тестирования ПО?

Типы тестирования? (White/Black/Grey Box)

Что означает тестирование черного ящика?

Что означает тестирование белого ящика?

Что означает тестирование серого ящика? (Grey box)

Основные отличия White/grey/black box?

Что такое деструктивное/разрушающее/негативное тестирование? (DT — Destructive testing)

Что такое недеструктивное/неразрушающее/позитивное тестирование? (NDT – Non Destructive testing)

Что такое пирамида/уровни тестирования? (Testing Levels)

Что подразумевается под компонентным/модульным/юнит тестированием? (Component/Module/Unit testing)

Что подразумевается под интеграционным тестированием? (Integration testing)

Разница между Unit testing и Integration testing?

Что такое системное интеграционное тестирование? (SIT — System Integration testing)

Что подразумевается под инкрементальным подходом? (Incremental Approach)

Что подразумевается под подходом снизу-вверх? (Bottom-Up Approach)

Что подразумевается под подходом сверху-вниз? (Top-Down Approach)

Что подразумевается под гибридным/сэндвич-подходом? (Sandwich Approach)

Что подразумевается под подходом Большого взрыва? (Big Bang Approach)

В чем разница между тест-драйвером и тест-заглушкой? (Test Driver and Test Stub)

Что подразумевается под системным тестированием?

Можем ли мы провести системное тестирование на любом этапе?

Что такое функциональное тестирование?

Что такое тестирование совместимости/взаимодействия? (Compatibility/Interoperability testing)

Что такое тестирование на соответствие? (Conformance/Compilance testing)

Что такое нефункциональное тестирование?

Основные понятия в тестировании производительности?

Тестирование производительности клиентской части и серверной, в чем разница?

В общем виде что такое тестирование производительности?

Что такое тестирование емкости/способностей? (Capacity)

Что означает тестирование масштабируемости? (Scalability)

Разница между тестированием ёмкости/способностей и тестированием масштабируемости? (Capacity vs Scalability)

Расскажите о стрессовом тестировании? (Stress testing)

Расскажите о нагрузочном тестировании? (Load)

Что такое объемное тестирование? (Volume testing)

Тестирование выносливости/стабильности/надежности (Soak/Endurance/Stability/Reliability testing)

Что такое спайк/шиповое тестирование? (Spike)

Что такое тестирование устойчивости? (Resilence)

Что такое тестирование времени отклика? (Response time testing)

Что такое Ramp тестирование?

Что такое тестирование хранилища? (Storage testing)

Что такое тестирование на отказ и восстановление? (Failover and Recovery testing)

Что вы знаете о Тестировании удобства пользования? (Usability testing)

Отличия тестирование на удобство пользования и тестирования доступности? (Usability Vs. Accessibility testing)

Что такое тестирование интерфейса? (UI testing)

Что такое тестирование рабочего процесса/воркфлоу? (Workflow testing)

Что вы знаете о пользовательском приемочном тестировании? (UAT – User Acceptance testing)

Что такое эксплуатационное приемочное тестирование? (OAT — Operational Acceptance testing)

Расскажите об инсталляционном тестировании?

Что вы знаете о тестировании безопасности? (Security and Access Control testing)

Что означает оценка уязвимости/защищенности? (Vulnerability Assessment)

Расскажите подробнее о тестировании на проникновение? (Penetration testing)

Отличия Vulnerability Assessment от Penetration testing?

Что такое Fuzz тестирование?

Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тестирования?

Что вы знаете о конфигурационном тестировании? (Configuration testing)

Что вы знаете про регрессионное тестирование? (Regression testing)

Типы регрессии по Канеру?

Что подразумевается под проверкой дыма/дымовым тестированием? (Smoke testing)

Что такое тестирование встряхиванием? (Shake out testing)

Что подразумевается под санитарным тестированием/согласованности/исправности? (Sanity testing)

Отличие санитарного тестирования от дымового? (Sanity vs Smoke testing)

В чем разница между повторным и регрессионным тестированием?

Объясните, что такое тестирование N+1?

Что означает подтверждающее тестирование? (confirmation/re-testing)

Что вы знаете о тестировании сборки? (Build Verification Test)

Что такое тестирование файлов cookie?

Что такое тестирование потоков? (Thread testing)

Что такое тестирование документации? (Documentation testing)

Какие вы знаете уровни тестирования данных?

Что такое подкожный тест? (Subcutaneous test)

Расскажите о локализации, глобализации и интернационализации? (Localization/ globalization/internationalization testing)

Что такое исследовательское тестирование? (Exploratory testing)

Что вы знаете о турах Виттакера в исследовательском тестировании?

Что такое Свободное или Интуитивное тестирование? (Adhoc)

Что вы знаете о мутационном тестировании? (Mutation testing)

Что означает механизм тестирования по ключевым словам? (Keyword Driven testing Framework)

Что вы знаете о тестировании интерфейса прикладного программирования (API — Application Programming Interface)?

Как протестировать API без документации/черным ящиком?

А что такое endpoint?

Frontend testing Vs. Backend testing?

Что подразумевают под эталонным тестированием? (Baseline testing)

В чем разница между Baseline и Benchmark testing?

Что такое параллельное/многопользовательское тестирование? (Concurrency/Multi-user testing)

Как вы думаете, что такое тестирование на переносимость?

Что такое тестирование графического интерфейса/визуальное тестирование? (GUI — Graphical User Interface)

Что такое A/B тестирование?

Что означает сквозное тестирование? (E2E — End–to–End)

В чем разница между E2E и системным тестированием?

Что такое параллельное тестирование? (Parallel testing)

Тест дизайн

Тест дизайн? (Test Design)

Перечислите известные техники тест-дизайна?

Что такое статическое тестирование, когда оно начинается и что оно охватывает?

Что такое динамическое тестирование, когда оно начинается и что оно охватывает?

Какие виды Review вы знаете?

Что вы знаете о Data Flow testing?

Что вы знаете о Control Flow testing?

Что такое Loop coverage?

Что такое Race coverage?

Тестирование пути и тестирование базового пути? (Path testing & Basis Path testing)

Что вы знаете о Statement coverage?

Что вы знаете о Decision coverage?

Что вы знаете о Branch coverage?

Что вы знаете о Condition coverage?

Что вы знаете о FSM coverage?

Что такое Function coverage?

Что такое Call coverage?

Что означает LCSAJ coverage?

Сравнение некоторых метрик

Что такое Equivalence Partitioning?

Что такое Boundary Value Analysis?

Что такое Error Guessing?

Что такое Cause/Effect?

Что такое Exhaustive testing?

Какие вы знаете комбинаторные техники тест-дизайна?

Что такое тестирование ортогональных массивов? (OAT — Orthogonal Array testing)

Что такое Domain analysis/testing?

Что такое Cyclomatic Complexity в тестировании ПО?

Что такое State Transition testing?

Что такое Scenario (use case) testing?

Что такое Decision Table testing?

Что такое Random testing?

Что такое Syntax testing?

Что вы знаете о Classification tree method?

Как мы узнаем, что код соответствует спецификациям?

Что включает в себя матрица отслеживания требований? (RTM — Requirement Traceability Matrix)

В чем разница между Test matrix и Traceability matrix?

Что такое анализ GAP?

Что такое граф причинно-следственных связей? (Cause Effect Graph)

В чем разница между предугадыванием ошибок и посевом? (Error guessing and error seeding)

Стили тестов?

Техники тестирования требований?

Что такое эвристики?

Manual part 2

Тестовые артефакты и документация (Test Deliverables/TestWare/test artifacts)

Виды тестовой документации?

Какие отличия у тест-кейса высокого и низкого уровня?

Отличия Test Suite от Test Scenario?

Какие отличия у плана тестирования и стратегии тестирования?

Виды тест планов?

Что является основой для подготовки плана приемки? (PAP — Product Acceptance Plan)

В чем разница между тест-кейсом и чек-листом?

В чем разница между тест-кейсами высокого уровня и низкого уровня?

Чем Test case отличается от сценария тестирования?

Что такое тест-анализ/основа теста? (Test Analysis/Test Basis)

Что такое документ бизнес-требований (BRD)?

Что вы знаете о требованиях (уровни/виды и т. д.)?

Рассажите, какие есть требования к самим требованиям?

Дефекты и ошибки

Что такое дефект?

Классы дефектов?

Какие есть категории дефектов?

Error/Mistake/Defect/Bug/Failure/Fault?

Каково содержание эффективного сообщения об ошибке?

Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке?

Серьезность и Приоритет Дефекта (Severity & Priority)

Может ли быть высокий severity и низкий priority? А наоборот?

Жизненный цикл дефекта?

Пришёл баг из продакшена, что делаем?

Что такое утечка дефектов и релиз бага? (Bug Leackage & Bug Release)

Что означает плотность дефектов при тестировании ПО?

Что означает процент обнаружения дефектов при тестировании ПО?

Что означает эффективность устранения дефектов при тестировании ПО? (DRP)

Что означает эффективность Test case в тестировании ПО? (TCE)

Возраст дефекта в тестировании ПО?

Что такое принцип Парето в тестировании ПО?

Каковы различные способы применения принципа Парето в тестировании ПО?

В чем основное отличие отладки от тестирования? (Debugging Vs. Testing)

Почему в программном обеспечении есть ошибки?

Что вы будете делать, если во время тестирования появится ошибка?

Как вы справляетесь с невоспроизводимой ошибкой?

Если продукт находится в производстве и один из его модулей обновляется, то необходимо ли провести повторную проверку?

Что такое анализ рисков?

В чем разница между coupling и cohesion?

Что такое скрытый дефект? (Latent defect)

Что такое маскировка ошибок, объясните примером?

Категории отладки? (Debugging)

Что такое Эффективность удаления дефектов? (DRE — Defect Removal Efficiency)

Что такое сортировка дефектов? (Bug triage)

SDLC и STLC

Что вы знаете о жизненном цикле разработки ПО? (SDLC — Software Development Lifecycle)

Что такое цикл/колесо Деминга? (Deming circle/cycle/wheel)

Модели разработки ПО?

Что такое Agile?

Что такое Scrum?

Какие вообще особенности у тестирования в Scrum?

В чем отличие Canban от scrum?

Что знаете о User stories в гибких подходах к разработке?

Что значит жизненный цикл тестирования ПО? (STLC – Software Testing Lifecycle)

Что вы знаете о техниках оценки теста? (Test Estimation)

В чем разница между SDLC и STLC?

Что такое быстрая разработка приложений? (RAD — Rapid Application Development)

Что такое разработка через тестирование (TDD — Test Driven Development)?

TDD в Agile Model Driven Development (AMDD)

Тестирование на основе моделей (MDD — Model-driven Development)

Тестирование на основе данных (DDT — Data Driven testing)

Тестирование на основе риска (RBT — Risk Based Testing)

Что вы знаете о потоковом тестировании? (BFT — BusinessFlowTesting)

Тестирование в разных сферах/областях (testing different domains)

Что такое веб-тестирование и как его производить?

Тестирование банковского ПО

Тестирование электронной коммерции (eCommerce)

Тестирование платежного шлюза (Payment Gateway)

Тестирование систем розничной торговли (POS — Point Of Sale)

Тестирование в сфере страхования (Insurance)

Тестирование в сфере телекоммуникаций (Telecom)

Тестирование протокола: L2 и L3 OSI

Тестирование интернета вещей (IoT — Internet of Things)

Что такое облачное тестирование? (Cloud testing)

Что такое тестирование сервис-ориентированной архитектуры? (SOA — Service Oriented Architecture)

Что такое тестирование планирования ресурсов предприятия? (ERP — Enterprise Resource Planning)

Тестирование качества видеосвязи WebRTC-based сервиса видеоконференций

Что такое тестирование ETL?

Мобильное тестирование

Каковы особенности в тестировании мобильных приложений?

В чем отличия тестирования мобильного приложения от десктопного?

В чем отличия тестирования мобильного приложения от web?

Почему так много внимания уделяется прерываниям? Что такое Activity Lifecycle?

Что вы знаете о симуляторах и эмуляторах?

Типы мобильных приложений?

Что основное проверить при тестировании мобильного приложения?

Как быть с покрытием девайсов?

Последнее обновление Android/iOS, что нового?

Основные различия iOS и Android?

Виды жестов и т.п.?

Как проверить использование процессора на мобильных устройствах?

Объясните критические ошибки, с которыми вы сталкиваетесь при тестировании на мобильных устройствах или в приложениях?

Что вы знаете о PWA?

Сети и около них

Что такое http?

Компоненты HTTP?

Методы HTTP-запроса?

Что такое ресурс?

Что такое веб-сервис? (WS — Web service)

Отличие сервиса от сервера?

Отличие сервиса от веб-сайта?

Что такое REST, SOAP? В чем отличия?

Что такое JSON, XML?

Коды ответов/состояния сервера с примерами? (HTTP status code)

Почему ошибка 404 относится к 4** — клиентской, если по идее должна быть 5**?

Какие еще бывают протоколы?

TCP/IP это?

Что такое куки (cookies)?

Разница между cookie и сессией/сеансом?

Отличие stateless и stateful?

Различия методов GET и POST?

Клиент — серверная архитектура?

Уровни OSI?

Что вы подразумеваете под потоковыми медиа? (Streaming media)

Основные команды Linux?

Почему важно тестировать в разных браузерах?

Адаптивный веб-дизайн vs. Отзывчивый веб-дизайн, в чем разница? (Adaptive Vs. Responsive)

Как сервер узнаёт, с какого типа устройства/браузера/ОС/языка вы открываете веб-сайт? (Например, для Adaptive design)

Чем отличается авторизация от аутентификации?

Как работает авторизация/аутентификация? Как сайт понимает, что ты залогинен?

Почему важно делать подтверждение e-mail при регистрации?

Что такое кэш и зачем его очищать при тестировании?

Что такое AJAX в вебе?

Как работает браузер (коротко)?

Как работает сотовая связь?

Как работает подключение к Wi-Fi?

Базы данных

Может ли у ПО быть сразу несколько баз данных?

Что такое SQL?

Что вы знаете о NoSQL?

Что такое нормальные формы?

Понятие хранимой процедуры?

Понятие триггера?

Что такое индексы? (Indexes)

Какие шаги выполняет тестер при тестировании хранимых процедур?

Как бы вы узнали для тестирования базы данных, сработал триггер или нет?

Как тестировать загрузку данных при тестировании базы данных?

Основные команды SQL?

Подробнее о джойнах? (Join)

Типы данных в SQL?

ПРАКТИКА

Дана форма для регистрации. Протестируйте.

Определение серьезности и приоритета

Определение граничных значений и классов эквивалентности

Логические задачи

Еще примеры

Набор небольших задач по SQL

Тестирование чашки для кофе

HR: Как вы будете решать конфликты между членами вашей команды?

HR: Что делать, если разработчик утверждает, что найденный дефект таковым не является?

Вот тебе комп и работающий сайт. Сделай мне 401-ю ошибку.

С чего начать абсолютному новичку?

Путь

Собеседование

Ошибки в работе у начинающих тестировщиков

Полезное

Youtube-каналы

Книги

Курсы

Источники

Специальность QA Software Tester или кто такой Quality Assurance Engineer

QA (Software Testing and Quality Assurance) или тестировщик – это специалист по обеспечению качества программного обеспечения. Тестировщик во многом похож на следователя или детектива. Он идёт по горячим следам программиста и выискивает баги, использует различные дедуктивные методы и скрытые приёмы. Без тщательного тестирования невозможно добиться высокого качества программного продукта – вот почему QA-специалисты очень востребованы в IT-компаниях, занятых разработкой.

Всех тестировщиков можно разделить на 2 большие группы по уровню подготовки — Manual QA Engineer и Automation QA Engineer.

Manual QA Engineer или мануальный тестировщик – это инженер, который фокусирует внимание на процессах разработки ПО, улучшает их, предотвращает появление дефектов и проблем. Все рабочие процессы проходят «вручную»: он планирует процесс тестирования, пишет тест-кейсы, выявляет проблемные места, заносит полученные данные в базу, проводит ре-тесты ошибок после доработки программистами. QA-мануальщик анализирует процесс тестирования для его оптимизации в дальнейшем.

Automation QA Engineer – это специалист, который использует программные средства для создания тестов и проверки результатов выполнения. Основная задача QA-автоматизатора — создавать автоматические скрипты, которые будут проверять работу программы на основании тест-кейсов, написанных QA-мануальщиками. Это помогает сократить время тестирования рутинных задач и упростить весь процесс в целом. QA Automation Engineer обладает навыками программиста и логикой тестировщика одновременно: автоматизатор проверяет качество продукта на различных этапах его разработки, тестирования и эксплуатации, а также он занимается разработкой продукта, который проверит написанное программистами.

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

Программа QA курса на ресурсе ITVDN разработана таким образом, что студент получает все необходимые знания и практические навыки для начала своей карьеры тестировщика. Курс позволит изучить основы, которые являются «must have» для всех тестировщиков, независимо от сферы тестирования и продукта, который предстоит тестировать. Закончив его, вы уже сможете начать карьеру и получать реальный опыт на фрилансе или позиции Trainee/Junior QA.

Требования к QA-специалисту:

Знание этапов жизненного цикла ПО

Отличное знание теории (основы, методы, виды и типы тестирования) и умение применять эти знания на практике

Знание баг-трекинговых систем (Jira/YouTrack), опыт работы с ними

Уверенные знания web-технологий (HTTP, DOM, HTML, JSON, Server response codes, cookie & session)

Базовые знания SQL, ООП

Опыт ведения тестовой документации

Базовые знания языка программирования, который используется в проекте

Понимание Agile/SCRUM методологии, умение и желание работать в команде

Тестировщик может занимать такие должности:

QA Engineer

QA Manual

Automation QA Engineer

Junior/Middle Test Engineer

Mobile QA Engineer

QA Functional Manager

Junior/Middle QA Game Tester

QA Lead

Лучшие системы управления тестированием 2019 / Хабр

Каждый проект уникален и у каждой команды свои запросы. Но всех нас объединяет желание работать с качественными инструментами, которые экономят время.

Мы проанализировали проверенные временем и новые системы управления тестированием, которые сейчас популярны на рынке. Выбрали функции, которые должны быть в идеальной Test Management System, сравнили возможности продуктов и изучили отзывы пользователей.

Как итог, перед вами список инструментов, один из которых точно подойдёт вашей команде.

Здесь нет рейтинга, у каждого инструмента есть свои преимущества и недостатки. В основном, инструменты тест-менеджмента на платной основе, но почти у всех из них есть бесплатная пробная версия.

Что мы хотим от системы управления тестированием?

Пользователь системы управления тестированием ожидает увидеть следующее:

Удобная установка и поддержка.

Создание и управление проектами.

Создание пользователей и ролей пользователей.

Удобная интеграция с автоматическими тестами.

Создание тест-плана.

Создание тест-кейса.

Прогон тест-кейса.

Понятная система отчётности.

Встроенная система баг-трекинга.

Возможность интеграции с другими инструментами.

Зачем она нужна?
Решить задачу создания единой системы для работы со всей документацией проекта можно несколькими способами:

Самый дешёвый способ — не заморачиваться и выбрать Google Docs для матрицы трассируемости, а дефекты вести в open-source баг-трекере.

Другой способ — использовать одну из популярных TMS’ок, интегрированную с баг-трекером компании.

Next-level способ — выбрать Test Management System, исходя из специфики проектов, объемов задач, типов документации и используемых видов тестирования.

Очень важно подойти к вопросу выбора TMS ответственно, ведь для компании, цена ошибки может оказаться высокой.

Популярные системы управления тестированием

Test Link

Test IT

Zephyr

qTest

PractiTest

TestLodge

TestRail

Qase

Tematoo

Test Collab

HP ALM

Testuff

XQual

Давайте рассмотрим выбранные инструменты более пристально.

1. TestLink

Один из немногих open-source инструментов управления тестированием, который доступен на рынке. Это веб-инструмент с типичными функциями, такими как управление требованиями, создание и сопровождение тест сьютов, прогон тестов, отслеживание ошибок, интеграция с известными баг-трекинговыми системами.

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

Код проекта часто обновляется и дополняется.

Возможности:

Управление требованиями

Спецификация — определение тест кейсов путём группировки в разные наборы тестов

Назначение выполнения тест сьютов на уровне сборки

Централизованное управление пользователями и ролями

Кастомизация настраиваемых пользователем полей

Ссылка на код (GitHub)
Ссылка на скачивание

2. Test IT

Test IT — TMS, которую создают тестировщики для тестировщиков. Этот инструмент отличает продуманный и понятный интерфейс. Внутри системы можно создавать проекты и вести для каждого структурированную библиотеку тестовых случаев и чек-листов, часто повторяющиеся операции выделяются в общие шаги. Инструмент гибкий — в каждом проекте создаются дополнительные пользовательские атрибуты, распределяются роли и права, что упрощает настройку TMS под процессы вашей компании. Test IT помогает руководителям групп тестирования равномерно распределять нагрузку между тестировщиками и контролировать исполнение работ с помощью пользовательских запросов и отчётов.

Разработчики приложения уделяют большое внимание автоматизированному тестированию, каждый тестовый случай в библиотеке тестов можно интегрировать с автотестами по API. Правильно настроенная интеграция с автотестами позволяет следить за прогонами и их результатами прямо из TMS в режиме реального времени. Вы сможете видеть какие автоматические тесты в процессе выполнения, анализировать их результаты и просматривать исходный код прямо из Test IT.

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

Возможности:

Управление тест-планами, тест-кейсами и чек-листами

Общие шаги для повторяющихся действий

Автоматическое распределение тестов на QA инженеров

Интеграция автоматических тестов с помощью API

Аналитика как по автоматическим, так и по ручным тестам

Ролевая модель и персонализация

Геймификация

Двусторонняя интеграция с JIRA

Импорт из других систем управления тестированием

Бесплатная пробная версия: Открытая демо-версия на сайте
Ссылка на скачивание

3. Zephyr

Zephyr — это плагин для всем известной JIRA, который интегрирует тестирование в проектный цикл, позволяя вам отслеживать качество программного обеспечения и принимать решения в стиле go / no-go. Тест кейсы могут создаваться, выполняться и трекаться так же, как и любые другие задачи в JIRA. Для более оптимальной фиксации процесса тестирования есть интеграция с инструментами управления качеством, автоматизации, непрерывной интеграции и аналитики.

Кроме того, у продукта быстро отвечающая тех поддержка.

Возможности:

Ссылка на user stories, задачи, требования, дефекты

Конфигурации деплоя: в облаке, на сервере, в дата-центре

Расширенная информация на дашбордах аналитики и DevOps

Интеграция с JIRA, Confluence, Selenium, Jenkins и Bamboo

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

4. qTest

Инструмент полезный не только тестировщикам, но и всей команде. Интерфейс qTest нативно понятен, мануалы просты в освоении. Это позволяет быстро и эффективно создавать, организовывать и управлять тест кейсами.

Разработчики нескромно заявляют, что их инструмент управления тестами №1

Согласно анализу рынка, qTest является одним из самых быстрорастущих решений для управления тестированием среди команд Agile Development.

Возможности:

Планирование тестов

Создание и управление требованиями

Интуитивный drag-n-drop интерфейс

Комплексная матрица трассируемости

Наглядные отчёты с подробными графиками

Интеграция со сторонними инструментами баг-трекинга

Детальный контроль доступа пользователей

Облачный инструмент интеграции с JIRA

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

5. PractiTest

PractiTest — это комплексное средство управления тестами. Оно обеспечивает полную наглядность процесса тестирования и более глубокое понимание результатов тестирования. Этот инструмент поможет организовать тест сьюты в соответствии с вашими циклами и спринтами. Тестовые наборы можно формировать по различным критериям, таким как компоненты, версии или типы. Тул заточен на Agile тестирование, регрессионное тестирование, тестирование микросервисов и DevOps.

А в тех поддержке работают обученные QA сотрудники, которые могут быстро понять вашу проблему.

Возможности:

Лёгкое добавление тестов новых фич в регрессионное тестирование

Группировка тестов на основе микросервисов, которые они охватывают, даже кросс-сервисные

Различное отображение информации для разных групп пользователей

Дашборды в реальном времени показывают состояние тестов, прогонов на этапах разработки и при деплое на продакшн

Интеграция с JIRA, Redmine, Jenkins, GitLab и Slack

Бесплатная пробная версия: 14 дней
Ссылка на скачивание

6. TestLodge

В нём есть самый необходимый минимум, который требуется для управления тестированием: тест планы, требования, тест кейсы и сьюты, и тестовые прогоны. Тул можно интегрировать с существующими баг-трекерами, что позволяет автоматически создавать отчёты о дефектах и заводить задачи.

Возможности:

Базовый набор создания, редактирования тест плана и тест сьютов

Нативный интерфейс

Интеграция с JIRA, Redmine, Trello, Asana, GitHub и YouTrack

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

7. TestRail

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

Возможности:

Отслеживание состояния и результатов отдельного теста

Сравнение результатов нескольких тестов, конфигураций и этапов

Отслеживание рабочей нагрузки команды для корректировки задач и ресурсов

Развёрнутые отчёты и метрики

Широкие возможности настройки, облачные или локальные варианты установки

Интеграция с JIRA, Redmine, YouTrack, GitHub, Jenkins, Selenium и Visual Studio

Удобный REST API

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

8. Qase

Qase это недавно появившийся продукт, который можно нормально использовать в работе. Облачная TMS, которая поможет вашей команде повысить производительность и организовать удобный флоу тестирования программного обеспечения.

Возможности:

Тестовый репозиторий: выстраивание тестов в логические группы

Составление шагов для кейсов, установка приоритета и серьёзности

Запуск тестовых прогоны с трекингом времени по каждому тест кейсу

Хранение документации по проекту

Автоматическое заведение дефектов в интегрированные трекеры

Интеграция с JIRA, Redmine, YouTrack и Slack

Объединение результатов автотестов с REST API

Бесплатно для небольших компаний
Ссылка на скачивание

9. Tematoo

Эта облачная TMS от TestLink не так разрекламирована, но не уступает по своей функциональности более дорогим аналогам. Инструмент предоставляет лаконичную инфраструктуру, позволяя быстро приступить к тестированию продукта. А бесплатный план поддержки небольших команд позволяет проводить пилотные реализации проекта бесплатно. Tematoo может быть интегрирован со многими баг-трекерами, даже облачными.

Возможности:

Формирование тест сьютов по билдам и типам

Описание тест кейса по шагам, с возможностью прикрепить скриншот

Статус отдельных тестов, наборов и общий статус сборки

Аналитические отчёты и общий метрики по тест плану

Для платного плана: свой баг-трекер

Бесплатно: для команды из 1-5 человек
Ссылка на скачивание

10. Test Collab

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

Test Collab можно настроить в облаке или в вашей инфраструктуре, тут всё достаточно гибко.

Возможности:

Группировка тест кейсов по этапам или билдам

Управление требованиями

Переиспользование тестов

Настройка спринтов

Отчёты по результатам тестов

Комментирование тест кейсов

Интеграция с JIRA, Redmine, Bugzilla, Asana, Trello, YouTrack, GitHub

Бесплатно: 200 тест кейсов, 400 выполненных прогонов
Бесплатная пробная версия: 14 дней
Ссылка на скачивание

11. HP ALM

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

Именно потому что продукт уже обкатан, в интернете есть большое множество мануалов и видеогайдов по настройке и использованию.

Возможности:

Общий доступ к библиотекам требований и ресурсов

Подробные сведения о коде, тестировании, управлении рисками и их оценке, а также о соответствии требованиям

Быстрый доступ к показателям, например к данным о неустранённых дефектах

Быстрая настройка лабораторной среды для устранения ошибок конфигурации в средах Agile

Создание требований и отслеживание их выполнения на всех этапах жизненного цикла приложения

Аналитика на любой вкус и цвет: гибко настраиваемые отчёты

Интеграция с 50+ инструментами

Бесплатная пробная версия: 60 дней
Ссылка на скачивание

12. Testuff

Testuff — это мощная веб-платформа управления тестированием, которая позволяет легко проектировать, выполнять и управлять неограниченным количеством тестов. Тул можно настроить под любой формат тестирования: от популярной гибкой методологии и TDD, до White-Box или Black-Box; Top-Down или Bottom-Up.

Здесь есть и оптимизированная очередь управления задачами для каждого тестировщика с применением тайм-менеджмента. И организация тестов по проектам, веткам кода и типичным тестовым наборам. Помимо бонуса экспорта в HTML/Excel, есть маленькие плюшки в виде встроенного тула создания скриншотов и видео с отображением указателя и нажимаемых клавиш.

Возможности:

Два доступных клиента — Web и Desktop

Планирование цикла тестирования с использованием нескольких тестовых окружений

Разграничение по ролям пользователей

Встроенный захват экрана в виде скриншота или видео

Подключение результатов автоматизированных тестов по API

Интеграция с JIRA, Trello, Redmine, Bugzilla, YouTrack, Selenium, GitHub, Visual Studio

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

13. XQual

XStudio от XQual осчастливит продвинутого тестировщика, который хочет подвергнуть свой продукт максимальному количеству испытаний. С помощью этого инструмента можно управлять не только своими релизами, требованиями, рисками, спецификациями, тестами, кампаниями и багами. Он может быть интегрирован со всеми платформами непрерывной интеграции и может выполнять любой вид тестирования.

Возможности:

Расширенная настройка шагов тест кейса

Переиспользование тестов

Матрица трассируемости

Настройка тестовой лаборатории: hardware, software, тестовое окружение

Продвинутое логирование действий (даже удалённых тестов)

Настраиваемая аналитика

Встроенный захват экрана

Интеграция с JIRA, Redmine, MySQL, Oracle, Apache, Skype

Интеграция с 5 различными интерфейсами для ручного тестирования

Интеграция с почти 70 тулами автоматизации: Selenium, QTP / UFT, JMeter, Ranorex, TestComplete, JUnit, NUnit, TestPartner, Sahi, NeoLoad, QF-Test, RobotFramework, Sikuli, SoapUi, Squish, TestNg, TestOptimal и многие другие

Бесплатно: для команды из 4-10 человек, 200 тестов
Ссылка на скачивание

Понравился пост? Не забудьте поделиться им!

И помните, мы стоим между багами и клиентом! 🙂

10 лучших инструментов для автоматизации тестирования ПО / Хабр

Привет, Хабр! Представляю вашему вниманию перевод статьи «Top 10 Automated Software Testing Tools» автора Pratik Satasiya.

Боб Иган, директор по исследованиям Sepharim Research, говорил о мобильной безопасности. Он выступил с заявлением на Enterprise Mobility Trends 2016:

«Современный десктоп на самом деле не десктоп, а опыт, который нужен в данный момент».

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

Внедрение приложений, уменьшающих усилия, быстро охватывает следующие отрасли:

Разработка приложения

Тестирование программного обеспечения

VOIPs (устройство, предназначенное для подключения телефонных аппаратов или офисных АТС к IP-сети для передачи через неё голосового трафика.)

Автоматизация управления персоналом

Железнодорожные пути

Повышенный спрос на автоматизацию также актуален в нашей индустрии тестирования программного обеспечения. Если вы следите за какими-либо сообществами по тестированию программного обеспечения или приложений (например, uTest, Quora и т. д.), Вы обнаружите, что тестировщики призывают к различным инструментам, которые могут быть полезны в их повседневной деятельности по тестированию, будь то ручное тестирование, веб-тестирование, браузерное тестирование, регрессионное тестирование, веб-сервисы и тестирование API и многое другое.

Вот обзор самых популярных инструментов автоматизации тестирования программного обеспечения, которые помогут тем, кто занимается тестированием программного обеспечения.

10 лучших инструментов для автоматического тестирования программного обеспечения

1. Selenium

Selenium — это среда тестирования для тестирования веб-приложений в различных браузерах и платформах, таких как Windows, Mac и Linux. Selenium помогает тестировщикам писать тесты на разных языках программирования, таких как Java, PHP, C #, Python, Groovy, Ruby и Perl. Selenium предлагает функции записи и воспроизведения для написания тестов без изучения Selenium IDE.

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

Узнайте больше о Selenium

2. TestingWhiz

TestingWhiz — это инструмент автоматизации тестирования со сценариями без кода от Cygnet Infotech, поставщика ИТ решений 3-го уровня CMMi. Редакция Enterprise инструмента TestingWhiz предлагает полный пакет различных решений для автоматизированного тестирования, таких как веб-тестирование, тестирование программного обеспечения, тестирование баз данных, тестирование API, тестирование мобильных приложений, обслуживание набора регрессионных тестов, оптимизация и автоматизация, а также межбраузерное тестирование.

TestingWhiz предлагает различные функции, такие как:

Тестирование на основе ключевых слов, данных распределенного тестирование

Тестирование расширения браузера

Object Eye Внутренний рекордер

SMTP интеграция

Интеграция с инструментами отслеживания ошибок, такими как Jira, Mantis, TFS и FogBugz

Централизованное хранилище объектов

Интеграция системы контроля версий

Индивидуальное правило записи

Узнайте больше о TestingWhiz.

3. HPE Unified Functional Testing (HP – UFT ранее QTP)

HP QuickTest Professional был переименован в HPE Unified Functional Testing. HPE UFT предлагает автоматизацию тестирования для функционального и регрессионного тестирования для программных приложений.

Язык сценариев Visual Basic Scripting Edition используется этим инструментом для регистрации процессов тестирования и управления различными объектами и элементами управления при тестировании приложений.

QTP предлагает различные функции, такие как:

Интеграция с Mercury Business Process Testing и Mercury Quality Center

Уникальное распознавание смарт-объектов

Механизм обработки ошибок

Создание параметров для объектов, контрольных точек и таблиц, управляемых данными

Автоматизированная документация

Узнайте больше о HP — UFT.

4. TestComplete

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

TestComplete предлагает следующие функции:

Тестирование GUI

Поддержка языка сценариев — JavaScript, Python, VBScript, JScript, DelphiScript, C ++ Script и C# Script

Тестовый визуализатор

Скриптовое тестирование

Тестовая запись и воспроизведение

Узнайте больше о TestComplete.

5. Ranorex

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

Ranorex предлагает следующие функции:

Распознавание графического интерфейса пользователя

Многоразовые тестовые коды

Обнаружение ошибок

Интеграция с различными инструментами

Запись и воспроизведение

Узнайте больше о Ranorex

6. Sahi

Sahi — инструмент для автоматизации тестирования веб-приложений. Sahi с открытым исходным кодом написан на языках программирования Java и JavaScript.

Sahi предоставляет следующие возможности:

Проводит мультибраузерное тестирование

Поддерживает ExtJS, ZK, Dojo, YUI и др. Фреймворки

Запись и воспроизведение на тестировании браузера

Узнайте больше о Sahi.

7. Watir

Watir — это инструмент тестирования с открытым исходным кодом, состоящий из библиотек Ruby, для автоматизации тестирования веб-приложений. Это произносится как «вода».

Watir предлагает следующие функции:

Тестирует языковое веб-приложение

Кросс-браузерное тестирование

Совместим с бизнес-инструментами разработки, такими как RSpec, Cucumber и Test / Unit

Проверяет кнопки, формы, ссылки и их ответы на веб-страницах

Узнайте больше о Watir.

8. Tosca Testsuite

Tosca Testsuite от Tricentis использует автоматизацию тестирования на основе моделей для автоматизации тестирования программного обеспечения.

Tosca Testsuite обладает следующими возможностями:

План и дизайн теста

Предоставление тестовых данных

Сервис виртуализации сети

Тестирование мобильных приложений

Управление интеграцией

Покрытие риска

Узнайте больше о Tosca Testsuite.

9. Telerik TestStudio

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

Telerik TestStudio предлагает различные совместимости, такие как:

Поддержка языков программирования, таких как HTML, AJAX, ASP.NET, JavaScript, Silverlight, WPF и MVC.

Интеграция с Visual Basic Studio 2010 и 2012

Запись и воспроизведение

Кросс-браузерное тестирование

Ручное тестирование

Интеграция с инструментами отслеживания ошибок

Узнайте больше о Tosca Testsuite.

10. Katalon Studio

Katalon Studio — это бесплатное решение для автоматизации тестирования, разработанное компанией Katalon LLC. Программное обеспечение построено на основе сред автоматизации с открытым исходным кодом Selenium, Appium со специализированным интерфейсом IDE для тестирования API, веб-приложений и мобильных устройств. Этот инструмент включает в себя полный пакет мощных функций, которые помогают преодолеть общие проблемы в автоматизации тестирования веб-интерфейса.

Katalon Studio состоит из следующих функций:

Встроенный репозиторий объектов, XPath, повторная идентификация объекта

Поддерживает языки сценариев Java / Groovy

Встроенная поддержка тестирования на основе изображений

Поддержка инструментов непрерывной интеграции, таких как Jenkins и TeamCity

Поддерживает интерфейс Duel-редактора

Настраиваемый рабочий процесс исполнения

Узнайте больше о Katalon Studio

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

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

тестирование / Блог компании Хабр Карьера / Хабр

QA Start · Академия IT

Семь уроков этого курса познакомят вас с методологиями разработки и их влиянием на качество, с фреймворками гибкой разработки, видами, техниками и уровнями тестирования, с тестовой документацией, а также с работой с дефектами ПО.

Пройти курс →

Интенсив по тестированию ПО · GeekBrains

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

Поступить →

Видеокурс по тестированию ПО · Академия IT

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

Пройти курс →

Верификация программного обеспечения · ИНТУИТ

Программа курса посвящена современным технологиям верификации ПО, применяемыми при промышленной разработке сложных и отказоустойчивых систем. Она охватывает такие темы, как построение тестового окружения, планирование системы тестов, анализ и обнаружение багов, интеграционное и системное тестирование и общие аспекты тестирования интерфейсов.

Пройти обучение →

Профессия «Инженер по тестированию» · Яндекс.Практикум

На этом курсе вы освоите тест-дизайн и овладеете инструментами Postman, Charles, Яндекс.Трекер, а также познакомитесь с Javascript и Puppeteer. Обратите внимание, Яндекс.Практикум предлагает бесплатно пройти только вводную часть курса, состоящую из 10 часов теории и 84 заданий. Это поможет определиться, хотите ли вы двигаться дальше в этом направлении.

Пройти вводную часть →

Автоматизация тестирования с помощью Selenium и Python · Stepik

Это базовый курс для начинающих тестировщиков, на котором вас научат писать автоматизированные UI-тесты на Python с помощью библиотеки Selenium. А еще в программе — популярные фреймворки и лучшие практики написания автотестов.

Пройти курс →

Software Debugging · Udacity

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

Поступить →

Основы тестирования · Академия IT

Еще один базовый курс от Академии, на котором вам расскажут о QA, как таковом, и расскажут о тестовых артефактах, жизненном цикле тестирования, типах приложений, клиент-серверной архитектуре и других полезных вещах.

Пройти обучение →

Software Testing · Udacity

В разработке программного обеспечения разрушение может быть так же ценно, как и созидание. На курсе вас научат ломать любое ПО разными способами, чтобы отыскать в нем баги и уязвимости.

Записаться →

Основы тестирования программного обеспечения · ИНТУИТ

За 14 с небольшим часов этого курса вы не только получите хорошую теоретическую базу знаний о тестировании ПО, но и потренируетесь в нем, выполняя практические задания. В конце курса предусмотрен экзамен по пройденному материалу, так что готовьте зачетки.

Поступить на курс →

Software Testing QA · Академия IT

Курс, на котором вас познакомят не столько с QA, сколько с тем, как начать свой путь в этой специальности. Уроки посвящены прохождению собеседований, лайфхакам и советам для новичков, а также разбору структуры QA команд в IT-компаниях.

Пройти обучение →

Курсы тестировщиков онлайн · Академия IT

Базовый, но от этого не менее полезный курс, который вам пригодится, чтобы получить или освежить знания о тестирование ПО, контроле качества и баг-трекинге.

Записаться →

Тестирование ПО: базовый уровень · Stepik

Курс ориентирован на начинающих тестировщиков и тех, кто хочет потренироваться перед сдачей сертификационного экзамена. Он основан на официальной программе обучения ISTQB, а все 111 тестов составлены из заданий реальных экзаменов ISTQB Foundation Level.

Пройти обучение →

Unit-тестирование С# · Академия IT

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

Записаться на курс →

40+ Популярные вопросы и ответы на собеседовании с аналитиком QA

Наиболее часто задаваемые вопросы и ответы на собеседовании с аналитиком по тестированию / обеспечению качества:

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

Но для того, чтобы попасть в эту категорию, требуется много навыков, понимания обязанностей, а также необходимых должностных обязанностей для выбранной вами карьеры. То же самое и при выборе карьеры QA-аналитика.Для этого нужно не только быть хорошим тестировщиком, быстро учиться, незаурядным мыслителем, но также и умением решать сложные проблемы.

Хотя вышеупомянутые качества не достигается мгновенно, очевидно, требует опыта и дни напряженной работы тоже.

В этой статье будут рассмотрены все аспекты, знания которых являются обязательными для работы аналитиком QA. Приведенные здесь наиболее часто задаваемые вопросы и ответы на собеседование с QA Test Analyst дадут вам четкое представление о подготовке к собеседованию.

Заключение

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

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

Спасибо и удачи с интервью!

Top 40 QA Interview Вопросы и ответы

Home
Testing
- - Back
  - Agile Testing
  - BugZilla
  - Cucumber
  - Database Testing
  - ETL Testing Назад
  - JUnit
  - LoadRunner
  - Ручное тестирование
  - Мобильное тестирование
  - Mantis
  - Почтальон
  - QTP
  - Назад
  - Центр качества (ALM)
  - SAP Testing
  - SAPU
  - Управление тестированием
  - TestLink
SAP
- - Назад
  - ABAP 9 0004
  - APO
  - Начинающий
  - Basis
  - BODS
  - BI
  - BPC
  - CO
  - Назад
  - CRM
  - Crystal Reports
  - QM4
  - 000 HRM
  - Заработная плата
  - Назад
  - PI / PO
  - PP
  - SD
  - SAPUI5
  - Безопасность
  - Менеджер решений
  - Successfactors
  - Учебники SAP
- Обязательно учите!
  - - Назад
    - Бухгалтерский учет
    - Алгоритмы
    - Android
    - Блокчейн
    - Business Analyst
    - Создание веб-сайта
    - CCNA
    - Облачные вычисления
    - 00030003 COBOL
    - Big Data
      - Назад
        AWS
        BigData
        Cassandra
        Cognos
        Хранилище данных
        0003
        HBOps
        0003
        HBOps
        0003
        MicroStrategy
        Монг
    .
    различных типов тестирования с подробностями
    Какие существуют различные типы тестирования программного обеспечения?
    Мы, как тестировщики, знаем о различных типах тестирования программного обеспечения, таких как функциональное тестирование, нефункциональное тестирование, автоматическое тестирование, гибкое тестирование и их подтипы и т. Д.
    Каждый из нас столкнулся бы с несколькими типы тестирования в нашем тестовом путешествии. Возможно, мы слышали некоторые из них и могли работать над некоторыми, но не все знают обо всех типах тестирования.
    Каждый тип тестирования имеет свои особенности, преимущества и недостатки. Однако в этой статье я рассмотрел в основном каждый тип тестирования программного обеспечения, который мы обычно используем в повседневной жизни тестирования.
    Пойдем взглянем на них.
    Различные типы тестирования программного обеспечения
    Ниже приведен список некоторых распространенных типов тестирования программного обеспечения:
    Типы функционального тестирования включают:
    - Модульное тестирование
    - Интеграционное тестирование
    - Системное тестирование
    - Тестирование работоспособности
    - Дымовое тестирование
    - Тестирование интерфейса
    - Регрессионное тестирование
    - Бета / приемочное тестирование
    Типы нефункционального тестирования включают:
    - Тестирование производительности
    - Нагрузочное тестирование
    - Стресс-тестирование
    - Объемное тестирование
    - Безопасность Тестирование
    - Тестирование совместимости
    - Тестирование установки
    - Тестирование восстановления
    - Тестирование надежности
    - Тестирование удобства использования
    - Тестирование на соответствие
    - Тестирование локализации
    Давайте подробнее рассмотрим эти типы тестирования.
    # 1) Альфа-тестирование
    Это наиболее распространенный тип тестирования, используемый в индустрии программного обеспечения. Целью этого тестирования является выявление всех возможных проблем или дефектов до выпуска продукта на рынок или для пользователя.
    Альфа-тестирование проводится в конце фазы разработки программного обеспечения, но перед бета-тестированием. Тем не менее, в результате такого тестирования могут быть внесены незначительные изменения в конструкцию.
    Альфа-тестирование проводится на сайте разработчика.Для этого типа тестирования может быть создана собственная виртуальная пользовательская среда.
    # 2) Приемочное испытание
    Приемочное испытание выполняется клиентом и проверяет, соответствует ли сквозной поток системы бизнес-требованиям или нет, и соответствует ли это потребностям конечного пользователя . Клиент принимает программное обеспечение только тогда, когда все функции и функции работают должным образом.
    Это последний этап тестирования, после которого программное обеспечение запускается в производство.Это также называется приемочным тестированием пользователя (UAT).
    # 3) Специальное тестирование
    Само название предполагает, что это тестирование выполняется на специальной основе, то есть без ссылки на тестовый пример, а также без какого-либо плана или документации для такого типа тестирования.
    Целью этого тестирования является обнаружение дефектов и нарушение работы приложения путем выполнения любого потока приложения или любой случайной функции.
    Специальное тестирование — это неформальный способ поиска дефектов, который может выполнить любой участник проекта.Трудно идентифицировать дефекты без тестового примера, но иногда возможно, что дефекты, обнаруженные во время специального тестирования, не могли быть идентифицированы с использованием существующих тестовых примеров.
    # 4) Тестирование доступности
    Целью тестирования доступности является определение, доступно ли программное обеспечение или приложение для людей с ограниченными возможностями.
    Здесь под инвалидностью понимаются глухие, дальтоники, умственно отсталые, слепые, пожилые и другие группы инвалидов. Выполняются различные проверки, такие как размер шрифта для людей с ограниченными возможностями по зрению, цвет и контрастность для цветовой слепоты и т. Д.
    # 5) Бета-тестирование
    Бета-тестирование — это формальный вид тестирования программного обеспечения, проводимого заказчиком. Это выполняется в Real Environment перед выпуском продукта на рынок для реальных конечных пользователей.
    Бета-тестирование проводится для того, чтобы убедиться в отсутствии серьезных сбоев в программном обеспечении или продукте, а также на соответствие бизнес-требованиям с точки зрения конечного пользователя. Бета-тестирование считается успешным, когда заказчик принимает программное обеспечение.
    Обычно это тестирование проводят конечные пользователи или другие лица. Это заключительное тестирование, проводимое перед выпуском приложения в коммерческих целях. Обычно выпущенная бета-версия программного обеспечения или продукта ограничена определенным количеством пользователей в определенной области.
    Таким образом, конечный пользователь фактически использует программное обеспечение и делится отзывами с компанией. Затем компания предпринимает необходимые действия перед выпуском программного обеспечения по всему миру.
    # 6) Внутреннее тестирование
    Всякий раз, когда ввод или данные вводятся во внешнем приложении, они сохраняются в базе данных, и тестирование такой базы данных называется тестированием базы данных или внутренним тестированием.
    Существуют различные базы данных, такие как SQL Server, MySQL, Oracle и т. Д. Тестирование базы данных включает тестирование структуры таблицы, схемы, хранимой процедуры, структуры данных и так далее.
    В Back-end тестировании графический интерфейс не участвует, тестировщики напрямую подключаются к базе данных с надлежащим доступом, и тестеры могут легко проверять данные, выполняя несколько запросов к базе данных.
    Во время внутреннего тестирования могут быть выявлены такие проблемы, как потеря данных, взаимоблокировка, повреждение данных и т. Д., И эти проблемы критически необходимо исправить до того, как система перейдет в производственную среду. подтип тестирования совместимости (который объясняется ниже) и выполняется группой тестирования.
    Тестирование совместимости браузера выполняется для веб-приложений и гарантирует, что программное обеспечение может работать с комбинацией различных браузеров и операционных систем. Этот тип тестирования также проверяет, работает ли веб-приложение во всех версиях всех браузеров или нет.
    # 8) Тестирование обратной совместимости
    Это тип тестирования, который проверяет, хорошо ли новое разработанное или обновленное программное обеспечение работает со старой версией среды или нет.
    Тестирование обратной совместимости проверяет, правильно ли новая версия программного обеспечения работает с форматом файлов, созданным более старой версией программного обеспечения; он также хорошо работает с таблицами данных, файлами данных, структурами данных, созданными более старой версией этого программного обеспечения.
    Если какое-либо программное обеспечение обновлено, оно должно хорошо работать поверх предыдущей версии этого программного обеспечения.
    # 9) Тестирование черного ящика
    Внутренний дизайн системы не рассматривается в этом типе тестирования.Тесты основаны на требованиях и функциональности.
    Подробную информацию о преимуществах, недостатках и типах тестирования черного ящика можно увидеть здесь .
    # 10) Тестирование граничных значений
    Этот тип тестирования проверяет поведение приложения на граничном уровне.
    Проверка граничных значений выполняется для проверки наличия дефектов на граничных значениях. Тестирование граничных значений используется для тестирования другого диапазона чисел. Для каждого диапазона есть верхняя и нижняя границы, и тестирование выполняется на этих граничных значениях.
    Если для тестирования требуется диапазон значений от 1 до 500, то проверка граничных значений выполняется для значений 0, 1, 2, 499, 500 и 501.
    # 11) Тестирование ветвей
    Это тип белого box Testing и проводится во время модульного тестирования. Тестирование ветвей, само название предполагает, что код тщательно тестируется путем обхода каждой ветки.
    # 12) Сравнительное тестирование
    Сравнение сильных и слабых сторон продукта с его предыдущими версиями или другими подобными продуктами называется сравнительным тестированием.
    # 13) Тестирование совместимости
    Это тип тестирования, при котором проверяется, как программное обеспечение ведет себя и работает в другой среде, веб-серверах, оборудовании и сетевой среде.
    Тестирование совместимости гарантирует, что программное обеспечение может работать в другой конфигурации, в другой базе данных, в разных браузерах и их версиях. Тестирование совместимости выполняется командой тестирования.
    # 14) Тестирование компонентов
    В основном выполняется разработчиками после завершения модульного тестирования.Тестирование компонентов включает в себя тестирование нескольких функций как единого кода, и его цель — определить, существует ли какой-либо дефект после соединения этих нескольких функций друг с другом.
    # 15) Сквозное тестирование
    Подобно системному тестированию, Сквозное тестирование включает в себя тестирование всей среды приложения в ситуации, которая имитирует реальное использование, например, взаимодействие с базой данных с использованием сети связь или взаимодействие с другим оборудованием, приложениями или системами, если это необходимо.
    # 16) Разбиение на эквивалентность
    Это метод тестирования и разновидность тестирования черного ящика. Во время этого разделения на эквивалентность выбирается набор группы и выбираются несколько значений или чисел для тестирования. Подразумевается, что все значения из этой группы генерируют одинаковый результат.
    Целью этого тестирования является удаление избыточных тестовых примеров в определенной группе, которые генерируют такие же выходные данные, но без каких-либо дефектов.
    Предположим, приложение принимает значения от -10 до +10, поэтому при использовании разделения по эквивалентности значения, выбранные для тестирования, равны нулю, одному положительному значению и одному отрицательному значению.Таким образом, разделение эквивалентности для этого тестирования составляет от -10 до -1, 0 и от 1 до 10.
    # 17) Пример тестирования
    Это означает тестирование в реальном времени. Пример тестирования включает сценарий в реальном времени, а также сценарии, основанные на опыте тестировщиков.
    # 18) Исследовательское тестирование
    Исследовательское тестирование — это неформальное тестирование, проводимое командой тестирования. Целью этого тестирования является исследование приложения и поиск дефектов, которые существуют в приложении.
    Иногда может случиться так, что во время этого тестирования обнаруженный серьезный дефект может даже вызвать сбой системы.
    Во время исследовательского тестирования рекомендуется отслеживать, какой поток вы тестировали и какие действия выполняли перед запуском конкретного потока.
    Метод исследовательского тестирования выполняется без документации и тестовых примеров.
    # 20) Функциональное тестирование
    Этот тип тестирования игнорирует внутренние компоненты и фокусируется только на выходе, чтобы проверить, соответствует ли он требованиям или нет.Это тестирование типа «черный ящик», ориентированное на функциональные требования приложения. Для получения подробной информации о функциональном тестировании щелкните здесь.
    # 21) Тестирование графического интерфейса пользователя (GUI)
    Целью данного тестирования GUI является проверка графического интерфейса пользователя в соответствии с бизнес-требованиями. Ожидаемый графический интерфейс приложения упоминается в подробном проектном документе и на экранах макетов графического интерфейса.
    Тестирование графического интерфейса включает размер кнопок и поля ввода на экране, выравнивание всего текста, таблиц и содержимого в таблицах.
    Он также проверяет меню приложения, после выбора других меню и пунктов меню, он проверяет, что страница не колеблется и выравнивание остается неизменным после наведения курсора мыши на меню или подменю.
    # 22) Gorilla Testing
    Gorilla Testing — это тип тестирования, выполняемый тестером, а иногда и разработчиком. В Gorilla Testing один модуль или его функциональность проверяется тщательно и тщательно. Целью этого тестирования является проверка устойчивости приложения.
    # 23) Happy Path Testing
    Целью Happy Path Testing является успешное тестирование приложения в положительном потоке. Он не ищет отрицательных или ошибочных состояний. Основное внимание уделяется только действительным и положительным входным данным, с помощью которых приложение генерирует ожидаемый результат.
    # 24) Инкрементное тестирование интеграции
    Инкрементное тестирование интеграции — это восходящий подход к тестированию, то есть непрерывное тестирование приложения при добавлении новых функций.Функциональность и модули приложения должны быть достаточно независимыми, чтобы их можно было тестировать отдельно. Это делают программисты или тестировщики.
    # 25) Тестирование установки / удаления
    Тестирование установки и удаления выполняется для процессов полной, частичной или обновленной установки / удаления в разных операционных системах в разной аппаратной или программной среде.
    # 26) Тестирование интеграции
    Тестирование всех интегрированных модулей для проверки объединенной функциональности после интеграции называется интеграционным тестированием.
    Модули обычно представляют собой программные модули, отдельные приложения, клиентские и серверные приложения в сети и т. Д. Этот тип тестирования особенно актуален для клиент-серверных и распределенных систем.
    # 27) Нагрузочное тестирование
    Это тип нефункционального тестирования, цель которого — проверить, с какой нагрузкой или максимальной рабочей нагрузкой может справиться система без какого-либо снижения производительности.
    Load Testing помогает определить максимальную емкость системы при определенной нагрузке и любых проблемах, вызывающих снижение производительности программного обеспечения.Нагрузочное тестирование выполняется с использованием таких инструментов, как JMeter, LoadRunner, WebLoad, Silk performer и т. Д.
    # 28) Monkey Testing
    Monkey Testing выполняется тестером, предполагающим, что если обезьяна использует приложение, то как случайный ввод, значения будут может быть введен Обезьяной без каких-либо знаний или понимания приложения.
    Цель Monkey Testing — проверить, не вылетает ли приложение или система, путем предоставления случайных входных значений / данных. Тестирование Monkey выполняется случайным образом, и никакие тестовые примеры не создаются в сценариях, и в этом нет необходимости.
    Тестирование Monkey выполняется случайным образом, тесты не создаются в сценариях, и нет необходимости быть в курсе всех функций системы.
    # 29) Тестирование мутаций
    Тестирование мутаций — это тип тестирования белого ящика, при котором изменяется исходный код одной из программ и проверяется, могут ли существующие тестовые примеры идентифицировать эти дефекты в системе.
    Изменения в исходном коде программы минимальны, так что они не влияют на все приложение, только определенная область, имеющая влияние, и соответствующие тестовые примеры должны быть в состоянии идентифицировать эти ошибки в системе.
    # 30) Отрицательное тестирование
    Тестировщики с мышлением «ломать голову» и с помощью отрицательного тестирования подтверждают это, если система или приложение ломаются.Метод отрицательного тестирования выполняется с использованием неверных данных, неверных данных или ввода. Он подтверждает, что система выдает ошибку о недопустимом вводе и ведет себя должным образом.
    # 31) Нефункциональное тестирование
    Это тип тестирования, для которого каждая организация имеет отдельную команду, которая обычно называется группой нефункционального тестирования (NFT) или командой производительности.
    Нефункциональное тестирование включает в себя тестирование нефункциональных требований, таких как нагрузочное тестирование, стресс-тестирование, безопасность, объем, тестирование восстановления и т. Д.Цель тестирования NFT — убедиться, что время отклика программного обеспечения или приложения достаточно быстрое в соответствии с бизнес-требованиями.
    Загрузка какой-либо страницы или системы не должна занимать много времени и должна выдерживать пиковые нагрузки.
    # 32) Тестирование производительности
    Этот термин часто используется как синоним «стресс-тестирования» и «нагрузочного» тестирования. Тестирование производительности проводится для проверки соответствия системы требованиям к производительности. Для этого тестирования используются различные инструменты производительности и загрузки.
    # 33) Тестирование восстановления
    Это тип тестирования, который проверяет, насколько хорошо приложение или система восстанавливаются после сбоев или сбоев.
    Recovery Testing определяет, может ли система продолжить работу после аварии. Предположим, что приложение получает данные по сетевому кабелю, и внезапно этот сетевой кабель был отключен.
    Через некоторое время подключите сетевой кабель; тогда система должна начать получать данные с того места, где она потеряла соединение из-за отсоединения сетевого кабеля.
    # 34) Регрессионное тестирование
    Тестирование приложения в целом на предмет модификации любого модуля или функциональности называется регрессионным тестированием. Сложно охватить всю систему регрессионным тестированием, поэтому для этих типов тестирования обычно используются инструменты автоматического тестирования.
    # 35) Тестирование на основе рисков (RBT)
    При тестировании на основе рисков функциональные возможности или требования проверяются на основе их приоритета. Тестирование на основе рисков включает в себя тестирование критически важных функций, которые оказывают наибольшее влияние на бизнес и в которых вероятность отказа очень высока.
    Приоритетное решение основывается на потребностях бизнеса, поэтому, как только приоритет установлен для всех функций, сначала выполняются функции с высоким приоритетом или тестовые примеры, а затем функции со средним, а затем с низким приоритетом.
    Функциональность с низким приоритетом может быть протестирована или не протестирована в зависимости от доступного времени.
    Тестирование на основе рисков проводится, если для тестирования всего программного обеспечения недостаточно времени, и программное обеспечение необходимо внедрять вовремя и без каких-либо задержек.Такой подход сопровождается только обсуждением и одобрением клиента и высшего руководства организации.
    # 36) Тестирование работоспособности
    Тестирование работоспособности выполняется, чтобы определить, работает ли новая версия программного обеспечения достаточно хорошо, чтобы принять ее для серьезного тестирования или нет. Если приложение дает сбой при первоначальном использовании, значит, система недостаточно стабильна для дальнейшего тестирования. Следовательно, для его исправления назначается сборка или приложение.
    # 37) Тестирование безопасности
    Это вид тестирования, проводимый специальной командой тестировщиков.Система может быть взломана любым способом.
    Тестирование безопасности проводится для проверки того, насколько программное обеспечение, приложение или веб-сайт защищены от внутренних и внешних угроз. Это тестирование включает в себя, насколько программное обеспечение защищено от вредоносных программ и вирусов, а также насколько безопасны и надежны процессы авторизации и аутентификации.
    Он также проверяет, как программное обеспечение ведет себя в случае любых хакерских атак и вредоносных программ, и как поддерживается программное обеспечение для защиты данных после такой хакерской атаки.
    # 38) Smoke Testing
    Всякий раз, когда группа разработчиков предоставляет новую сборку, группа тестирования программного обеспечения проверяет сборку и гарантирует отсутствие серьезных проблем.
    Команда тестирования гарантирует, что сборка будет стабильной, и будет проведено детальное тестирование. Smoke Testing проверяет, что в сборке не существует дефекта, показывающего стопор, что помешает группе тестирования подробно протестировать приложение.
    Если тестировщики обнаруживают, что основная критически важная функциональность не работает на самом начальном этапе, группа тестирования может отклонить сборку и сообщить об этом группе разработчиков.Дымовое тестирование проводится на детальном уровне любого функционального или регрессионного тестирования.
    # 39) Статическое тестирование
    Статическое тестирование — это тип тестирования, который выполняется без какого-либо кода. Выполнение документации выполняется на этапе тестирования.
    Он включает в себя обзоры, пошаговое руководство и проверку результатов проекта. Статическое тестирование не выполняет код вместо синтаксиса кода, соглашения об именах проверяются.
    Статическое тестирование также применимо для тестовых случаев, плана тестирования, проектной документации.Команда тестирования должна выполнять статическое тестирование, поскольку дефекты, выявленные во время этого типа тестирования, экономически эффективны с точки зрения проекта.
    # 40) Стресс-тестирование
    Это тестирование проводится, когда система находится под нагрузкой, превышающей ее спецификации, чтобы проверить, как и когда она выходит из строя. Это выполняется при большой нагрузке, такой как вывод большого числа за пределы емкости хранилища, сложные запросы к базе данных, постоянный ввод в систему или загрузка базы данных.
    # 41) Тестирование системы
    В рамках метода тестирования системы вся система тестируется в соответствии с требованиями.Это тестирование типа «черный ящик», основанное на общих технических требованиях и охватывающее все комбинированные части системы.
    # 42) Модульное тестирование
    Тестирование отдельного программного компонента или модуля называется модульным тестированием. Обычно это делается программистом, а не тестировщиками, поскольку для этого требуются подробные знания внутренней структуры программы и кода. Также может потребоваться разработка модулей тестового драйвера или тестовых жгутов.
    # 43) Тестирование удобства использования
    В разделе «Тестирование удобства использования» выполняется проверка удобства использования.Поток приложения проверяется, чтобы узнать, может ли новый пользователь легко понять приложение или нет. Соответствующая справка задокументирована, если пользователь застрял в какой-либо точке. В основном в этом тесте проверяется системная навигация.
    # 44) Тестирование уязвимости
    Тестирование, которое включает выявление слабых мест в программном обеспечении, оборудовании и сети, известно как тестирование уязвимостей. Вредоносные программы, хакер может получить контроль над системой, если она уязвима для такого рода атак, вирусов и червей.
    Таким образом, перед производством необходимо проверить, проходят ли эти системы тестирование на уязвимость. Он может выявить критические дефекты, изъяны в безопасности.
    # 45) Объемное тестирование
    Объемное тестирование — это тип нефункционального тестирования, выполняемого группой тестирования производительности.
    Программное обеспечение или приложение обрабатывает огромный объем данных, и Volume Testing проверяет поведение системы и время отклика приложения, когда система обнаруживает такой большой объем данных.Такой большой объем данных может повлиять на производительность системы и скорость обработки.
    # 46) Тестирование белого ящика
    Тестирование белого ящика основано на знании внутренней логики кода приложения.
    Это также известно как Тестирование стеклянных ящиков. Для выполнения этого типа тестирования необходимо знать, как работает внутреннее программное обеспечение и код. Эти тесты основаны на покрытии операторов кода, ветвей, путей, условий и т.д.
    Заключение
    Вышеупомянутые типы тестирования программного обеспечения являются лишь частью тестирования.Однако до сих пор существует список из более чем 100+ типов тестирования, но не все типы тестирования используются во всех типах проектов. Итак, я рассмотрел некоторые общие типы тестирования программного обеспечения, которые в основном используются в жизненном цикле тестирования.
    Кроме того, в разных организациях используются альтернативные определения или процессы, но основная концепция везде одинакова. Эти типы тестирования, процессы и методы их реализации продолжают меняться по мере изменения проекта, требований и содержания.
    .
    No related posts.

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Qa test: Путь QA бойца / Хабр

Тестовое задание QA / Хабр

Кто ты, QA-инженер или тестировщик?

QA, QC и тестировщики: три большие разницы?

Ищу Тестировщика ПО (QA-инженера)

Что такое обеспечение качества

QA ≠ QC: как их различить

Как дальше жить?

«Подготовка к собеседованию QA» starter pack или самая большая шпаргалка вопросов-ответов по тестированию / Хабр

Manual part 1

HR-часть

Общее о тестировании

Виды тестирования

Тест дизайн

Manual part 2

Тестовые артефакты и документация (Test Deliverables/TestWare/test artifacts)

Дефекты и ошибки

SDLC и STLC

Тестирование в разных сферах/областях (testing different domains)

Мобильное тестирование

Сети и около них

Базы данных

ПРАКТИКА

С чего начать абсолютному новичку?

Полезное

Источники

Специальность QA Software Tester или кто такой Quality Assurance Engineer

Лучшие системы управления тестированием 2019 / Хабр

Что мы хотим от системы управления тестированием?

10 лучших инструментов для автоматизации тестирования ПО / Хабр

10 лучших инструментов для автоматического тестирования программного обеспечения

1. Selenium

2. TestingWhiz

3. HPE Unified Functional Testing (HP – UFT ранее QTP)

4. TestComplete

5. Ranorex

6. Sahi

7. Watir

8. Tosca Testsuite

9. Telerik TestStudio

10. Katalon Studio

тестирование / Блог компании Хабр Карьера / Хабр

40+ Популярные вопросы и ответы на собеседовании с аналитиком QA

Популярные вопросы интервью с аналитиком QA

Заключение

Top 40 QA Interview Вопросы и ответы

различных типов тестирования с подробностями

Различные типы тестирования программного обеспечения

# 1) Альфа-тестирование

# 2) Приемочное испытание

# 3) Специальное тестирование

# 4) Тестирование доступности

# 5) Бета-тестирование

# 6) Внутреннее тестирование

# 8) Тестирование обратной совместимости

# 9) Тестирование черного ящика

# 10) Тестирование граничных значений

# 11) Тестирование ветвей

# 12) Сравнительное тестирование

# 13) Тестирование совместимости

# 14) Тестирование компонентов

# 15) Сквозное тестирование

# 16) Разбиение на эквивалентность

# 17) Пример тестирования

# 18) Исследовательское тестирование

# 20) Функциональное тестирование

# 21) Тестирование графического интерфейса пользователя (GUI)

# 22) Gorilla Testing

# 23) Happy Path Testing

# 24) Инкрементное тестирование интеграции

# 25) Тестирование установки / удаления

# 26) Тестирование интеграции

# 27) Нагрузочное тестирование

# 28) Monkey Testing

# 29) Тестирование мутаций

# 30) Отрицательное тестирование

# 31) Нефункциональное тестирование

# 32) Тестирование производительности

# 33) Тестирование восстановления

# 34) Регрессионное тестирование