Тестовое задание QA / Habr
Некоторое время назад я проходил собеседование на позицию QA инженера в одной известной российской IT-компании. Мне была предложена задача, свое решение которой с позволения компании я опубликовал в своем блоге. Пост оказался очень популярным, за короткое время набрав несколько тысяч просмотров, и мне показалась светлой мысль продублировать его на Хабре. По правилам Хабра текст публикуется без смайликов.Итак, задача звучала следующим образом: необходимо описать шаги для всестороннего тестирования простого карандаша с резинкой на одном из концов.
Решение — под катом.
Поскольку карандаши — вообще замечательнейшая и любимая тема, я получил несказанное удовольствие от этого задания. В процессе размышления и поиска информации открыто много нового и интересного, о чем раньше я и не подозревал…
Итак, имеем карандаш:
По условию задачи, поскольку никаких дополнительных условий не задано, поэтому полагаем, что:
1. Карандаш не механический, а именно простой — деревянный или пластиковый. Про цвет ничего не сказано — т.о. карандаш может быть цветным. По-сути, данное условие говорит только о том, что данный карандаш более пригоден для рисования, чем для простых записей и черчения; конечно, не факт, но положим данное условие несущественным — намеренно не будем рассматривать тестирование карандашей разных цветов. При желании рассмотрим этот вопрос отдельно.
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 и как стать тестировщиком?
Что значит следить за качеством, кто такой тестировщик, как тестировать сайт или программу? Давайте во всем разбираться.
Существует понятие Quality Assurance, QA. Это сложный процесс обеспечения качества, который охватывает все этапы разработки программного продукта в компании. В QA входит изучение процессов и определение всех условий и обстоятельств, которые могут повлиять на качество разработки и конечный продукт.
Quality Control, QC ‒ это контроль качества во время разработки продукта и анализ состояния в текущий момент времени на соответствие требованиям.
Этап контроля, тестирование ПО, состоит из планирования тестов, их выполнение, анализа результатов.
Кто такой тестировщик
Тестировщик следит за качеством продукта над которым работают в компании. Он проверяет работу сайта, приложения или программы, чтобы она соответствовала всем требованиям. Другими словами, если заказчик просит компанию разработать простое Android приложение для вызова такси с функционалом А и В, то приложение именно так и должно работать.
Тестировщик работает с требованиями к программному продукту. Программисты пишут код и разрабатывают продукт. На стадии разработки тестировщик внимательно изучает документацию и продумывает тесты, которые будет проводить. Когда процесс разработки приложения подходит к концу тестировщик проверяет продукт на соответствие требованиям, которые указаны в технической документации и корректную работу. Если в документах написали, что пользователь может зарегистрироваться используя свой Google аккаунт, то он должен зарегистрироваться только с помощью своего аккаунта Google. Не номера телефона, не профиля Facebook и не Apple ID. Только Google аккаунт.
Тестировщик проходит еще и путь пользователя. Он выполняет все действия, которые мог бы совершить пользователь продукта. Он регистрируется, пишет и отправляет сообщения, выбирает и меняет аватар. Выполняет тестирование use case, дымовое тестирование, нагрузочное тестирование и т.д.
QA Engineer следит за неполадками и ошибками, которые могут появится. Он регулярно проверяет продукт на соответствие требованиям. Приложение или программа должны работать так, как того требует заказчик и специфика его работы. Он следит за тем, чтобы программисты поправляли функционал программы и при этом не ломали другие части продукта.
Несоответствия или баги, которые обнаружил тестировщик, попадают в баг-репорт. Команда разработки поправляет все и тестировщик проверяет снова.
Тестировщик хорошо знает, как должно работать ПО, поэтому вместе с командой программистов он работает над тем, чтобы программа корректно функционировала и работала так, как того хотел заказчик или пользователи.
Легко ли стать тестировщиком
Ответ зависит от подготовки, предыдущего опыта и того, что следует подучить. Учиться необходимо. Сами знаете, что изучать и вникать в новую и сложную тему не так уже и просто.
Работа тестировщика подойдет внимательным и даже скрупулезным людям.
Вот представьте, что необходимо протестировать простой карандаш. Что будете делать? Как тестировать? Подбросите его или попробуете сломать, а может проверите пишет ли он? В некоторых компаниях тестирование карандаша является одним из вопросов при приеме на работу. Решение этого шуточного задания показывает интерес к тестированию и пониманию его основных процессов.
В тестирование приходят разными путями. Часто студенты, которые изучают программирование или системную инженерию, начинают работать в крупных проектах именно на позиции тестировщиков. Когда они получают диплом, то уже сильно увлечены тестированием и могут остаться на своих позициях. В тестирование приходят люди из других профессий. По разным причинам человек меняет профессию: нет перспектив развития или нет интереса к работе. Тестирование ПО совмещает гуманитарные и технические знания, а сама IT-сфера довольно быстро развивается и является достаточно привлекательной для работы.
Что нужно для работы тестировщиком
Основной набор знаний тестировщика, конечно, сильно зависит от компании и специфики самого проекта.
В любом случае, необходимо желание учить новое и постоянно развиваться. Во-первых, знакомство с тестированием и желание понять и разобраться с новыми знаниями.
Во-вторых, знания основ тестирования хватит на первое время. Потом придется постоянно развиваться и самому следить за новыми технологиями, знакомиться с ними и использовать в работе. Придется учить и делать самому многое.
Любознательны и готовы все время учиться? Вы готовы к этому? Если ответ положительный, тогда тестировщику необходимо быть готовым к постоянному обучению и развитию.
1. Теория тестирования
Главные знания начинаются с того, что человек, которые решил выучить тестирование программного обеспечения (QA) должен разбираться в теории и практике тестирования и контроле качества программного продукта.
Он хорошо знает и понимает весь цикл разработки ПО: от идеи до сдачи проекта или вывода его на рынок. Конечно, тестировщик разбирается в методологиях тестирования, знает виды тестирования и его уровни. Умеет читать техническую документацию, анализировать требования и составлять тестовую документацию.
2. Bug-tracking системы
Тестировщик описывает все найденные несоответствия, баги в специальной системе. Он детально описывает несоответствия, присваивает приоритет по его устранению, описывает свой путь в программе и еще указывает множество деталей, которые помогут команде разработки подправить все несоответствия. Обычно для этого используют JIRA или Redmine.
Тестировщик умеет работать с тест-кейсами, тест-планами, чек-листами и баг-трекерами.
3. Язык запросов SQL и работа с базами данных
Тестировщику приходится сталкиваться с информацией, которая хранится в базах данных. Поэтому язык запросов SQL и работа с базами данных будет очень полезна тем, кто планирует тестировать программы и приложения. SQL встречается в описаниях почти каждой вакансии тестировщика.
4. Дополнительные технологии
В зависимости от специфики компании и проекта от тестировщика могут требовать знания дополнительных технологий. Например, для тестирования Web-приложений и сайтов понадобится HTML/CSS, JavaScript, jQuery и HTTP. Тестировать мобильные приложения будет проще, когда умеешь работать с Genymotion, VirtualBox и iOS Simulator.
5. Английский язык
Знания английского языка давно стали необходимой частью для работы в IT-компаниях. Зачастую заказчики или часть команды находяться в других странах и основная коммуникация с ними проходит на английском языке: переписка, переговоры, общение. Английский позволяет быстро получать актуальную информацию для работы: прочитать статью или посмотреть вебинар.
6. Коммуникационные навыки
Тестировщик, которые обладает отличными навыками коммуникации и способен донести информацию до команды, невероятно ценный сотрудник для компании. Навыки коммуникации и командная работа позволяют решить многие проблемы очень быстро, а значит работать эффективно.
7. Аналитический склад ума и внимательность
Внимание к деталям важны для того, кто тестирует программу или приложение. Не заметишь или пропустишь маленькую деталь на этапе тестирования, но если ее заметит пользователь, то это может привести к плохому впечатлению от продукта и переходу пользователей к конкурентам.
Выучить основы QA и найти работу тестировщика можно, но придется многому учиться, искать информацию и разбираться с новыми понятиями.
На курсе по тестированию программного обеспечения (QA) студент получает базовые знания. Выполняя домашние задания, посещая семинары студент сможет решить элементарные задачи в компании. Для старта этого будет достаточно. Но с первого места работы тестировщика все только начинается. Дальше предстоит самому учиться и быстро разбираться с новыми задачами. В IТ не нужны люди, которые останавливаются и не развиваются.
Задумываетесь о работе в IT-компании и считаете тестирование самой подходящей для себя специальностью? В учебном центре подготовки IT-специалистов Level Up есть курс по тестированию программного обеспечения. Начните свою карьеру в QA с нами!
Кто такие QA и почему выпуск забагованной iOS 13 — это нормально
Onliner вместе с компанией ISsoft добрался до одной из самых стереотипных специальностей в IT-сфере. Порой можно встретить мнение, что через профессию тестировщика легче всего попасть в то самое «айти», причем работа, в общем-то, довольно простая. На деле, конечно, все немного не так. QA-специалист с десятилетним опытом Роман Романчук рассказал, как же устроена эта работа и к чему тестировщику нужно быть готовым.
Что должен уметь тестировщик и QA
— QA и тестировщик — это одно и то же?
— Некоторые говорят «тестирование», а некоторые — «обеспечение качества», то есть QA. Второе понятие более широкое, ведь тестирование — это просто проверка (валидация и верификация). А обеспечение качества — целый процесс внутри команды.
— Какие перспективы у тестировщика?
— Он может развиваться как технически, то есть расти в автоматизацию, так и прокачивать софт-скиллы, расти в QA-лида, QA-менеджера и так далее. В техническом плане кроме автоматизации можно идти в архитектуру — это уже сложный уровень. Если совсем глобально смотреть, тестировщик может перебраться в разработку.
— Насколько нужно знать технические вещи? Достаточно просто сказать «это не работает» или еще нужно понимать причину?
— С минимальным опытом тестировщику сложно понимать, как устроена серверная архитектура или веб-приложение, что на бэкэнде, какие сервисы. То есть описание багов идет поверхностное, как со стороны обычного пользователя: кнопка не работает на сайте — так и пишет. Более опытный тестировщик должен понять, почему кнопка не нажимается. Смотрит консоль: может, JavaScript, а может, запрос пошел, но в ответе ошибка — значит, бэкэнд упал. Чем опытнее тестировщик, тем глубже он копает причину бага. Следовательно, он умеет лучше ее описать, и разработчики смогут быстрее найти и исправить ошибку.
— То есть идеальный тестировщик — это еще и разработчик в душе?
— Хороший тестировщик, опытный, высокого уровня — он немного и разработчик, и бизнес-аналитик, и UX/UI-дизайнер, и проектный менеджер.
— И вы ищете изъяны в их работе, получается.
— Здесь важно понимание целей. Это ведь командная работа, и глобальная задача — сделать качественный продукт вовремя и чтобы клиент был доволен. Когда команда понимает, что работает на общий результат, а не на поиски ошибок конкретного разработчика, тогда все друг другу доверяют.
— Если бы те же разработчики идеально выполняли работу, то тестировщики остались бы без дела?
— Не думаю. В простых системах и продуктах это было бы возможно. Например, при разработке какого-нибудь сайта-визитки QA зачастую и не нужен, проекты сдаются без его привлечения. А когда речь идет о сложных продуктах по автоматизации бизнес-процессов, решению конкретных проблем заказчика — там всегда есть вещи, которые никогда не смогут на 100% учесть ни разработчики, ни дизайнеры. Есть много ниш для проверок: безопасность, стабильность работы. Если пишешь код, держать в голове все эти аспекты невозможно.
Почему выходят забагованные продукты
— Иногда видишь такое: выходит крупное мобильное приложение версии 1.0, и уже через неделю — версия 1.0.1, в описании которой говорится об «исправлении ошибок». Значит, продукт плохо тестировали?
— Часто первая версия продукта — просто проверка рынка, отреагирует он или нет. Для этого надо сделать приложение быстрее других и чтобы оно кое-как работало. Если задача именно такая — то ничего страшного в выпуске сырой версии нет. Конечно, когда все согласовано и заказчика устраивает этот вариант. А баги уже потом можно дофиксить.
Другое дело — например, банковское приложение. Здесь уже непозволительно выпускать забагованный продукт, репутация очень важна.
— За два месяца iOS 13 получила около пяти обновлений, и большинство из них касались не добавления новых функций, а правок существующих. Почему такое происходит? Вряд ли Apple не хватило средств на тестирование.
— У Apple есть четкие циклы выпуска продуктов: нужно в год уложить разработку нового железа и софта, а затем поддерживать совместимость ПО с прошлыми устройствами. Не всегда получается за один год заложить и новые фичи, и новое железо, отсюда и возникают проблемы. Понятно, что это сложнейшие проекты, и регулярно идет «процентовка» — проверка вида «успеваем / не успеваем». Где-то возникли проблемы с производителем железа, где-то споткнулись на какой-нибудь фишке. Тогда принимается осознанное решение: да, будут недоработки, но нужно выходить в любом случае.
Падение стоимости акций компании значительно хуже при невыходе нового iPhone, чем при выпуске забагованной операционной системы.
Представьте варианты использования одного и того же смартфона: разные операторы, типы подключений, стандарты беспроводных сетей. Проверить такое многообразие невозможно даже с помощью автотестов. Поэтому всегда будут возникать какие-то специфические баги, и нужно быть готовым быстро их исправить в случае обнаружения.
О разных типах тестирования
— Есть «тестирование низкого уровня». Что это и какие уровни, методы еще бывают?
— Существует большое количество классификаций тестирования по уровням, типам, методам и подходам. Если мы говорим о тестировании на низком уровне, то сюда больше подходит понятие «тестирование методом серого ящика». Например, есть проекты, где разработка ведется на низком уровне. Это написание кода, который взаимодействует непосредственно с железом. В последние годы понятие используется в связи с развитием интернета вещей — всевозможные кофеварки и чайники, которые подключаются к интернету. И чтобы это маленькое устройство могло соединиться с Wi-Fi-точкой, смартфоном по Bluetooth и так далее, нужен софт. Но не в обычном понимании, а без UI. Вот это и есть «низкий уровень». К примеру, измерение температуры воды в чайнике, передача этих данных на смартфон — программирование низкого уровня. Сейчас у этой сферы прямо новое дыхание.
А поскольку разработка ведется на низком уровне, то и тестирование должно быть на нем же. Тестировщик должен понимать, что здесь идет проверка не только софта, но и железа. Допустим, нужно проверить новую модель слухового аппарата. Надо понимать, что у устройства есть встроенная память, она делится на энергозависимую и независимую и так далее. Чем больше тестировщик знает таких деталей, тем эффективнее будет проходить испытание.
— Как выглядит мануальное тестирование? Допустим, нужно проверить сайт. Берете и прокликиваете каждую кнопку, смотрите, куда ведут ссылки?
— Все думают, что именно так это и выглядит. На самом деле описанное — уровень джуниора. Действительно, они могут проводить такое тестирование: проверять работоспособность каждой функции и так далее.
А если мы говорим про обеспечение качества (QA), то сперва нужно посмотреть на сам сайт, узнать у клиента необходимые функциональные и нефункциональные требования, процесс работы, приоритеты. Например, важны ли UI-требования, соответствия палитры и другие вещи. Дальше мы создаем тест-план, в котором, скажем, в рамках UI-тестирования смотрим четкие аспекты — цвет, разрешение (для поддержки различных форм-факторов устройств: ноутбуки, планшеты, телефоны), наличие прототипа интерфейса и так далее.
Некоторые клиенты, к примеру, хотят конкретный цвет, и мы проверяем на полное совпадение по коду оттенка. И так проходим по каждому из типов тестирования. В тест-плане важно правильно описать и согласовать с клиентом наше видение процессов, подходов и планов по тестированию, ведь от этого зависит бюджет, размер команды и необходимая квалификация тестировщиков. В QA масса всего: какие браузеры как отображают сайт; есть ли у него интеграции, например, с банковскими сервисами; под какой нагрузкой он будет работать и так далее. Отдельная и одна из самых сложных граней — безопасность и проверка на наличие уязвимостей.
— Что, если тестировщик заметит проблему в UX? Что-то показалось неудобным, нелогичным. Это его сфера ответственности?
— Думаю, да. Если делаем аналог Booking, то понимаем, что сервисом будут пользоваться миллионы людей. И, например, есть список со множеством фильтров. Когда разработчики добавили популярный фильтр куда-то вниз страницы и до него нужно скролить или он просто малозаметный, тестировщик наверняка это увидит — и такое, я считаю, нужно отправлять на доработку.
Хотя, опять же, предварительно нужно обговорить с клиентом, обращать внимание на подобные вещи при тестировании или нет. Но базовое понимание юзабилити у хорошего тестировщика должно быть.
Как обстоят дела с подготовкой людей, из каких отраслей переходят в QA и что вообще высшее образование может дать тестировщику, мы узнали в Институте информационных технологий БГУИРа. Декан факультета повышения квалификации и переподготовки кандидат технических наук, доцент Андрей Говин, кандидат физико-математических наук, доцент Инна Кашникова и кандидат технических наук, доцент Валерий Мухаметов рассказали, почему тестировщики в 35 лет становятся «пенсионерами» и куда они идут дальше.
Век такого тестировщика после курсов — 30—35 лет
— Есть мнение, что попасть в IT через тестирование проще всего. Согласны ли с этим и почему?
Андрей Говин: Да, такое мнение действительно есть. Скорее всего, оно складывается из-за малого времени обучения, особенно если говорим о внутренних курсах IT-компаний. Но есть опасность. Вы получите знания в узконаправленной компетенции, то есть то, что нужно заказчикам здесь и сейчас. Дальнейшее развитие специалиста — его личная забота, заказчика это не интересует.
Примерно в 35 лет тестировщик подходит к пенсионному возрасту в IT-сфере. Так же с другими профессиями. Например, программист к этому времени достигает пика по зарплате, а потом она плавно снижается. Затем он становится менее креативным и к 35 годам понимает, что должен что-то делать: или открывать свою компанию, переходить на управленческие позиции, или идти в преподаватели. Молодежь в Беларуси очень способная и дышит в спину очень активно. По крайней мере, у меня такое мнение сложилось о рынке.
— Тестировщик должен быть каждым понемногу: и программистом, и бизнес-аналитиком, и дизайнером. Значит, одного образования может не хватить?
Инна Кашникова: Наверное, сейчас в нашей жизни одного образования никому не хватит. Вам ведь понадобятся знания в той области, в которой вы работаете. Тестируете проекты, которые представлены на финансовых рынках, — значит, нужно иметь представление о том, что такое финансовый рынок. Поэтому да, узконаправленные специалисты, наверное, просто не могут работать.
— Как часто обновляете программы подготовки?
Валерий Мухаметов: Специальность тестировщика для нас относительно молодая. Мы обновляем программы каждый год. По своим дисциплинам могу за год сделать пять-шесть версий материалов. Все действительно быстро меняется.
Инна Кашникова: Фактически к каждому набору преподаватели пересматривают лабораторные работы, практикумы, и все постоянно обновляется.
Кандидат медицинских наук пошел учиться на айтишника
— Из каких сфер приходят к вам на курсы? Врачи, учителя, айтишники других специальностей?
Валерий Мухаметов: Люди очень разные. Входного барьера у нас нет, нужен только диплом о высшем образовании, никаких вступительных экзаменов. Поэтому к упомянутым учителям и врачам можно добавить кого угодно. К примеру, на специальность «Программное обеспечение информационных систем» пришла врач-гинеколог с десятилетним стажем.
Андрей Говин: Недавно у нас закончил обучение кандидат медицинских наук, а сейчас учится кандидат юридических наук. Представляете, насколько люди решили поменять свою жизнь? Ведь у них хорошая база уже была в своей сфере. Но специалисты захотели идти дальше.
Валерий Мухаметов: Однажды по совету мужа пришла женщина. У нее образование было связано с биологией, и мы сказали, что перечень специальностей не позволяет ей учиться у нас — он хоть и широкий, но ограничен все же. Тогда она пошла в Министерство образования, добилась от них разрешения на учебу у нас, закончила курс с отличием и сейчас работает в крупной IT-компании.
— Дайте напоследок по одному совету для тестировщика.
Андрей Говин: Обращусь к школьникам: ходите на курсы по профильной ориентации, которых сейчас становится много. Посмотрите на программирование, тестирование, дизайн — поймете, что к чему.
Инна Кашникова: Задача современного человека — постоянно развиваться и оставаться в тренде. Профессия тестировщика хоть и востребована, но, на мой взгляд, не должна быть одной на всю жизнь. Вам понадобятся новые знания и развитие.
Валерий Мухаметов: Я сказал бы о важности стыков двух наук. Как правило, специалистов в одной области всегда много, а вот в смежных отраслях таковых уже гораздо меньше. Поэтому совет — выжимать максимум из своего образования, и лучше не одного, а минимум двух.
Компания ISsoft — один из крупнейших белорусских разработчиков IT-решений для рынков США и Западной Европы. Основана в Минске в 2004 году как дочерняя компания корпорации Coherent Solutions, Inc. (США). Резидент Парка высоких технологий с 2007 года. Центры разработки ISsoft в Минске и Бресте насчитывают более 1000 квалифицированных сотрудников. Компания ежегодно входит в рейтинги Inc.5000 и Software 500.
Спецпроект подготовлен при поддержке иностранного производственного унитарного предприятия «ИССОФТ СОЛЮШЕНЗ», УНП 190819327.
Читайте также:
Библиотека Onliner: лучшие материалы и циклы статей
Наш канал в Telegram. Присоединяйтесь!
Быстрая связь с редакцией: читайте паблик-чат Onliner и пишите нам в Viber!
Перепечатка текста и фотографий Onliner без разрешения редакции запрещена. [email protected]
QA и тестирование — в чем разница?
В терминах бывает сложно разобраться, особенно когда значения схожи или пересекаются. Сегодня речь пойдет об обеспечении качества (QA – от англ. Quality Assurance). Это неотъемлемая часть разработки мобильных приложений, роль которой часто недооценивают. А зря.
Обеспечение качества часто путают с тестированием, а тестировщиков называют специалистами в области обеспечения качества. Пора развеять заблуждения и рассказать подробнее об этом процессе, его необходимости и результатах, которые вы должны получить.
Что есть что?
Существует 3 термина, которые легко перепутать: тестирование (Testing), контроль качества (QC – Quality Control) и обеспечение качества (QA — Quality Assurance). Все они связаны друг c другом: QA – самое широкое понятие, оно включает в себя QC, в которое входит тестирование.
- Обеспечение качества (QA) отвечает за весь процесс разработки, поэтому должно быть интегрировано во все этапы разработки: от описания проекта до тестирования, релиза и даже пост-релизного обслуживания. Специалисты QA создают и реализуют различные тактики для повышения качества на всех стадиях производства: подготовка и установление стандартов, анализ качества, выбор инструментов, предотвращение появления ошибок и постоянное усовершенствование процесса.
- Задача Контроля качества (QC) — гарантировать соответствие требованиям (поиск ошибок и их устранение). QC ориентирован на проверку продукта, включает в себя многие процессы, такие как анализ кода, технические обзоры, анализ дизайна, тестирование и пр.
- Тестирование — это проверка результатов работы на соответствие требованиям.
Почему необходимо обеспечение качества?
Не экономьте на QA! Закладывайте эти расходы в бюджет разработки вашего приложения. Да, ценник от этого значительно вырастет — обеспечение качества может составить 25-50% от стоимости разработки приложения.
Помните: вы выпускаете продукт на высококонкурентный рынок (каким является рынок мобильных приложений) — нельзя делать его как попало. Лучше до релиза по максимуму «выловить» баги, чтобы не обрабатывать негативные отзывы. Не факт, что вам дадут второй шанс после крайне неудачного опыта, даже если вы все исправите. Не рискуйте лояльностью пользователей и своей репутацией. Вложитесь в QA, это оправданные траты.
Критичных проблем вы сможете избежать, но небольшие ошибки возможны. Даже в продуктах, выпускаемых Microsoft, Google и Facebook, которыми каждый день пользуются миллионы, находятся проблемы и недоработки. Способа создать идеальное приложение с первой попытки пока не изобрели, но есть методы, позволяющие свести вероятность ошибок к минимуму и предотвратить их появление.
Что вы получаете в результате?
- Тест-план (Test plan). Документ, описывающий полный объем работ, служит основой для тестирования. Тест-план включает описание объекта тестирования, задачи тестирования и объемы работ, тестовые сценарии, распределение обязанностей членов команды, ожидаемые результаты тестирования, указание тестовой среды и инструментов.
- Тестовые сценарии (Test cases). Тестовый сценарий — перечень действий, которые необходимо выполнить, чтобы проверить определенную функцию или функции приложения.
- Доступ к аналитике. Получив доступ к системе отслеживания ошибок, вы сможете увидеть все обнаруженные баги и убедиться, что они были устранены.
Мы много лет разрабатываем приложения, и относимся к проектам клиента как к собственным. Инвестируя в обеспечение качества, вы инвестируете в репутацию своей компании и успех продукта. Как показывает опыт, оно того стоит.
Основные показатели процесса QA / Luxoft corporate blog / Habr
В рамках Quality Assurance могут и должны быть использованы различные метрики и показатели качества продукта и процесса разработки. Метрики можно разделить на группы по параметрам, на основании которых они рассчитываются, по этапам жизненного цикла разработки, на которых они применяются, по целям и задачам, по стейкхолдерам, для которых они предназначены. Этот список можно продолжать и дальше.В этой статье я решил собрать вместе и рассмотреть самые основные, на мой взгляд, группы критериев и измерителей для QA процесса. А в каждой группе я перечислю только самые важные и показательные, опять же на мой взгляд, метрики а также разберу, для чего они необходимы, в каких ситуациях полезны и как их использовать.
Какими должны быть метрики?
Сама по себе метрика в контексте ПО — это численное выражение какого-либо свойства, качества самого продукта или процесса его разработки. Иными словами, это то, с помощью чего мы можем измерить, сравнить и оценить ПО.
Теперь буквально пара комментариев по поводу значений и свойств метрик:
- Основная цель любой метрики — это улучшение процесса разработки и самого программного продукта. Метрика позволяет увидеть, в какой точке на пути к целям мы находимся в данный момент, приближаемся к ним или удаляемся, достигаются ли критерии успешности.
- Метрики не должны существовать ради самого процесса измерения. Необходимо использовать только те метрики, которые действительно имеют практическое значение и будут влиять на дальнейшее развитие продукта или оптимизацию процесса. Отсюда следует простое правило – сначала нужно определить зоны для изменения\улучшения, а потом решать, как их оценивать.
Основные группы метрик для QA
Теоретически возможно придумать свою характеристику, формулу или показатель практически для каждого, даже самого незначительного действия, этапа или статуса процесса QA. Можно учитывать каждый артефакт, все переходы дефектов по статусам, вычислять количество тестов в наборе. Однако, самый важный вопрос, который сразу следует задать себе, когда возникает желание что-то измерить: «Зачем нужна эта информация, как ее можно использовать?». При формирования набора метрик, следует отталкиваться от целей, планов по улучшению процессов и продукта.
Итак, в этой статье мы не будем рассматривать обычные количественные показатели прогресса тестирования, которые используются в большинстве отчетов и статусов. Вместо этого разберем, какие сферы, артефакты и области разработки с точки зрения Quality Assurance мы должны измерять и контролировать для оценки качества выполнения работы. Анализ и оптимизация этих точек крайне важнны для эффективного взаимодействия со стейкхолдерами (https://doitsmartly.ru/all-articles/sw-testing/120-stakeholders-for-qa.html) и разработки ПО в целом:
1. Требования к разрабатываемому ПО.
Совершенно точно мы должны понимать, что разрабатываем и тестируем, и степень этого понимания необходимо уметь оценить. Потенциальные риски или пропущенные проблемы на уровне спецификации могут привести к самым серьезным и дорогим ошибкам.
2. Качество разрабатываемого продукта.
Тут все очевидно: необходимо иметь возможность оценивать качество разработки и ПО, чтобы делать прогнозы и оценку рисков. Важно понимать, насколько продукт является качественным и надежным, опираясь не только на наличие или отсутствие найденных ошибок, но как раз прогнозируя, много ли потенциальных проблем.
3. Возможности команды QA.
Здесь тоже просто: для того, чтобы управлять процессом тестирования, планировать работы и прогнозировать сроки, требуется всегда иметь не только актуальный статус задач, но и знать возможности команды QA.
4. Качество работы команды тестирования.
Помимо качества самого продукта нужно измерять эффективность самого процесса QA и команды тестирования. Чтобы постоянно оптимизировать и улучшать качество работы, требуется знать, где мы находимся сейчас, что позволяет двигаться вперед, а что отбрасывает назад.
5. Обратная связь и удовлетворенность продуктом.
Последняя область, но, конечно же, не по значимости, а по отзывам стэйкхолдеров процесса, потребителей наших услуг, пользователей продукта. Очень важно иметь возможность измерять общую степень удовлетворенности продуктом, выделять тенденции и делать соответствующие выводы. Правильно подобранные для этой группы метрики позволят вовремя выявить возможные проблемы и оперативно применить обратную связь для улучшения процессов.
Далее рассмотрим, какие именно метрики входят в каждую группу, разберем, как именно их можно оценить. Для каждой группы я приведу несколько примеров возможных метрик и опишу их значение. Более подробно эти и некоторые другие индикаторы QA процесса разобраны в моей статье «Самые важные метрики QA» (https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html).
Группа 1 — Требования к разрабатываемому ПО
Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль.
1. Тестовое покрытие требования
«Общее количество тестов» / «Общее количество требований»
Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.
- Данная метрика будет работать, только если требования хорошо декомпозированы на равнозначные. Иначе она превратится в индикатор наличия или отсутствия тестов для каждого из требований.
- Для требований, у которых коэффициент будет равен или близок к 0, нужно рассмотреть возможность добавления тестов.
2. Степень взаимосвязанности требований
AVERAGE («Количество требований, связанных с требованием №1» / «Общее количество требований -1» ,…, «Количество требований, связанных с требованием №n» / «Общее количество требований -1»)
Метрика вычисляется как количество связей каждого требования с остальными требованиями. При этом используется среднее по всем требованиям значение.
Назначение метрики: дать основание для оценки сроков тестирования и учета возможных рисков. Зная степень взаимного влияния требований друг на друга, можно, например, запланировать дополнительное время и кейсы для сквозного тестирования, проработать регрессионные проверки, посмотреть в сторону интеграции и т.п.
- По своему опыту могу отметить, что приемлемая степень связанности не превышает 0,2-0,3. В ином случае доработка одного из требований будет вести к цепочке переработок, а значит и возможных ошибок в значительной части продукта.
3. Коэффициент стабильности требований
«Количество изменений в существующих требованиях» / «Общее количество требований, реализованных за итерацию, включая новые»
Назначение метрики: показать, как много уже реализованных требований приходится переделывать от релиза к релизу при разработке новых фич. Также метрика дает представление о том, насколько легко масштабируется функционал системы, добавляются новые возможности.
- Для данной метрики коэффициент должен быть как минимум меньше 0,5. В этом случае мы внедряем новых фич в 2 раза больше, чем переделываем существующих. В противном случае команда больше фокусируется на переделывании ранее выпущенных фич, а не на создании новых ценностей для бизнеса.
Группа 2 — Качество разрабатываемого продукта
Данная группа метрик позволяет оценить и сравнить от релиза к релизу как качество ПО, так и качество самой разработки.
1. Плотность дефектов
«Количество дефектов в отдельном модуле» / «Общее количество дефектов в ПО»
Рассчитывается как доля дефектов от общего их числа, приходящихся на отдельный модуль в рамках итерации или релиза.
Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем, а также при анализе рисков.
- Данная метрика поможет обратить наше внимание на проблемный модуль\систему\функциональность, где доля дефектов выше среднего.
2. Коэффициент регрессии
«Количество дефектов в старом функционале» / «Общее количество дефектов, включая новый функционал»
Назначение метрики: показать, на что уходят усилия команды — занимается ли она больше разработкой и отладкой новых фич или основную часть времени тратит на исправления в уже существующих частях ПО.
- Например, если коэффициент регрессии больше 0,5, это значит, что больше половины времени мы тратим на восстановление ранее работавших функций ПО. Такую ситуацию требуется исправлять.
3. Коэффициент повторно открытых дефектов
«Количество повторно обнаруженных дефектов» / «Общее количество ошибок, включая ранее исправленные и новые»
Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля.
- Чем ближе значение коэффициента к 0, тем меньше повторяются старые ошибки.
- При этом, если значение больше 0,2-0,3, это может говорить либо о технической сложности модуля, либо о проблемах в архитектуре, либо о некачественном исправлении ошибок.
Группа 3 – Возможности и эффективность команды QA
Основная задача данной группы метрик заключается в том, чтобы выразить в цифрах, на что способна команда тестирования. Эти показатели можно и нужно рассчитывать и сравнивать на регулярной основе, анализировать тенденции, наблюдая, как на работу команды влияют те или иные изменения.
1. Скорость работы (velocity) команды QA
«Количество story points за N итераций)» / «N»
Рассчитывается как отношение реализованных story points \ требований \ user stories за несколько итераций \ sprints к количеству выбранных итераций.
Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития. Метрика позволяет следить за скоростью работы QA, наблюдать за тем, какие внутренние или внешние воздействия на команду влияют на эту скорость.
2. Среднее время жизни дефекта
«Суммарное время исправления найденных дефектов» / «Количество дефектов»
Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза, к сумме дефектов.
Назначение метрики: показать, сколько в среднем времени уходит на работу с одним дефектом: на его регистрацию, исправление и воспроизведение. Данный показатель позволит оценить время, необходимое на тестирование, выделить области ПО, с которыми возникают наибольшие сложности.
- Время жизни дефекта — это все время от его регистрации до закрытия за вычетом всех возможных приостановок работы. Показывая дефекты с наибольшим временем исправления, метрика позволит выявить особенно сложные и проблемные модули или «слабое звено» в команде разработки.
Группа 4 — Качество работы команды тестирования
Задача этого набора метрик: оценить, насколько качественно тестировщики выполняют свои задачи, определить уровень компетенций и зрелости команды QA. Обладая таким набором показателей, можно сравнивать команду с ней же на разных отрезках времени или с другими, внешними группами тестирования.
1. Эффективность тестов и тестовых наборов
«Количество обнаруженных ошибок» / «Количество кейсов в тестовом наборе»
Назначение метрики: показать, как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.
- Показатель «убойности» тестов позволяет мониторить эффективность каждого из тестовых наборов, как она меняется с течением времени. Это даст возможность вовремя дополнять их «свежими» тестами.
2. Коэффициент ошибок, пропущенных на продуктив
«Количество ошибок, обнаруженных после выпуска релиза» / «Общее количество ошибок, обнаруженных до и после релиза»
Назначение метрики: продемонстрировать качество тестирования и эффективность обнаружения ошибок — какая доля дефектов была отфильтрована, а какая прошла на продуктив.
- Конечно, допустимый процент пропущенных ошибок будет зависеть от многих факторов, однако, если он >0,1, то тут явно есть проблема, ведь в таком случае каждый десятый дефект попал на продуктив и привел к сбоям ПО у пользователей.
3. Реальное время работы команды QA
«Время, потраченное на целевые QA активности» / «Общее количество рабочих часов команды»
Отношение времени, потраченного командой непосредственно на целевые QA активности, к общему количеству часов.
Назначение метрики: во-первых, увеличить точность планирования, а во-вторых, отслеживать и управлять эффективностью работы команды.
- К целевым активностям могут относиться: анализ, дизайн, оценки, тестирование, рабочие встречи и многое другое, к нецелевым — простой из-за блокеров, проблемы в коммуникациях, недоступность ресурсов и т.п.
- Конечно, данная метрика никогда не будет равна 1. Практика показывает, что для эффективных команд ее значение может составлять 0,5-0,6.
4. Точность оценки времени по областям\видам\типам работ
«Оценочное время работы» / «Фактическое время работы»
Назначение метрики: позволяет использовать поправочный коэффициент для последующих оценок.
- Степень точности оценки можно определить для всей команды или отдельных тестировщиков, для всей системы или отдельных модулей ПО.
Группа 5 — Обратная связь и удовлетворенность пользователей
И в заключение, группа метрик, показывающая, как продукт был принят конечными пользователями, насколько он соответствовал их ожиданиям. При этом в рамках оценки взаимодействия с пользователями нам важна не только обратная связь о самом ПО. Еще одна значимая задача этой группы метрик — показать, удовлетворены ли пользователи процессом взаимодействия с командой ИТ в целом и QA в частности.
1. Удовлетворенность пользователей ИТ сервисом
Проводится регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.
Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.
- Метрика может служить индикатором того, что необходимо сфокусироваться на оптимизации процесса или сделать его понятнее и прозрачнее для пользователей.
- Расчет показателя удовлетворенности можно проводить на основе результатов опроса по итогам поставки ПО. Для этого необходимо собрать все оценки и посчитать средний балл.
2. Удовлетворенность пользователей продуктом
Регулярный опрос пользователей о том, насколько они удовлетворены качеством продукта.
Назначение метрики: определить, насколько разрабатываемый продукт соответствует ожиданиям пользователей, в том ли направлении мы движемся, правильно ли определяем важность фич и выбираем варианты решений.
- Для расчета этой метрики также проводим опрос пользователей и вычисляем средний балл. Рассчитывая такой показатель на регулярной основе, можно следить за трендом удовлетворенности пользователей.
3. Вовлеченность стейкхолдеров
Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров.
Назначение метрики: определить степень участия внешних стейкхолдеров (бизнес, инфраструктура, пользователи, поддержка и т.д.) в работе над продуктом. Имея на руках такую метрику, можно сориентироваться, где требуется получить обратную связь, чтобы однажды не столкнуться с проблемами и непониманием.
Павел Новиков,
Program Manager
https://doitsmartly.ru/
Специальность 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
QA engineer, с чего начать?
С чего начать джуниору? Что он должен знать, что уметь, где приобрести необходимые навыки и практику? Как начать построение карьеры в тестировании?
QA (от англ. quality assurance) — обеспечение качества. QA — это довольно абстрактное понятие. Но в основном этот процесс имеет две цели:
- продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;
- выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.
QA — это обеспечение качества продукта, причем, в идеальном случае, на всех этапах разработки. Но в первую очередь это понятие конечно же включает в себя тестирование.
Функциональное тестирование.
В большинстве случаев самое первое, с чем придется столкнуться QA Engineer’у это функциональное тестирование: написание тестов по задачам и прохождение этих тестов., прохождение уже написанных, апдейт, заведение багов и прочее. В этом случае QA Engineer — тестировщик. Для этого самое важное — хорошо работающая голова, умение читать задачи и задавать правильные вопросы: «А что если так? А если этак?».
В зависимости от технологии тестировщику могут понадобятся дополнительные специфические навыки. Web разработка, разработка мобильных приложений, ПО: в каждой технологии свои подводные камни.
Но, процесс обеспечения качества не заканчивается на функциональном тестировании, поэтому понятие QA шире, чем тестирование. Здесь мы уходим от банальных тестов по функциональным требованиям и переходим к анализу требований и документации (поиск узких мест в требованиях и реализации), юзабилити тестирование (поиск «косяков» в интерфейсах и функциональности), тестирование производительности и прочее.
Автоматизированное тестирование.
Автоматизация тестирования — отдельная часть. Здесь от компании к компании все по-разному, и роль автотестера может начинаться с «тестера который научился использовать тестовый фреймворк» и заканчиваться «полноценным разработчиком, который автоматизирует то, что ему говорят тестировщики». Требования отличаются соответственно.
Кроме тестирования, хороший QA инженер работает и над самим процессом разработки. Его цель — обеспечивать качество продукта, и если оно страдает из-за косяков в рабочем процессе — их тоже надо выявить и решить.
QA-инженер — это тестировщик, который вышел в своей работе за рамки тестирования. QA-инженер работает над качеством продукта не только в плане «требования выполнены — к продакшену готовы», а старается делать продукт лучше во всех отношениях. В первую очередь — для бизнеса, во вторую — для пользователя, в третью — для тех, кто этот продукт делает.
Следовательно, путь QA лучше всего начинать именно с тестирования (кстати говоря, в России понятия QA и тестирования почти всегда тождественны в умах нетестировщиков).
Что важно для тестировщика?
- Способность и желание разбираться в том, как это (продукт\фича\пр) работает сейчас, и как это должно работать.
- Так же стоит приготовиться много говорить «нет, так не пойдет» менеджерам и разработчикам.
- Ну и вообще, смириться с тем, что другие стороны процесса очень часто готовы действовать в ущерб качеству.
Требования к джуниору.
- Представление о процессе разработки: этапы, когда нужно начинать тестировать и все такое.
- Представление о написании тестов: что представляет из себя тест-план, тест-сьют, тест-кейс, тест-степ, Definition of Done, ожидаемый результат и т.д.
- Представление о том, что такое дефект: Severity и Priority дефекты, какие бывают дефекты, из чего состоит описание дефекта, и т.д.
- Хотя бы общее представление о тест-дизайне: что это такое, зачем нужено, какие есть практики.
- Базовые навыки (SQL — селект, апдейт, работа с несколькими таблицами).
Дополнительную литературу, касающуюся всех этих навыков и технологий можно найти здесь: https://proglib.io/p/qa-books/
А ещё, конечно, нужно, чтобы человек умел думать. Будьте готовы к задачкам на логику и к задачкам типа «Есть окно с кнопкой, посылает запрос: напиши тесткейсы» или «Протестируй карандаш».