Чем занимается отдел тестирования
Создаем отдел тестирования
Разработка программного обеспечения невозможна без контроля качества, а в этом ключевую роль играет процесс тестирования. Надо заметить, что тестирование ‒ это не единственная и тем более не достаточная мера для создания качественного ПО, но совершенно необходимая.
Что такое тестирование? Упрощенно, это процесс проверки того, что программа соответствует всем поставленным требованиям. Еще более упрощенно ‒ тестирование есть поиск ошибок. При этом обычно программа рассматривается как “черный ящик”, и проверка производится многократным запуском с разными исходными данными и в разных условиях.
Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования. Перекладывание функций тестировщиков на разработчиков, бизнес-аналитиков или даже менеджеров ‒ путь неэффективный. В этой статье мы расскажем, как можно построить отдел тестирования.
Глоссарий
Тест-кейс ‒ шаги по достижению ожидаемого результата.
Тест-план ‒ запланированные и назначенные тест-кейсы.
Прогон ‒ выполнение тест-плана.
Регрессионный тест ‒ тест старого функционала программы, работоспособность которого могла быть нарушена после внедрения новых функций.
Самое важное ‒ найти правильных людей. Первое, с чем вы столкнетесь ‒ на тестировщиков у нас не учат, и найти человека не так уж просто. У вас два пути: “сделать тестировщиком” кого-то из ваших сотрудников или нанять со стороны человека в опытом работы.
Определенно, человек из компании уже знает особенности вашего продукта, требования клиентов и коллектив (это тоже важно). Вероятно (если вы уж занимаетесь разработкой), что кто-то из программистов свой код все же тестировал и кто-то это делал лучше и более тщательно, чем другие?
Однако, хотя переход из программистов в тестировщики возможен, никак нельзя быть уверенным, что ваши сотрудники, которым нравится своя работа, согласятся полностью посвятить себя тестированию. Я бы предположил, что они вообще не будут в восторге от такого предложения — слишком разные это профессии. Поэтому, найм со стороны также рассматривайте.
Хороший тестировщик — это не просто “выполнятель тестов”, это тот человек, который будет каждый день использовать ваш продукт и быть самым преданным его пользователем. А иметь такого человека в команде — многого стоит.
Планирование времени
Тестирование ‒ это трудоемкий и затратный по времени процесс. Один прогон регресс-тестов чего стоит! Поэтому при тестировании крайне важно планирование времени. Например, проектов у вас много, а отдел тестирования ‒ только один. Возникает много проблем при одновременных релизах.
Для решения очень удобно использовать google-календарь (про использование сервисов google я как-то уже писал), то есть создать календарь, в который можно вносить планируемые релизы, и расшарить его менеджерам и тестировщикам. Можно просматривать даты релизов и в системе управления проектами, например, Redmine, но наиболее наглядно использовать единый календарь для планирования.
Тестирование ‒ это учет и контроль
Ручное тестирование
Ручное тестирование — это то, с чего все начинается. Тесты выполняются вручную, без использования особых средств автоматизации (за исключением TMS). Тестировщик обычно просто следует заранее написанному плану действий, фиксируя результат — было ли поведение ожидаемым, или нет (в этом случае записывается, что пошло не так).
В большинстве случаев, ручное тестирование — это функциональное тестирование, а также тестирование на программную и аппаратную совместимость. Ручное тестирование наиболее распространено для проверки пользовательских интерфейсов — здесь автоматизация иногда экономически неэффективна или вообще невозможна.
Сотрудника на ручное тестирование следует искать кропотливого, пытливого и терпеливого, который “на ты” с объектами тестирования — сайтами, мобильными устройствами, SmartTV и т.п.
Автоматизированное тестирование
Потребность в автоматизированном тестировании возникает, когда проект уже большой и ведется его активное развитие. Чтобы не тратить время на ручной прогон тестов, которые приходится выполнять очень часто, можно использовать автоматизированное тестирование.
Часто под автотестами понимают только юнит-тесты, хотя автоматизировать можно практически любой вид тестирования. Мы считаем, что любое тестирование кода по принципу “белого” или “серого ящика” — это задача разработчика, а не тестировщика, поэтому здесь организацию юнит-тестирования рассматривать не будем.
Инструментарий для автоматизации ручного функционального тестирования достаточно широк. Мы сами используем Selenium для тестирования веба.
Часто бывает так, что затраты на поддержание автотестов значительно превышают затраты на ручное тестирование. Поэтому надо действовать без фанатизма.
Требования к сотруднику практически такие же, как к программисту-администратору. Почему администратору? Потому что автотестирование тесно связано с релиз-инжинирингом.
То есть мы, как правило, либо собираем пакеты для тестирования, либо выкатываем релиз в тестовое окружение (staging environment или “карантин” в нашей терминологии). В определенный момент мы приходим к тому, что надо минимизировать время тестирования перед релизом.
Нагрузочное тестирование
Тестирование отказоустойчивости
Вам понадобится этот вид тестирования, как только вы начнете строить отказоустойчивые системы (например, с резервированием элементов или с graceful degradation). Печальный опыт показывает, что при отказе одно элемента в таких системах падает вообще все поведение других элементов труднопредсказуемо.
Как мы проводим тест отказоустойчивости? Анализируем техническую структуру проекта, тщательно планируем действия и в часы наименьшей загрузки выводим некоторые элементы системы из работы, изучаем последствия, вносим улучшения и корректировки. Потом повторяем.
«Нужно быть ленивым, чтобы стать хорошим тестировщиком»
С тестированием связано много стереотипов: к нему относятся как к быстрому старту в IT с перспективой высокой зарплаты, но не видят в этом серьезной профессии. Кажется, что тестирование — сплошная рутина, где нет места творчеству и реализации собственных идей.
Вместе с руководителем отдела QA/QC в Redmadrobot и куратором нашего курса Software Testing Marishunya_QA мы разобрались, какими навыками нужно обладать тестировщику, куда можно развиваться в тестировании, с чем на самом деле связана текучка кадров и почему даже хорошим программистам не следует брать на себя обязанности тестировщика.
Чем занимается отдел тестирования?
Многие говорят, что тестировщик должен «сломать продукт» — найти уязвимость, которая сделает использование приложения невозможным. Это в корне неверно. Тестировщик должен рассмотреть систему со всех сторон, подумать, как может себя повести приложение в различных ситуациях, проверить «защиту от дурака» — что будет, если ввести вместо фамилии числа, например.
Если говорить о мобильных приложениях, многим кажется, что тестирование ограничивается поворотом экрана, то есть стандартными сценариями использования. Инженер в процессе тестирования задается вопросом: «На что новая фича может повлиять? В каких ситуациях что-то может пойти не так?». Возьмем интернет-магазин: программист реализует функцию скидки по промокоду. Если он станет сам проверять, то войдет в корзину, допустим, через главное меню — убедится, что все работает, и не подумает, что это можно сделать еще тремя способами, для которых тоже надо прописать вызов функции. Тестировщик же должен идти по пути всех пользователей, написать тест-кейсы по нескольким сценариям и потом к ним возвращаться. Поэтому отдел тестирования сопровождает продукт на всем протяжении его разработки и находится в центре V-образного жизненного цикла программного обеспечения.
Тестировщик должен знать бизнес-требования и технические нюансы, поскольку тестирует как спецификации, так и use cases; ему также нужно наравне с другими членами команды выставить свои оценки, чтобы правильно спланировать delivery, иногда пнуть разработчика, потому что в конце спринта project-менеджер придет в отдел QA/QC, чтобы спросить протестировано ли приложение.
Тестировщик может затрагивать все проектные роли и должен уметь доказать каждому участнику, почему необходимо закрыть тот или иной баг или вообще отложить релиз. Грамотный и опытный специалист, с самого начала принимающий участие в разработке приложения, еще на этапе согласования работ может сократить время на стабилизацию продукта, а значит — снизить цену ошибки. Если тестировщики еще на этапе ревью заметят ошибку в тексте, то стоимость ошибки — час работы аналитика, чтобы дописать пару строк. Когда ошибки находят уже на этапе сборки, то надо просить аналитика переписать, разработчика переделать, а тестировщиков перепроверить — это уже день работы и перенос релиза или вообще исключение фичи из релизной сборки
QA и QC: в чем разница?
В России путают понятия Quality Assurance (обеспечение качества) и Quality Control (контроль качества). Часто можно встретить схематичное изображение, где внутри QA находится QC, а внутри QC — само тестирование.
Гораздо правильнее изобразить так:
На самом деле QA и QC — разные вещи и они идут параллельно друг другу. Простому тестированию, грубо говоря, можно научить практически любого: посадить за стол, дать бета-сборку приложения и сказать: «Проверь, как это работает». QC — это инженер, который знает подходы, видит продукт вживую, разрабатывает стратегию тестирования и знает основные принципы, то есть контролирует качество самого продукта. QC работает непосредственно с разработчиками, составляет базу кейсов и организует тестирование.
QA — человек, который обеспечивает качество не на уровне выпускаемого продукта, а всей компании в целом, то есть отвечает за процессы и обеспечивает условия для правильной работы QC, координирует отделы по ряду продуктов и составляет планы тестирования. Ответственность QA начинается с переговоров с заказчиками, работы со смежными отделами и выстраивания взаимодействий, продолжается в процессе разработки и заканчивается уже на презентации продукта. Она затрагивает не только технические, но и юридические аспекты. В компании все отделы сами по себе могут работать хорошо: сейлзы продают, программисты кодят, project-менеджеры контролируют процессы. Однако, чтобы механизм действовал без пробуксовок, взаимодействие отделов между собой было четким, а на выходе получался первоклассный продукт, нужно обеспечение качества — это и есть Quality Assurance.
Как стать тестировщиком?
Никаких специальных факультетов или направлений в области тестирования в российских университетах на сегодняшний момент нет, поэтому и для кандидатов каких-то требований в плане образования не предъявляется, хотя наличие технической или кибернетической специальности будет большим плюсом.
Чаще всего в вакансиях для тестировщика можно встретить следующие требования:
Главное требование к кандидату — мыслить алгоритмами и системами. Желательно иметь какой-то технический бэкграунд и знать теорию. Что такое testing, QC, QA и чем они отличаются? Какие есть виды тестирования и как их комбинировать? Что такое тест-дизайн, тест-кейс, тест-план? Надо знать хотя бы один объектно-ориентированный язык программирования, основы баз данных, клиент-серверной архитектуры и работы в различных ОС.
Если раньше с этим были проблемы, то сейчас в интернете полно специализированных ресурсов, как например форум на Software Testing. Если говорить о книгах, то ниже список литературы:
«Обеспечение и контроль качества — что-то новое для России. Проблема состоит в непонимании цели и задачи тестирования в целом. Создают отдел, но что с ним делать, не знают. Нет четко поставленной задачи, из-за чего отсутствует мотивация работать на результат. Семь лет назад я начинала работать в тестировании в Украине и сейчас я сталкиваюсь с таким же непониманием, с каким встречалась тогда. В России большая часть заказчиков — госсектор и банкинг со своей тяжелой и неповоротливой бюрократией. В Украине же на них приходилось только около 20% рынка, все остальные — частные компании, которые умеют считать свои деньги».
Марина Куликова, Head of QA/QC, Redmadrobot
Как быть тестировщиком?
Войти в профессию просто, а вот расти и развиваться дальше намного сложнее. Если сравнивать тестировщиков с программистами, то последние по ходу своей карьеры уходят «вглубь». Тестировщик же находится в центре цикла жизни продукта, поэтому ему необходимо видеть картину в целом, иногда перехватывать функции project-менеджера и заниматься продуктовой аналитикой, то есть развиваться «вширь». Тестировщик получает много навыков из смежных направлений, зачастую плохо понимает масштабы своей области, смотрит по сторонам и уходит во что-то другое: программирование, product owner или аналитику. В итоге специалисты в области тестирования часто меняют профессию, а отделы QA/QC страдают от нехватки высококвалифицированных кадров.
Хотя тестирование — действительно интересная отрасль, где творчества порой не меньше, чем в самой разработке. Тестировщику часто приходится работать при нехватке входных данных, в условиях жестких спецификаций или строгих требований заказчика, не говоря уже о том, что иногда нужно самому «руками» залезть в код. Вырастая до руководящих должностей, нужно много общаться как с другими отделами, так и с заказчиками, доказывая свою точку зрения со стороны QA.
Больше узнать о тестировании и получить практический опыт вы сможете на нашем курсе Software Testing, где Марина Куликова расскажет о техниках тест-дизайна и как обеспечить качество вашего ПО в любых условиях.
Как мы в Azoft проводим тестирование программного обеспечения
Время чтения: 4 минуты
Отправим вам статью на:
Отказ от тестирования — это риски, которые трудно просчитать. Найденные после релиза баги могут отпугнуть пользователей, а вы потеряете время и деньги. Со стороны это не всегда очевидно, но контролировать качество продукта важно. Для этого существует отдел тестирования.
Мы вспомнили три наших крупных проекта и на их примере рассказываем, чем именно занимаются наши тестировщики.
Первый проект: Android-приложение для логистической компании СДЭК. Второй: информационная система для тематического парка развлечений Любогород. Третий проект: конструктор сайтов для интернет-провайдера Электронный Город.
Как работает отдел тестирования
Отдел тестирования начинает работать, когда клиент присылает требования к проекту или его части, за которую мы отвечаем. Перед тем как тестировать проект, тестировщики анализируют документацию, уточняют требования и участвуют в обсуждениях по ходу разработки.
Мы используем связку из функционального и нефункционального тестирования. Каждый проект проверяем на соответствие требованиям и документации. Отдельно смотрим вёрстку и удобство использования (usability).
Функциональное и нефункциональное тестирование начинаются, когда часть функционала уже разработана. Рассмотрим на практике.
Проверка требований и составление тестовой документации
Как правило, мы тестируем проекты, которые разрабатываем. Требования для таких проектов передаёт заказчик или собирает наш отдел аналитики.
На первом этапе отдел тестирования изучает и уточняет эти требования. Важно убрать противоречия, а также сделать требования однозначными и полными.
Мы определяем инструментарий и стратегию тестирования, чтобы составить тестовую документацию. В случае с проектами для Любогорода и СДЭКа это были чек-листы, но мы используем и другие виды документации. Её содержание и формат зависят от проекта, его особенностей, пожеланий заказчика.
Сначала мы проясняем требования, потом пишем документацию. Иногда выполняем эти действия параллельно. Например, для СДЭКа и Любогорода мы прояснили требования при составлении тестовой документации.
Тестирование
Обычно мы не ограничиваемся одним видом тестирования в процессе работы. Стараемся проводить комплексные проверки с комбинациями различных техник и подходов.
Функциональное тестирование
Все три проекта мы тестировали по чек-листам. Записывали, что проверяем, какие данные вносим и какое поведение ожидаем.
СДЭК мы тестировали и по юзкейсам. Это сценарии, по которым юзеры будут пользоваться приложением. Чтобы сделать юзкейсы наглядными, мы использовали XMind. Так мы визуализировали поведение системы и логику переходов.
В процессе тестирования мы просматриваем базу данных проекта и вносим изменения. Тип БД определяет клиент, который будем использовать. Например, на проекте для Любогорода использовали HediSQL — клиент для MySQL.
Нефункциональное тестирование
Вёрстку на мобильных проектах проверяем на различных операционных системах, версиях ОС и мобильных устройствах с различными разрешениями экрана. Веб-приложения тестируем в разных браузерах и на разных операционных системах.
Для тестирования вёрстки мы обычно используем Developer Console в Chrome и Firefox Firebug Console в Firefox.
Мы всегда проверяем, что проект соответствует дизайну и макетам. Кроме этого мы сверяемся с руководствами Apple и Google по пользовательскому опыту и интерфейсу. Опыт тестировщика тоже важен: он может указать на ошибки в UX и помочь их исправить.
Для СДЭКа и Любогорода мы делали тестирование взаимодействия. Проверяли, как компоненты ПО взаимодействуют друг с другом, а разрабатываемая система — с другими системами.
В мобильных проектах мы часто тестируем API. Так можно проверить работу интерфейса взаимодействия в начале разработки проекта или отдельной фичи. Для этого в проектах для СДЭКа и Любогорода мы использовали Postman.
На всех трёх проектах нужно было убедиться, что взаимодействие сервера и клиента реализовано верно. Чтобы просматривать, перехватывать и редактировать запросы между сервером и клиентом мы использовали Fiddler. Так мы проверили, что на стороне клиента данные отображаются корректно.
Дополнительные виды тестирования
В зависимости от проекта мы можем проводить другие виды тестирования. Например, если на проекте ожидается большой трафик, клиент выставляет требования к выдерживаемой нагрузке, то мы проводим нагрузочное тестирование.
Мы проводили нагрузочное тестирование на проекте для Электронного Города. Для начала выяснили, какие сценарии использования будем тестировать. Нужно было проверить, выдержит ли главная страница большой трафик.
Чтобы протестировать необходимый сценарий, мы использовали Jmeter. Это инструмент для performance-тестирования от компании Apache. Мы подготовили тестовую среду, разработали сценарии в Jmeter и реализовали параллельный запуск на нескольких удалённых машинах.
Затем запустили тестирование и вместе с разработчиками следили за состоянием системы под нагрузкой. Для мониторинга использовали Zabbix. Искали ошибки, оптимизировали систему и тестировали по новой, пока результат не начал соответствовать заявленным требованиям. Результаты тестов мы сформировали в отчёт и предоставили заказчику.
По итогам функционального и нефункционального тестирования мы завели задачи в таск-трекере. Там же описали баги и предложили улучшения.
Верификация устраненных дефектов и приемка
На следующем этапе мы проверяем, что все найденные баги устранены, а новых не появилось. Затем проверяем функционал, который могли затронуть при устранении дефектов.
Перед тем как сдать проект, мы проверяем работоспособность системы. Для этого проводим приёмочное или смоук-тестирование.
Приёмочное тестирование помогает убедиться, что основной функционал системы работает и результат работы соответствует ожидаемому результату. Например, что критичные для бизнеса требования выполняются, а кейсы реализуются успешно. Смоук-тестирование подтверждает, что после сборки кода основные функции системы работают исправно.
Заключение
Вы узнали про основные этапы тестирования в нашей компании. Виды тестирования, которые мы применяем, часто различаются. Кроме тех, которые описаны в статье, мы выполняем тестирование безопасности, исследовательское, автоматизированное и многие другие.
Если вы заказываете у нас разработку, наш внутренний отдел тестирования будет заниматься проектом. Не потребуется дополнительно отдавать контроль качества на аутсорс и ждать, пока подрядчики вникнут в детали проекта.
Подпишитесь
Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.
Тестирование ПО: суть профессии, требования и заработная плата
Разработка программного обеспечения — сфера, которая будет в ближайшее время только расти, несмотря ни на эпидемию, ни на экономический кризис. Соответственно, будет увеличиваться дефицит технических специальностей, связанных с разработкой.
Одна из них — тестирование ПО. Забегая наперед, скажем, что в тестировщиках нуждаются практически все компании, которые занимаются созданием программного обеспечения и сервисов. Что касается порога входа, требований, которые предъявляются к разработке ПО и размере заработной платы тестировщиков, то в этом вопросе поможет разобраться преподаватель курса GeekBrains «Тестирование ПО» Максим Засецкий.
QA, QC и тестирование
Тестирование программного обеспечения — обширное понятие, которое включает планирование, проектирование и, собственно, выполнение тестов.
Из чего состоит сфера тестирования ПО
QA (Quality Assurance) — обеспечение качества продукта. QA-специалист контролирует и обеспечивает качество работы продукта компании. Он отвечает и за отдельные этапы разработки софта. В частности, за выбор инструментов для разработки, предотвращение возможных проблем. Еще он участвует в процессе совершенствования продукта. QA охватывает все этапы разработки, включая описание проекта, собственно, тестирование, релиз и, зачастую, пост-релизный этап.
QC (Quality Control) — контроль качества продукта. Задача QC-специалиста — проверка конкретного продукта, что включает анализ кода продукта, дизайна, плюс тестирование. QC-инженер разрабатывает стратегию тестирование вполне определенного тестирования, взаимодействует с разработчиками и организует само тестирование.
Специалист по тестированию занимается выполнением тестов. Тестированием называют проверку соответствия результатов работы программного продукта на соответствие заданным критериям. Тестировщики занимаются тестированием всего продукта в целом или же отдельных компонентов. Тестирование играет важнейшую роль в обеспечении качества продукта.
Кстати, есть внешнее ответвление — современное направление тестирования Developer in test. Специалисты этого направления — вроде как и разработчики, но занимаются они обеспечением качества разрабатываемого продукта.
Что должен знать и уметь хороший тестировщик?
Исходя из всего, что сказано выше, сложно выделить конкретные знания или умения. Все сильно зависит от проекта, на котором работает специалист, соответственно, и от стека технологий, которые на этом проекте используются.
Если говорить о джуниорах, то здесь можно выделить общие навыки:
Хорошие знания в клиент-серверной архитектуре.
Хороший тестировщик должен понимать механизм взаимодействия веб-приложений, уметь локализовать проблему вне зависимости от того, возникла ли она на фронтэнде или бэкенде.
Специалисту необходимо иметь базовые навыки использования специализированного софта, уметь использовать инструменты devTools, иметь представление о работе снифферов, знать базовые команды консоли Windows.
Крайне важны soft-скиллы:
Умение общаться с коллегами.
Умение ясно излагать мысли.
Способность четко описать проблему разработчику.
Умение работать с документацией.
Понимание стандартов разработки ПО.
Готовность доказать и отстоять свою позицию, основываясь на документации или здравом смысле.
Существует мнение, что профессионалом в сфере тестирования можно стать через 3 года, при условии наличия технического бэкграунда. В первый год молодой специалист начинает понимать, что от него требуют, во второй год — понимает, как нужно выполнять то, что от него требуют, на третий — пытается улучшить выстроенный процесс, добавляя свое видение.
Что касается тестировщиков с большим опытом и обширными знаниями, то им крайне необходимо постоянно расширять навыки, следить за тенденциями в мире IT, искать новые подходы к решению вчерашних задач и всегда быть «на волне».
В разных компаниях требования к тестировщиком отличаются. Кому-то нужны Developer in test, а для кого-то важнейшую роль играют софт-скиллы специалистов.
Мифы о тестировании ПО и тестировщиках
Почему-то все более распространенным становится заблуждение, согласно которому тестировщики занимаются тем, что просто нажимают на кнопки и вводят рандомную информацию в разные поля программы. На самом деле это не так, если бы тестировщики хаотично нажимали на кнопки и вводили случайные данные, то результаты тестирования никакой ценности для разработчика не принесли бы. Результаты представляли бы собой неструктурированную информацию из которой невозможно получить представление о том, насколько качественным получился продукт и насколько удобен он для пользователей. У тестировщиков всегда есть стратегия работы, план, который позволяет получить объективное описание актуального состояния продукта.
Второй миф заключается в утверждении, что тестировщики ответственны за качество ПО. На самом деле, ответственность за качество разработки продукта несет вся команда. Тестировщики же помогают улучшать качество разработки, а также выявляют проблемы на ранних стадиях.
Третий миф — тестировщиков очень много. На самом деле хороших специалистов на рынке мало. Много тех, кто выкладывает резюме с пометкой «тестировщик», не понимая сути тестирования ПО.
Востребованность профессии и доходы тестировщиков ПО
По данным зарплатного калькулятора Хабр Карьеры, средний размер заработной платы тестировщика составляет чуть больше 96 тысяч рублей в месяц. Конечно, это среднее значение. Есть те, кто зарабатывает значительно меньше, скажем, тысяч 30, а есть и те, кто получает в 10 раз больше — около 300 тысяч рублей.
Средняя з/п тестировщика ПО в первом полугодии 2020 года
Профессионалы примерно одного уровня, выполняющие один и тот же пул задач в столице и в регионе могут получать сильно отличающуюся зарплату. В Москве это 100+ тысяч рублей, в регионах — 40-50 тысяч рублей, а в некоторых случаях и вовсе 20-30 тысяч.
Если сравнивать уровень зарплаты тестировщиков в РФ и за рубежом, то разница в среднем 30-50%.
Источник картинки https://habr.com/ru/post/446650/
Плюс можно сравнить еще разброс уровня заработной платы в зависимости от региона — Евросоюз, СНГ, США и Канада, РФ.
Источник картинки https://habr.com/ru/post/446650
Наш зарплатный калькулятор показывает и список навыков, которыми владеют тестировщики ПО: