что такое тестирование в чем его суть как процесса
Вводная статья по тестированию: F.A.Q. новичка
Тестирование программного продукта — один из важнейших этапов в процессе его разработки. Незнание основных терминов и понятий может усложнить работу тестировщика. Мы решили собрать самые распространенные вопросы по тестированию ПО, чтобы помочь тем, кто только начинает свой путь в профессии или просто интересуется сферой IT. Некоторые из них касаются теории тестирования, другие — практики, третьи — документации в тестировании.
Благодарим за помощь в подготовке материала «Аплана. Корпоративный университет» и в частности его преподавателей: Александра Бегларяна («Базовый курс тестирования и тест-дизайна») и Екатерину Дрюпину (курс «Ручное функциональное тестирование»).
Что такое тестирование программного обеспечения (ПО)?
Согласно «Руководству к своду знаний по программной инженерии» (IEEE, SWEBOK, 2004), тестирование — это проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.
Согласно «Стандартному глоссарию терминов, используемых в тестировании программного обеспечения» (ISTQB), тестирование — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и определения дефектов.
В разных источниках, скажем, в книгах, статьях, можно встретить большое количество определений понятия «тестирование». Разные специалисты пытались объяснить его как можно точнее, придумывая все новые и новые формулировки. Например, одна из самых простых: тестирование — это сравнение фактического результата с ожидаемым. А еще — одна из техник контроля качества, включающая планирование работ (Test Management), проектирование тестов (Test Design), выполнение тестирования (Test Execution) и анализ полученных результатов (Test Analysis). Это исследование программы с целью обнаружения ошибок; возможный способ оценки качества программного обеспечения в терминах найденных дефектов, исполненных тестов и протестированных систем и т.д.
Какие есть виды тестирования?
Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы:
Тестирование можно классифицировать…
По критерию запуска программы:
По объекту тестирования:
По степени автоматизации:
По времени проведения тестирования:
По степени подготовленности:
По признаку позитивности сценариев:
Есть еще более сложные и полные классификации. К примеру, вот такой вариант использует один из преподавателей «Аплана. Корпоративный университет» на своем курсе:
Можно ли выделить наиболее востребованные виды тестирования?
Опыт показывает, что наиболее востребованы ручное функциональное тестирование, автоматизированное функциональное тестирование и нагрузочное тестирование.
Ручное функциональное тестирование (РФТ) — это тестирование вручную, то есть без использования каких-либо автоматизированных средств. В этом случае инженер по тестированию берет на себя роль конечного пользователя и, в соответствии с тестовым сценарием, проверяет ПО или систему. Его задача — выявить поведение, отличное от ожидаемого конечным пользователем.
Ручное тестирование применяется в регрессионном (тестирование изменений), интеграционном (связь с другими системами) и при тестировании нового функционала.
Автоматизированное функциональное тестирование (АФТ) — процесс верификации программного обеспечения, при котором основные функции и шаги теста выполняются автоматически при помощи инструментов для автоматизированного тестирования. Для этого сначала разрабатывают ручные тесты, затем их автоматизируют — тесты выполняются программой-роботом, без привлечения ручных тестировщиков. АФТ может являться частью регрессионного тестирования и входить в комплексное.
Нагрузочное тестирование (НТ) позволяет определить, как и с какой скоростью программа работает под определенной нагрузкой. Нагрузочное тестирование рекомендуется проводить при выпуске нового программного обеспечения, доработке эксплуатируемого ПО и при изменении конфигурации стендов.
Есть ли какие-то базовые принципы тестирования?
Вот семь основных из них:
Как понять, когда нужно начинать тестирование?
Чем раньше обнаружен дефект, тем дешевле обходится его исправление, поэтому начинать тестирование нужно как можно раньше. Например, статическое тестирование (до фактического получения ПО) делает проще динамическую стадию. На ранних стадиях проще изменить тест-дизайн и т.д.
Что такое баги?
Баг (bug) или дефект — это отклонение фактического результата от ожидаемого, изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Баги находят на этапе тестирования, затем нужна отладка (дебаггинг), которую выполняет разработчик. Отладка (debugging) — процесс поиска, анализа и устранения причин отказов в программном обеспечении. После отладки исправление требует новой проверки тестировщиком.
Какие инструменты инженер по тестированию обычно использует в своей работе?
Тестировщик самостоятельно определяет скорость работы, при которой он наиболее внимателен и эффективен. Как специалист, он должен уметь проводить ревизию своих активностей для выявления возможности ускорения действий.
Базовые инструменты тестировщика:
Как можно оценить качество ПО?
Оценка программного обеспечения производится согласно международному стандарту ISO 9126. ПО будет качественным, если можно обеспечить его функциональность, надежность, удобство использования, удобство сопровождения, производительность и переносимость. Чем больше атрибутов качества можно реализовать или поддержать (для производительности — это соответствие стандартам, временная эффективность и эффективность использования ресурсов и т.д.), тем выше будет качество ПО. У атрибутов есть и численные показатели — метрики, которые позволяют измерять прогресс в достижении качества.
Что такое тест-план и что в нем должно быть написано?
Тест-план — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Как и в случае с тестированием, в профессиональной литературе можно встретить и другие определения тест-плана. Одно из самых коротких: тест-план — это документ, обобщающий и координирующий тестирование. А одно из самых длинных: тест-план — это документ, описывающий масштаб, подход, ресурсы и график тестирования, в котором определены тестовые элементы, отдельные части функционала, тестовые задания, специалисты, которые будут проводить конкретные тесты, и любые риски, требующие дополнительного планирования.
Основные разделы тест-плана:
Что такое тест-дизайн и зачем он нужен?
Тест-дизайн — одна из наиболее творческих деятельностей в IT. Это этап процесса тестирования ПО, на котором, в соответствии с определенными ранее критериями качества и целями тестирования, проектируются и создаются тестовые случаи (тест-кейсы).
Что является результатом работы инженера по тестированию?
Для большинства тестировщиков основной продукт работы — отчет о проделанных испытаниях в разрезе общего количества пройденных тестовых сценариев с их результатами, а также список открытых дефектов с указанием их критичности.
Есть ли какие-то книги, которые могут быть полезны новичку в тестировании?
Рекомендуем к прочтению следующие книги:
Как научиться тестировать ПО
Считается, что через тестирование можно легко зайти в ИТ. Мы спросили наших специалистов по тестированию, как это реализовать без поступления на профильные программы обучения в вузы. Оказалось, что можно ограничиться базой по информатике, одной книжкой по тестированию и правильным выбором, где получать первый опыт. Правда, приправить это надо собственной заинтересованностью и усердием.
Под катом — наши советы и ответы на распространенные вопросы новичков. Есть немного и о том, куда двигаться дальше, когда кажется, что потолок знаний близко.
Нужна ли тестировщику база в ИТ?
Откровенно скажем, желательна.
Большинство наших специалистов в той или иной форме увлекались ИТ с детства или как минимум учились в профильных вузах, т.е. уже имели какую-то базовую подготовку еще до прихода в тестирование. Часть из них начинали как разработчики (учились на разработчика) — отдельные “тестовые” направления еще лет 10 назад отсутствовали. Так что у нас перед глазами просто нет “антипримера” такого пути.
Сейчас в ИТ действительно много тех, кто такую подготовку не проходил. И им немного сложнее двигаться вперед. Чтобы справиться с задачами в тестировании, необходимо как минимум уметь поставить операционку, понимать, как развернуть тестовое приложение и необходимое окружение, как создать репозиторий в Git, погуглить ответы на свои вопросы, покопаться на специализированных ресурсах вроде Stackoverflow. По сути это и обеспечивает общая база по информатике.
Но и эти знания вполне можно освоить по книгам или курсам в интернете. Сегодня недостатка в источниках информации нет. Главное, чтобы была заинтересованность и время, которое можно на это выделить.
В тестировщики или в разработчики?
Тестирование тестированию рознь.
Требования к начинающему ручному тестировщику не очень высоки. Пожалуй, это и есть та самая “легкая дорога в ИТ”. Здесь нужно знать базовые принципы тестирования, о которых мы поговорим чуть позже, и иметь упомянутую выше базу. Правда, от ручных тестировщиков постепенно уходят, чтобы проверять программные продукты быстрее и эффективнее. Поэтому так или иначе со временем все “ручники” начинают писать код или заниматься метриками и анализом. Но это не значит, что нельзя начать свою карьеру в статусе джуна-”ручника”.
Автоматизатор тестирования уже ближе к разработчику. В базе знаний у каждого автоматизатора обычно значится как минимум один язык программирования — тот, на котором ведется разработка автотестов (это не всегда основной язык разработки на проекте). Занимаясь автоматизацией, также важно знать шаблоны проектирования и уметь применять общие принципы разработки — расширяемость, читаемость, легкость переиспользования. По сути автотест — это та же программа, которая должна соответствовать заранее заданному сценарию.
Чтобы начать работать автоматизатором, помимо знаний о тестировании в целом, необходимо иметь минимальные знания в объектно-ориентированном программировании, представлять, как написать простейший “Hello World!”.
Выбирая направление, вряд ли стоит смотреть на сиюминутную популярность специалистов на рынке труда. Средние показатели спроса и зарплат в ИТ — вещь очень специфическая, они зависят в том числе и от смежных знаний. Кто бы мог подумать, но специалисты по разработке на каком-нибудь Delphi сейчас в банковском секторе востребованы, несмотря на то, что в других отраслях язык не пользуется вообще никаким спросом. Здесь все работает по законам рынка: специалистов мало, а спрос на них остался, поскольку кому-то же надо поддерживать легаси.
Так и в тестировании. Сейчас есть спрос на JS-автоматизаторов. Он велик, потому что запросы у бизнеса большие, но еще не успели выучиться те люди, которые встали на данный путь с первым появлением интереса рынка. Как только они выучатся и пойдут работать, ситуация может измениться.
В этом изменчивом мире именно базовые знания — понимание, что и как тестировать в принципе, какие бывают подходы, — а также умение быстро усваивать информацию помогут быстро переориентироваться на смежный стек технологий.
Что почитать?
Тестирование, да и ИТ в целом, — бурно развивающаяся отрасль, поэтому часто можно встретить скептическое отношение к книгам. Слишком уж у них велик “цикл производства”. Писать, издавать, распространять — долго. Он растягивается более чем вдвое, если мы говорим о переводной литературе.
Однако одну книгу наш отдел тестирования рекомендовал почти единогласно — “Тестирование Дот Ком” Романа Савина. Это самая известная книга по теме, которая просто и доступно вводит в курс основных понятий и процессов в ручном тестировании. И хотя она издана довольно давно, базовые знания, изложенные в ней, до сих пор актуальны. Пожалуй, ее читали процентов 80 всех тестировщиков в странах СНГ.
Другие рекомендации легко найти в распространенных в интернете “списках N книг для начинающего тестировщика”. Но в целом наша команда тестирования считает, что базы из книги Романа Савина будет достаточно для запуска дальнейшего процесса самообразования.
Стоит ли идти на курсы, тем более платные?
Мнение о курсах у наших специалистов неоднозначное.
Любые учебные программы полезны тем, что они дают сразу много информации в структурированном виде. Информация собрана в удобные для освоения фрагменты, разделена по этапам. Уровень за уровнем можно идти по учебной программе, как в игре, и получать полезные знания.
Идти на курсы можно с одной из двух целей — либо закрыть какие-то пробелы в знаниях, либо закрепить уже известную информацию. В зависимости от целей усваиваться все будет по-разному. Но из-за обилия новых знаний осядет далеко не 100% полученной информации. С этой точки зрения самостоятельное обучение на конкретном проекте полезнее. Собранные сведения или найденный ответ точно задержатся в голове. Правда, на это уйдет немного больше времени.
Не все стены стоит пробивать своим лбом. И правильный баланс, где стоит послушать лектора на курсах, а где — попробовать что-то выучить самостоятельно, каждый определяет для себя сам. Этот баланс есть и в любой другой сфере: наверняка вы про себя уже знаете, легче вам учиться самостоятельно или слушать преподавателя.
Перейдем к конкретике. Несколько раз в беседах с нашими специалистами по тестированию всплывали курсы Алексея Баранцева, например по функциональному тестированию для ручных тестировщиков или по автоматизации. Но понятно, что ими спектр возможностей для обучения не ограничивается.
Курсы, упомянутые в негативном ключе, мы здесь приводить не будем. Все зарабатывают, как могут, и профессиональное образование — это такой же бизнес, как и все остальное. Поэтому прежде чем платить кому-то деньги за освоение профессии, стоит потратить время на исследование рынка.
Учебные программы лучше всего выбирать по отзывам. При этом не стоит смотреть отзывы на сайтах самих курсов или пропагандирующих их учебных заведений. Лучше искать отрицательные комментарии в социальных сетях. Позитивные отзывы часто оставляют те, кто еще учатся — кто не может высказать все, что думает об учебном процессе. Истина вскрывается, когда они выпускаются и начинают переосмыслять то, что с ними происходило. К слову, негатив вы, скорее всего, найдете о любом учебном заведении, вопрос лишь в том, сколько его будет и каково будет его содержание.
Хорошие курсы должны подразумевать не просто рассылку видеозаписей с последующем сбором домашнего задания. Необходима нормальная обратная связь с преподавателем или наставником, который объяснит, в чем ошибка, в каком направлении стоит двигаться, чтобы правильно решить поставленную задачу. А видеоролики можно посмотреть и бесплатно (а потом и задачки из интернета порешать).
Кому-то, вероятно, будет важно и комьюнити вокруг обучения. Совместные решения сплачивают коллектив, параллельно развивая софт скиллы, необходимые для последующей работы в команде.
Стоит ли ездить на конференции?
Конференции — очень полезный элемент ИТ-мира. В первую очередь это площадка для обмена опытом. Здесь редко можно найти доклад, который ответит на сиюминутный частный вопрос в какой-то конкретной ситуации. Зато можно наткнуться на подходы к решению схожих проблем, которые вполне приложимы к вашей ситуации.
На некоторых конференциях можно встретить “базовые” доклады, позволяющие почерпнуть начальные знания в новом для себя сегменте, например в автоматизации. Но чаще это, конечно, информация для более опытных специалистов. В целом конференция — это, скорее, место для нетворкинга и получения смежных знаний (рядом со своей текущей специализацией, например на другом языке).
Стоит отметить, что большая часть вопросов, обсуждающихся на конференциях, есть и в интернете. Единичные мероприятия могут дать какой-то действительно неочевидный опыт.
Многие доклады с конференций можно найти в записи онлайн. Главное не зацикливаться на их просмотре. Если смотреть много видео, но мало практиковаться, толкового саморазвития не выйдет. Во всем нужен баланс. Кстати, в отличие от просмотра докладов, личное присутствие на конференциях — это обычно еще и знакомства, общение с людьми, с которыми можно обсудить текущие проблемы и вопросы.
Где взять первый опыт?
Настоящий опыт тестирования можно получить только на работе в реальном проекте. Чем больше кода вы напишете собственными руками, тем эффективнее вы будете решать следующие задачи, потому что прочитанная теория без практики быстро забывается.
В реальном проекте обучение пойдет гораздо эффективнее. Будут возникать конкретные проблемы, их решения можно искать в Google или на форумах. Путь, проложенный самостоятельно, в будущем сильно поможет. Естественно, путь этот стоит прокладывать не с нуля — поэтому мы выше и рассказывали о том, где стоит искать начальные знания.
Вместе с общей базой любой проект даст определенную степень специализации. Может быть, это будет тестирование продуктов под разные операционные системы, клиент-серверные приложения или инструменты для серверов. Все это потребует своих сопутствующих умений.
Ценно, когда на этом пути вас сопровождают коллеги. Поэтому для начинающего очень важно правильно выбрать компанию. Для новичка лучше устроиться в крупную организацию, где уже определены стеки технологий для каждого вида продукта, выстроены все процессы, есть тестовая документация и множество команд, у которых можно подсмотреть решение или спросить совета. На первых порах системный подход к тестированию и идеология внутреннего обмена опытом гораздо важнее, чем обещанная зарплата. А еще, будем откровенны, в крупных компаниях ответственность за неверные стратегические решения довольно размыта, так что можно спокойно набираться опыта, не рискуя всем бизнесом своего работодателя.
В небольших компаниях и стартапах отношение к тестированию зачастую иное. Кто-то что-то где-то тестирует — и хорошо. Как надо тестировать правильно, они не расскажут. Наоборот, в обход всех процедур в пятницу вечером будут заливать новые релизы на продакшн, а дотестировать их уже потом.
На такие “дикие пляски” лучше идти более подготовленным специалистам, которые понимают, в чем здесь отступление от классических процессов. У человека без опыта работа в таком режиме породит только кашу в голове. Скорее всего, ничему хорошему он тут не научится.
В целом, если вам не повезло с местом работы, не обязательно срочно собирать вещи. Главное найти специалиста, на которого можно опереться в поисках правильных решений — эдакого ментора и советчика. Кстати, ментора не обязательно искать среди коллег. Это может быть и сторонний человек, который подскажет, что изучить и куда посмотреть. Правда, посторонний человек вряд ли будет погружен в тематику проекта. Общаясь с ними, вероятно, придется и про NDA вспомнить.
Джун, миддл, сениор. А есть ли путь дальше?
На своем проекте тестировщик обычно вынужден ограничиваться существующим стеком технологий. Смена стека, как и смелые эксперименты, обычно довольно затратна либо связана с изменением места работы. Однако и в рамках стека где-то до уровня сениора проблем вам хватит — это не один год упорного труда и самообразования.
Когда покажется, что вы уперлись в потолок, можно развиваться в управленцы или идти “вширь” — изучать новые фреймворки и инструменты, поднимая свою цену на рынке труда. Важно, что при изучении разных подходов у вас будет формироваться то самое комплексное видение, которое поможет лучше решать, казалось бы, нерешаемые задачки даже внутри вашего стека.
Как и в разработке, в тестировании есть малая доля задач, которые подразумевают более глубокое знание, например, математики. Разговор о ней начинается там, где математика всплывает и в самой разработке — в высоких нагрузках и т.п. Это еще одно направление возможного роста для тех, у кого в голове могут укладываться действительно масштабные логические структуры (и кому скучно в стандартных задачах тестирования). Таких задач на рынке совсем немного. Но за счет них возможность дальнейшего саморазвития сохраняется и для тех, кто не хочет идти по управленческому пути развития.
Дополнительные ссылки
Материалы по тестированию есть на http://www.protesting.ru/. Там много теории и немного практики. Можно найти базовую информацию о том, какие бывают виды тестирования, что такое тест-кейс, тест-план и т.п. Правда, ресурс этот развивается с 2000-х годов, поэтому некоторая информация успела устареть. Но по базе здесь можно найти ценные примеры.
Форум на ресурсе https://software-testing.ru/forum/ — это своего рода аналог Хабра для тестировщиков (по большей части для автоматизаторов). Там много полезной информации именно начального уровня — на Хабре в разделе тестирования больше более продвинутых статей, а тексты для новичков появляются все реже и принимаются аудиторией все хуже.
Спасибо специалистам по тестированию нашей компании за помощь при подготовке статьи!
Автор: Клэр Рэклесс (Claire Reckless)
Перевод: Ольга Алифанова
Если бы вам пришлось ответить на вопрос «Что такое тестирование?», что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений.
Плюс к тому многие недопонимают, что же такое тестирование, чем занимаются тестировщики – даже среди самих тестировщиков. Тестирование как навык и как профессия постоянно развивается. В этой статье мы рассматриваем, чем тестирование является, и чем нет.
Из чего состоит тестирование
Расследование
Расследование определяется как «наблюдение или изучение путем близкого наблюдения и систематического изучения» [1].
Процесс тестирования должен быть расследованием. Мы не всегда знаем, что получим на выходе, но наша задача – выяснить информацию, которая поможет людям принимать решения. Это не просто сравнение работы системы со спецификацией, где прописан ожидаемый результат. Мы должны мыслить критически, задавать сложные вопросы, рисковать, подмечать то, что на первый взгляд кажется несущественным, а при тщательном анализе оказывается важным и требующим дальнейшего изучения.
Список требований всегда неполон – всегда найдутся неучтенные требования, которые опущены или предполагались по умолчанию. Вне зависимости от полноты ваших требований, они всегда будут неполны. Вы не будете заранее знать, что делает ваше приложение. И тут в игру вступает исследовательское тестирование.
Исследовательское тестирование определяется как одновременное обучение, тест-дизайн и прогон тестов [2]. Тестировщик исследует приложение, узнает новую информацию, учится, находит что-то новое для тестирования по ходу дела. Он может заниматься этим в одиночку или в паре с другим тестировщиком (а может, и разработчиком).
Тестирование не должно восприниматься, как прогон списка готовых тестов или тест-кейсов, дающих твердый «pass/fail’ результат. Если у вас есть юзер-стори или набор требований, конечно, важно иметь их в виду. Однако критерии приемки бывает полезно переформулировать как «критерии отказа». Когда критерии приемки не удовлетворены, продукт не принят, но если они в порядке, это не значит, что в ПО нет багов.
Проверки и верификация должны совмещаться с исследованием и расследованием, а также вопросами в духе «Что будет, если…», на которые вы можете не знать ответа, пока не попробуете, и ответы на которые не покрыты вашими готовыми кейсами.
Снижение рисков
Одна из причин, по которой мы тестируем – это поиск дефектов, рисков и другой информации о продукте, которая позволяет нам действовать, чтобы конечный пользователь не пострадал. Мы можем:
Устранить все возможные баги, с которыми может столкнуться пользователь, просто невозможно, каким бы сложным не было ваше ПО. Однако, тестируя, мы снижаем риск того, что пользователь с ними столкнется – или серьезность последствий такого столкновения.
Ценность
Тестирование – это ценная часть разработки ПО, но его часто недооценивают из-за его непредсказуемой и креативной природы.
Результат ежедневного труда разработчика – это код, аналитика – требования или документация, однако результаты труда тестировщика может быть довольно сложно измерить. Зачастую тестировщикам сложно рассказать о своих планах, своем прогрессе и результатах. Те, кто не разбирается в тестировании, в результате плохо понимают, что было сделано, как, и почему. В итоге понять ценность тестирования сложно. В мире множество компаний, разрабатывающих ПО вообще без тестировщиков.
Отсутствие счетного результата, создаваемого тестировщиками – одна из причин, по которой некоторые предпочитают использовать тест-кейсы как способ измерения – их можно легко сосчитать. Но ценность тестирования – это намного больше, чем тест-кейсы. Исследовательское тестирование, возможно, не дает в результате набора четких кейсов, однако тестировщик находит больше интересных багов, отступая от жестких сценариев.
Отчасти поэтому людям нравятся метрики, которые учитывают количество заведенных багов, написанных и пройденных кейсов, и других вещей, которые можно сосчитать. Некоторые проекты используют эти метрики, чтобы измерять качество продукта, а также качество работы разработчиков и тестировщиков. Эти метрики концентрируются на неправильных вещах и могут вас обманывать.
Тестирование ценно на всех стадиях жизненного цикла разработки, не только когда пишется код. Вот что еще можно протестировать:
Задача тестировщика – задавать вопросы, исследовать, критически размышлять над этими вещами. В результате то, что могло бы стать багом в процессе разработки, можно изловить гораздо раньше.
Коммуникация
Коммуникация – это огромная часть работы тестировщика. Тестировщики предоставляют информацию о качестве программного продукта, поэтому очень важно передавать эту информацию точно, чтобы заинтересованные лица принимали верные решения.
Человек может начать работать тестировщиком, имея слабые технические навыки, но если он силен в коммуникации и может внятно донести свою мысль – это куда важнее.
Тестировщики должны использовать правильные слова и верно строить фразы, чтобы они не были противоречивыми – так снижается риск недопонимания. То, что вы хотели сказать – необязательно то, что вы в итоге сказали, и часто люди делают допущения и в результате предпринимают неверные действия, потому что коммуникация была плохой или недостаточной.
Нам нужно регулярно общаться с людьми, играющими различные роли, находящимися на разных позициях и обладающих разным объемом знаний о продукте.
Письменная коммуникация важна не меньше устной. Создать блестяще написанную, обширную документацию, которая никому не нужна, легче легкого. Мы должны убедиться, что используем правильный способ общения в каждом конкретном случае, будь то человек, процесс или проект.
Потенциальная бесконечность
По сути, мы всегда тестируем только выборку. Каждый нетривиальный продукт обладает непредставимым количеством параметров с большим количеством возможных значений. Откуда вы знаете, что тестируете важные значения? Мы не можем протестировать все.
Часть нашей работы – принятие решений о том, что тестировать, понимание последствий того, что будет протестировано только это, и способность обосновать свой выбор.
Из чего тестирование не состоит
Простота
О тестировании часто думают как о чем-то, чем может заниматься любой. Возможно, в какой-то степени это правдиво – любой может исследовать продукт, задавать вопросы о нем, прогнать пошагово тест-кейс или проверить, соответствует ли продукт списку требований. Но чтобы делать это хорошо и систематически, нужен настоящий навык.
Нам часто говорят «пишите кейсы так, чтобы их мог прогнать любой дурак», и из-за этого создается ложное впечатление, что тестировать очень просто. Мы тупо пишем тесты согласно критериям приемки, не так ли? Но тестировщики, тестирующие свободным поиском, знают, что это не так.
Даже проверки – не такое-то простое дело. Мы принимаем непростые решения, где нужны эти проверки, и какие из них следует автоматизировать. Эти решения требуют понимания фреймворков автоматизации, навыка программирования, знания, как работает API, и владения инструментами вроде Selenium. Резюмируя, мы должны разбираться в приличном наборе технологий. Помимо этого, нам нужно знать, что нужно автоматизировать, а к чему автотесты подпускать нельзя.
Автоматизируемость
«Ручные тестировщики нам больше не нужны – мы можем автоматизировать все!» Все мы видели те или иные вариации этой фразы в Твиттере, на форумах и в статьях. Тестирование – это исследовательская, детективная деятельность, и ее невозможно заменить автоматизированными проверками. Компьютер технически не способен исследовать продукт так, как это делает человек.
Мы можем автоматизировать те или иные проверки, но компьютер и человек будут прогонять их по-разному. Живой человек заметит многое из того, на что никогда не обратит внимание машина, и прислушается к своему ощущению «тут что-то не так» – и, соответственно, даст обратную связь не только по конкретной проверке, но и по всему подмеченному в процессе. Компьютер сделает только то, что ему сказано сделать. Автоматизированные проверки очень ценны для тест-стратегии, но на данный момент неспособны заменить живых тестировщиков, потому что люди и машины занимаются принципиально разными вещами.
Тестировщики используют инструменты, в том числе автотесты, для поддержки своей работы. Специальные инструменты помогают нам генерировать данные, автоматизировать рутины, анализировать результаты тестов. Ими нужно владеть, чтобы облегчить себе жизнь, а не с целью заменить ручной труд полностью.
Повышение качества
Тестировщики не делают ничего, что бы напрямую улучшало качество продукта. Прогоняя тест, мы никак не влияем на код – следовательно, качество ПО остается неизменным. Только после того, как разработчики исправляют баги, качество продукта может измениться. Мы не можем «втестировать» качество в продукт.
Тестирование – не единственная область разработки ПО, принимающая во внимание качество продукта. За ним нужно следить на всех стадиях жизненного цикла, и за него отвечают все участники команды разработки. Тестировщики могут использовать свои специфические навыки для сотрудничества с коллегами, но за качество отвечаем не только мы – это головная боль всей команды!
Ни тестировщики, ни разработчики, правящие баги, не могут в результате сделать вывод, что качество продукта улучшилось. Мы не можем протестировать все, поэтому всегда вероятны сценарии, которые мы не проверяли, таящие в себе баги. Качество может ухудшиться из-за изменений или чего-то, неизвестного нам – мы даже не подозреваем, что у нас есть проблемы, пока не произойдет нечто, вскрывающее их. И даже если тестировщики могут уверенно сказать, что продукт готов к релизу, конечные пользователи могут его забраковать – например, из-за криво составленных требований. Все зависит от точки зрения.
Качество определяется как «ценность для человека, чье мнение значимо». Его трудно измерить, и поэтому с определенностью заявить, что тестирование на каком бы то ни было этапе улучшает качество продукта, довольно трудно, даже невозможно.
Фиксированная, не требующая воображения деятельность, подчиняющаяся строгим правилам
Самые интересные баги зачастую находятся при помощи исследовательского тестирования. Прогон одних и тех же тестов раз за разом вряд ли даст вам много новой интересной информации – и, на сердце руку положа, довольно скучно гонять их вручную.
Не существует лучших практик тестирования, применимых в абсолютно любых проектах. Вы должны выяснить, что лучше всего работает в вашем контексте и в вашей области.
Размышления над новыми креативными способами тестирования – очень увлекательная часть нашей работы. Способность экспериментировать, искать лучшие инструменты, изучать новые навыки и технологии, и делать то, что наилучшим образом подходит нашему проекту, помогает нам постоянно совершенствоваться и держать свои навыки в форме.
Жизненно необходимо для успеха продукта
Проект может быть вполне успешным и без тестировщиков – тому множество примеров. Однако даже в случае отсутствия тестировщиков как таковых тестирование все же кем-то выполняется на той или иной стадии жизненного цикла. Разработчики тестируют собственный код, а заказчики – требования. Конечный пользователь иногда тестирует продукт до релиза. Люди могут тестировать, даже не отдавая себе отчета, что они этим занимаются.
Никогда не заканчивается
Под бесконечностью тестирования понимается невозможность протестировать все и вся в приложении. Нет реалистичных способов протестировать все комбинации, действия пользователя, внешние условия, значения данных или пути через код. В этом плане тестирование, действительно, бесконечный процесс. Следует принять как данность, что всегда останется что-нибудь непротестированное. Большинство проектов жестко ограничены временем, бюджетом и ресурсами, и тестировщики должны укладываться в эти ограничения, тестируя максимально эффективно.
Часть работы тестировщика – это принятие решений, что именно тестировать, и понимание последствий этих решений и связанных с нимирисков.
Тестирование завершается, когда у менеджмента достаточно информации, помогающей принять решение, готов ли продукт к релизу.
Тестирование – это многое, многое другое
Я перечислила только некоторые аспекты того, что же такое тестирование. Эта статья могла бы быть значительно длиннее! Нет единого определения, что подразумевается под тестированием, а впихнуть в одно предложение все то, чем занимаются тестировщики, просто невозможно! Если поискать определение тестирования в Интернете, можно наткнуться на фразы вроде «поиск багов в приложениях» – но как мы уже выяснили, это не только и не столько поиск багов.