С чего начинается тестирование
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализом результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Пример таблицы принятия решений
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.
Как научиться тестировать ПО
Считается, что через тестирование можно легко зайти в ИТ. Мы спросили наших специалистов по тестированию, как это реализовать без поступления на профильные программы обучения в вузы. Оказалось, что можно ограничиться базой по информатике, одной книжкой по тестированию и правильным выбором, где получать первый опыт. Правда, приправить это надо собственной заинтересованностью и усердием.
Под катом — наши советы и ответы на распространенные вопросы новичков. Есть немного и о том, куда двигаться дальше, когда кажется, что потолок знаний близко.
Нужна ли тестировщику база в ИТ?
Откровенно скажем, желательна.
Большинство наших специалистов в той или иной форме увлекались ИТ с детства или как минимум учились в профильных вузах, т.е. уже имели какую-то базовую подготовку еще до прихода в тестирование. Часть из них начинали как разработчики (учились на разработчика) — отдельные “тестовые” направления еще лет 10 назад отсутствовали. Так что у нас перед глазами просто нет “антипримера” такого пути.
Сейчас в ИТ действительно много тех, кто такую подготовку не проходил. И им немного сложнее двигаться вперед. Чтобы справиться с задачами в тестировании, необходимо как минимум уметь поставить операционку, понимать, как развернуть тестовое приложение и необходимое окружение, как создать репозиторий в Git, погуглить ответы на свои вопросы, покопаться на специализированных ресурсах вроде Stackoverflow. По сути это и обеспечивает общая база по информатике.
Но и эти знания вполне можно освоить по книгам или курсам в интернете. Сегодня недостатка в источниках информации нет. Главное, чтобы была заинтересованность и время, которое можно на это выделить.
В тестировщики или в разработчики?
Тестирование тестированию рознь.
Требования к начинающему ручному тестировщику не очень высоки. Пожалуй, это и есть та самая “легкая дорога в ИТ”. Здесь нужно знать базовые принципы тестирования, о которых мы поговорим чуть позже, и иметь упомянутую выше базу. Правда, от ручных тестировщиков постепенно уходят, чтобы проверять программные продукты быстрее и эффективнее. Поэтому так или иначе со временем все “ручники” начинают писать код или заниматься метриками и анализом. Но это не значит, что нельзя начать свою карьеру в статусе джуна-”ручника”.
Автоматизатор тестирования уже ближе к разработчику. В базе знаний у каждого автоматизатора обычно значится как минимум один язык программирования — тот, на котором ведется разработка автотестов (это не всегда основной язык разработки на проекте). Занимаясь автоматизацией, также важно знать шаблоны проектирования и уметь применять общие принципы разработки — расширяемость, читаемость, легкость переиспользования. По сути автотест — это та же программа, которая должна соответствовать заранее заданному сценарию.
Чтобы начать работать автоматизатором, помимо знаний о тестировании в целом, необходимо иметь минимальные знания в объектно-ориентированном программировании, представлять, как написать простейший “Hello World!”.
Выбирая направление, вряд ли стоит смотреть на сиюминутную популярность специалистов на рынке труда. Средние показатели спроса и зарплат в ИТ — вещь очень специфическая, они зависят в том числе и от смежных знаний. Кто бы мог подумать, но специалисты по разработке на каком-нибудь Delphi сейчас в банковском секторе востребованы, несмотря на то, что в других отраслях язык не пользуется вообще никаким спросом. Здесь все работает по законам рынка: специалистов мало, а спрос на них остался, поскольку кому-то же надо поддерживать легаси.
Так и в тестировании. Сейчас есть спрос на JS-автоматизаторов. Он велик, потому что запросы у бизнеса большие, но еще не успели выучиться те люди, которые встали на данный путь с первым появлением интереса рынка. Как только они выучатся и пойдут работать, ситуация может измениться.
В этом изменчивом мире именно базовые знания — понимание, что и как тестировать в принципе, какие бывают подходы, — а также умение быстро усваивать информацию помогут быстро переориентироваться на смежный стек технологий.
Что почитать?
Тестирование, да и ИТ в целом, — бурно развивающаяся отрасль, поэтому часто можно встретить скептическое отношение к книгам. Слишком уж у них велик “цикл производства”. Писать, издавать, распространять — долго. Он растягивается более чем вдвое, если мы говорим о переводной литературе.
Однако одну книгу наш отдел тестирования рекомендовал почти единогласно — “Тестирование Дот Ком” Романа Савина. Это самая известная книга по теме, которая просто и доступно вводит в курс основных понятий и процессов в ручном тестировании. И хотя она издана довольно давно, базовые знания, изложенные в ней, до сих пор актуальны. Пожалуй, ее читали процентов 80 всех тестировщиков в странах СНГ.
Другие рекомендации легко найти в распространенных в интернете “списках N книг для начинающего тестировщика”. Но в целом наша команда тестирования считает, что базы из книги Романа Савина будет достаточно для запуска дальнейшего процесса самообразования.
Стоит ли идти на курсы, тем более платные?
Мнение о курсах у наших специалистов неоднозначное.
Любые учебные программы полезны тем, что они дают сразу много информации в структурированном виде. Информация собрана в удобные для освоения фрагменты, разделена по этапам. Уровень за уровнем можно идти по учебной программе, как в игре, и получать полезные знания.
Идти на курсы можно с одной из двух целей — либо закрыть какие-то пробелы в знаниях, либо закрепить уже известную информацию. В зависимости от целей усваиваться все будет по-разному. Но из-за обилия новых знаний осядет далеко не 100% полученной информации. С этой точки зрения самостоятельное обучение на конкретном проекте полезнее. Собранные сведения или найденный ответ точно задержатся в голове. Правда, на это уйдет немного больше времени.
Не все стены стоит пробивать своим лбом. И правильный баланс, где стоит послушать лектора на курсах, а где — попробовать что-то выучить самостоятельно, каждый определяет для себя сам. Этот баланс есть и в любой другой сфере: наверняка вы про себя уже знаете, легче вам учиться самостоятельно или слушать преподавателя.
Перейдем к конкретике. Несколько раз в беседах с нашими специалистами по тестированию всплывали курсы Алексея Баранцева, например по функциональному тестированию для ручных тестировщиков или по автоматизации. Но понятно, что ими спектр возможностей для обучения не ограничивается.
Курсы, упомянутые в негативном ключе, мы здесь приводить не будем. Все зарабатывают, как могут, и профессиональное образование — это такой же бизнес, как и все остальное. Поэтому прежде чем платить кому-то деньги за освоение профессии, стоит потратить время на исследование рынка.
Учебные программы лучше всего выбирать по отзывам. При этом не стоит смотреть отзывы на сайтах самих курсов или пропагандирующих их учебных заведений. Лучше искать отрицательные комментарии в социальных сетях. Позитивные отзывы часто оставляют те, кто еще учатся — кто не может высказать все, что думает об учебном процессе. Истина вскрывается, когда они выпускаются и начинают переосмыслять то, что с ними происходило. К слову, негатив вы, скорее всего, найдете о любом учебном заведении, вопрос лишь в том, сколько его будет и каково будет его содержание.
Хорошие курсы должны подразумевать не просто рассылку видеозаписей с последующем сбором домашнего задания. Необходима нормальная обратная связь с преподавателем или наставником, который объяснит, в чем ошибка, в каком направлении стоит двигаться, чтобы правильно решить поставленную задачу. А видеоролики можно посмотреть и бесплатно (а потом и задачки из интернета порешать).
Кому-то, вероятно, будет важно и комьюнити вокруг обучения. Совместные решения сплачивают коллектив, параллельно развивая софт скиллы, необходимые для последующей работы в команде.
Стоит ли ездить на конференции?
Конференции — очень полезный элемент ИТ-мира. В первую очередь это площадка для обмена опытом. Здесь редко можно найти доклад, который ответит на сиюминутный частный вопрос в какой-то конкретной ситуации. Зато можно наткнуться на подходы к решению схожих проблем, которые вполне приложимы к вашей ситуации.
На некоторых конференциях можно встретить “базовые” доклады, позволяющие почерпнуть начальные знания в новом для себя сегменте, например в автоматизации. Но чаще это, конечно, информация для более опытных специалистов. В целом конференция — это, скорее, место для нетворкинга и получения смежных знаний (рядом со своей текущей специализацией, например на другом языке).
Стоит отметить, что большая часть вопросов, обсуждающихся на конференциях, есть и в интернете. Единичные мероприятия могут дать какой-то действительно неочевидный опыт.
Многие доклады с конференций можно найти в записи онлайн. Главное не зацикливаться на их просмотре. Если смотреть много видео, но мало практиковаться, толкового саморазвития не выйдет. Во всем нужен баланс. Кстати, в отличие от просмотра докладов, личное присутствие на конференциях — это обычно еще и знакомства, общение с людьми, с которыми можно обсудить текущие проблемы и вопросы.
Где взять первый опыт?
Настоящий опыт тестирования можно получить только на работе в реальном проекте. Чем больше кода вы напишете собственными руками, тем эффективнее вы будете решать следующие задачи, потому что прочитанная теория без практики быстро забывается.
В реальном проекте обучение пойдет гораздо эффективнее. Будут возникать конкретные проблемы, их решения можно искать в Google или на форумах. Путь, проложенный самостоятельно, в будущем сильно поможет. Естественно, путь этот стоит прокладывать не с нуля — поэтому мы выше и рассказывали о том, где стоит искать начальные знания.
Вместе с общей базой любой проект даст определенную степень специализации. Может быть, это будет тестирование продуктов под разные операционные системы, клиент-серверные приложения или инструменты для серверов. Все это потребует своих сопутствующих умений.
Ценно, когда на этом пути вас сопровождают коллеги. Поэтому для начинающего очень важно правильно выбрать компанию. Для новичка лучше устроиться в крупную организацию, где уже определены стеки технологий для каждого вида продукта, выстроены все процессы, есть тестовая документация и множество команд, у которых можно подсмотреть решение или спросить совета. На первых порах системный подход к тестированию и идеология внутреннего обмена опытом гораздо важнее, чем обещанная зарплата. А еще, будем откровенны, в крупных компаниях ответственность за неверные стратегические решения довольно размыта, так что можно спокойно набираться опыта, не рискуя всем бизнесом своего работодателя.
В небольших компаниях и стартапах отношение к тестированию зачастую иное. Кто-то что-то где-то тестирует — и хорошо. Как надо тестировать правильно, они не расскажут. Наоборот, в обход всех процедур в пятницу вечером будут заливать новые релизы на продакшн, а дотестировать их уже потом.
На такие “дикие пляски” лучше идти более подготовленным специалистам, которые понимают, в чем здесь отступление от классических процессов. У человека без опыта работа в таком режиме породит только кашу в голове. Скорее всего, ничему хорошему он тут не научится.
В целом, если вам не повезло с местом работы, не обязательно срочно собирать вещи. Главное найти специалиста, на которого можно опереться в поисках правильных решений — эдакого ментора и советчика. Кстати, ментора не обязательно искать среди коллег. Это может быть и сторонний человек, который подскажет, что изучить и куда посмотреть. Правда, посторонний человек вряд ли будет погружен в тематику проекта. Общаясь с ними, вероятно, придется и про NDA вспомнить.
Джун, миддл, сениор. А есть ли путь дальше?
На своем проекте тестировщик обычно вынужден ограничиваться существующим стеком технологий. Смена стека, как и смелые эксперименты, обычно довольно затратна либо связана с изменением места работы. Однако и в рамках стека где-то до уровня сениора проблем вам хватит — это не один год упорного труда и самообразования.
Когда покажется, что вы уперлись в потолок, можно развиваться в управленцы или идти “вширь” — изучать новые фреймворки и инструменты, поднимая свою цену на рынке труда. Важно, что при изучении разных подходов у вас будет формироваться то самое комплексное видение, которое поможет лучше решать, казалось бы, нерешаемые задачки даже внутри вашего стека.
Как и в разработке, в тестировании есть малая доля задач, которые подразумевают более глубокое знание, например, математики. Разговор о ней начинается там, где математика всплывает и в самой разработке — в высоких нагрузках и т.п. Это еще одно направление возможного роста для тех, у кого в голове могут укладываться действительно масштабные логические структуры (и кому скучно в стандартных задачах тестирования). Таких задач на рынке совсем немного. Но за счет них возможность дальнейшего саморазвития сохраняется и для тех, кто не хочет идти по управленческому пути развития.
Дополнительные ссылки
Материалы по тестированию есть на http://www.protesting.ru/. Там много теории и немного практики. Можно найти базовую информацию о том, какие бывают виды тестирования, что такое тест-кейс, тест-план и т.п. Правда, ресурс этот развивается с 2000-х годов, поэтому некоторая информация успела устареть. Но по базе здесь можно найти ценные примеры.
Форум на ресурсе https://software-testing.ru/forum/ — это своего рода аналог Хабра для тестировщиков (по большей части для автоматизаторов). Там много полезной информации именно начального уровня — на Хабре в разделе тестирования больше более продвинутых статей, а тексты для новичков появляются все реже и принимаются аудиторией все хуже.
Спасибо специалистам по тестированию нашей компании за помощь при подготовке статьи!