Тестирование в IT - это просто.

Для желающих приобщиться к IT технологиям калитка стать тестировщиком считается открытой для всех желающих. Давайте разбираться в чем состоит работа тестировщика.

Про термины.

Что такое тестирование? Тестирование - это процесс проверки соответствия поведения программы с требованиями к ней.

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

Баг (bug) - факт несоответствия поведения программы с требованиями к ней.

Тестовый стенд - совокупность аппаратуры, софта и определенных настроек для тестирования продукта.

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

Тест-план - набор тест-кейсов для выполнения цикла тестирования. Например: регрессионный тест-план, предрелизный тест-план, релизный тест-план, приемочный тест-план, дымовой тест-план. После выполнения тест-плана и получения по нему отчета руководство проекта обычно принимает решение о успешности этапа разработки проекта или неуспешности.

Тестировщик - отрицание.

Для начала давайте определимся - в чем состоит основная работа тестировщика?

Он тестировщик, значит тестирование! Нет.

Он тестировщик, значит в поиске багов! Нет.

Эээ… получить безглючный продукт? Это цель, это не основная работа.

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

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

Описание развертывания тестового стенда должно быть:

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

Сложность стенда тестирования зависит от сложности продукта, можно выделить несколько семейств продуктов: сетевая инфраструктура, серверные приложения, десктопные приложения, веб-приложения. Тестовый стенд для каждого из них отличается. Наиболее сложный - продукт сетевой инфраструктуры. Необходимо в виртуальной среде развернуть несколько виртуалок и объединить их в подсеть. После чего проверить, что все правильно на каждой виртуалке. Как это сделать, если виртуалок 400? Правильно, программой и выгрузкой ее работы в лог, 400 логов собираем, объединяем, получаем статус от каждой виртуалки. Насчет 400 я приврал конечно, но 10-15 виртуалок легко могут использоваться.

Поэтому - развертывание тестового стенда это основная часть работы тестировщика.

Тестировщик - гнев.

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

Тестировщик - торг.

Общий алгоритм работы тестировщика следующий:

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

Тестировщик - депрессия.

Разделяют несколько подходов к тестированию продукта, даже не подходов, а процессов. Это: QA - Quality Assurance, QC - Quality Control и Testing. В чем отличия? Кем я хочу стать? Кто из них тестировщик?

Quality Assurance (обеспечение качества) - ставит целью выпустить продукт максимального качества с момента начала разработки и до выпуска продукта затрагивая все аспекты разработки.

Quality Control (контроль качества) - продукт уже есть, надо измерить его качество.

Testing - процесс проверки качества продукта, разработки тест-кейсов и планов тестирования с оценкой охвата тестирования. Этот процесс является частью вышестоящих QA и QC.

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

Тестировщик - принятие.

Основные аспекты работы я описал. Что еще осталось? На самом деле не очень мало.

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

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

Автоматизация - даже без полноценного подхода к автоматизации тестирования это не пустой звук. Работа тестировщика не простая, нужно всегда много держать в голове, выполнять много работы руками, это все тяжким грузом оседает на подсознательном уровне и рано или поздно тестировщик понимает, что занимается совсем не тем. Допустим: есть кейс для проверки корректности логина в систему, в тест-кейсе представлен набор логин и пароль из 10 примеров, их нужно ввести по очереди и получить уведомление от системы, где логин прошел, а где нет. После чего написать отчет. Вроде все просто. Время на этот кейс - 30 минут. Продукт собирается каждую ночь, этот кейс входит в план дымового тестирования, т.е. выполняется на каждой версии в первую очередь. Сколько хватит тестировщика и когда он всех пошлет, чтобы сбежать от такой работы. 10 раз можно выполнить этот кейс, а 100? А если проект на много лет? Поэтому я считаю, что любому тестировщику нужна отдушина. Автоматизация его труда является прекрасной отдушиной. Берем и замеряем время на выполнение задач, разбиваем на типы работ: подготовка стенда, ознакомление с тест-кейсом, выполнение, оформление багов, написание отчета. Подготовка стенда много времени занимает - отлично, автоматизируй это! Не знаешь как? Встречи команды бывают? Обозначь вопрос и тебе подскажут или даже помогут это сделать. И так далее маленькими шажками оптимизируй работу и потом ты уже не думаешь, что завтра с утра надо опять этот кейс с логинами проходить, а думаешь как тебе разрешение экрана в Windows автоматически менять для проверки работы продукта или по сигналу правого глаза отключать сетевую карту ровно на 5 секунд. В любом, даже в самом технологически развитом болоте все чахнет и стоит привнести в этот мир немного красок и света как все налаживается.

Основные методы тестирования:

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

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

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

модульное тестирование (unit-test) - тестирование отдельных функций в коде, пишется программистами.
интеграционное тестирование - тестирование цепочки модульных тестов или проверка интерфейсов, пишется программистами. Активно используется как отдельная функциональность на серверных продуктах.
регрессионное тестирование - тестирование старой функциональности после ввода новой. Мы не сломали, что у нас работало до этого.
нагрузочное тестирование - замер экстремальных показателей продукта и сохранение результатов. В последующем результаты анализируются, чтобы выяснить с какого момента стало лучше/хуже и что именно надо править. Стенд должен быть развернут на реальном железе без виртуалок.
системное тестирование - проверка работы программы на системе с разной конфигурацией, чтобы выяснить какое оборудование продукту нужно для штатной работы. Системное тестирование выполняется без виртуалок на реальном железе.
предрелизное и релизное тестирование - проверка работы продукта для присвоения версии релиз кандидат или релиз. Отчет по тестированию анализируется руководством проекта для принятия решения - можно ли присваивать продукту статус релиз кандидат или релиз.
приемочное тестирование - проверка готовности продукта к началу продаж, отправляется менеджеру продукта с рекомендацией выпустить данную версию продукта в продажу. Менеджер продукта по своей цепочке пропускает этот отчет и если получает от всех “добро” - продукт в продаже.

Должности и обязанности в тестировании.

Тестировщик - специалист выполняющий работу по сценариям тестирования с последующим отчетом и регистрацией багов.

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

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

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

Есть еще разные направления тестирования, допустим: тестирование локализаций продукта на разные языки, тестирование документации, нагрузочное тестирование. В таких случаях, тестирование проводят не тестировщики, а технические писатели в случае локализаций и документации и исследователи в случае нагрузочного тестирования.

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

Интересные баги из практики.

логи и ненужная информация: регистрация в логе токена для логина в продукт, регистрация логина и пароля в открытом виде - один раз понадобилось программисту убедиться, что он правильно все присваивает и вот, убрать то это он забыл. Как это еще код-ревью прошло - никто не знает. Логам стоит уделять отдельное внимание, там можно много интересного найти. Да, если при работе программы лог разрастался и заканчивалось место на диске - продукт падал.
для установки продукта надо 115 мб. пространства, оставляю ровно 115 мб., ставлю продукт, устанавливаю защитный ключ - продукт падает с ошибкой. Отметка об успешной установке продукта есть, продукт не работает, компьютер заблокирован.
продукт устанавливается на медленную виртуалку (1 гб память, 1 ядро, Windows 8.1). Статуса успешной установки нет, установщик прекращает работу без сообщений об ошибке. В дальнейшем, все работает нормально, но статуса то нет. Проблема была в команде sleep(1000); Установка происходила в другом потоке и по окончанию поток не успевал закончить работу (медленная виртуалка), программист посчитал, что секунды ему должно хватить, а это не так. В результате статус не записывался, т.к. корневой поток заканчивал работу раньше вспомогательного.

Всем удачи!