Гид по ручному тестированию приложений: преимущества, этапы и методологии
Время на прочтение
12 мин
Количество просмотров 82K
Детально разбираем то, как проводить ручное тестирование, когда оно лучше автоматизированного, что нужно уметь тестировщику и как он может построить свою карьеру от джуниора до тест- лида. Гид подготовлен совместно с руководителем отдела тестирования компании Agima Дариной Гордеевой.
Привет! Меня зовут Дарина Гордеева. Работаю в компании AGIMA руководителем отдела почти 3 года. В области тестирования и обеспечения качества более 6 лет. За это время прошла путь от джуниора до руководителя отдела, занимаясь тестированием железа, а также мобильных и веб-приложений, автоматизацией и настройкой процессов QA. Сегодня я расскажу вам про особенности, возможности и скрытые проблемы ручного тестирования.
Напомним, что любой читатель, воспользовавшийся промословом “Хабр” может получить скидку в 10 000 рублей на понравившийся курс, а самые усидчивые и внимательные могут собрать себе скидку в 25 000 рублей, разгадывая ребусы из материалов, подготовленных совместно с агентством Agima:
- Как с первого раза попасть в AppStore: пошаговое руководство;
- 8 этапов процесса разработки интерфейса мобильного приложения;
- А/В-тесты не работают. Проверьте, что вы делаете не так.
Оперативность, гибкость, возможность импровизации и другие плюсы
Сегодня есть множество фреймворков для тестирования, поддерживающих практически все существующие языки. Казалось бы — можно брать и автоматизировать. Но даже сейчас ручные тесты важны.
Одно из объяснений их необходимости заключается в том в том, что при ручном тестировании функционала мы можем гораздо быстрее получить информацию о состоянии продукта, который анализируем, о качестве разработки. Кроме того, при автоматизации предварительно разработанные кейсы часто приходится менять и актуализировать, а на написание автотестов требуется определённое время.
При этом в процессе разработки может прийти обратная связь от заказчика, когда он увидит в готовом продукте какую-то функцию, которую решит изменить до релиза — и, если вы уже подготовили для неё программные тесты, их придётся переписать. Обновление кейсов, автотестов и их проверка отнимут ценное время, которое можно было бы использовать на само обновление этой фичи.
Всё это означает, что главная цель ручных тестов — предварительно убедиться в том, что заявленный функционал работоспособен, не имеет ошибок и выдаёт ожидаемые, запланированные результаты. Без них нельзя быть уверенным в том, что можно работать дальше. Особенно это актуально для функций, на реализацию которых завязана последующая разработка. В таком случае возня с созданием автотестов на эти фичи становится блокирующим фактором для всей разработки продукта, сдвигая сроки и срывая дедлайны. Момент, когда кейсы придёт пора автоматизировать, всё равно рано или поздно наступит — но не стоит стремиться приблизить его искусственно в погоне за тотальным исключением ручного труда.
В дополнение к этому, на первых этапах разработки приложения автоматизация может оказаться довольно дорогой. Вам потребуется специалист, обладающий специфической квалификацией (и, возможно, не один). Постоянное поддержание тестов в актуальном состоянии требует затрат ресурсов вплоть до релиза фичи. А месяцы простоя, посвященные вылизыванию автотеста ударят по мотивации команды.
Если вы хотите регулярно добавлять новый функционал и успевать за действиями конкурентов, то перед тем, как создавать автотесты всегда проверяйте возможности продукта вручную. Просто потому что ручное тестирование ускоряет ваши процессы.
Это особенно актуально для мобильной разработки. Большинство таких проектов сегодня разрабатывается короткими спринтами, а значит фичи в них внедряются в ускоренном темпе. В подобных условиях ручное тестирование позволяет максимально оперативно давать команде обратную связь: сообщать о наличии багов — или радовать её тем, что всё окей и можно двигаться дальше. Провести серию автотестов вы сможете позже, покрыв с их помощью большие массивы кода. Ручное тестирование поможет подготовить кейсы для этой проверки.
Автотесты не позволяют проверить удобно ли использовать новые возможности приложения — проверка юзабилити всегда осуществляется вручную.
Skillbox рекомендует: онлайн-курс Fullstack-мобильный разработчик.
В ручных тестах можно импровизировать, создавая безумные сочетания действий, которые никогда не придут в голову пользователю, но могут быть совершены им случайно. Это позволяет создавать новые кейсы.
Новые кейсы появляются еще и потому, что тестировщик постоянно задает себе вопрос «а что, если?». Так он находит оригинальные способы взаимодействия с приложением — даже если их не было в базовых сценариях.
Проблемы ручного тестирования и их решения
Самый большой из недостатков ручного тестирования — человеческий фактор. Он, конечно, влияет на всё, происходящее в команде — и на работу участников, и на события, происходящие на стороне клиента. В случае QA причиной того, что тестировщик будет слабо погружен в процесс и пропустит потенциальную ошибку может стать всё что угодно — недостаток опыта, семейные проблемы или головная боль.
Один и тот же сценарий два тестировщика могут проверить разными способами. Что с этим делать? Важно, чтобы каждый непредусмотренный или отличающийся от ожидаемого результат был зафиксирован в виде кейса. Чтобы любой тестировщик мог проверить его, совершив тот же набор действий. Но и этого может быть мало — если кейс окажется недостаточно подробным, а тестировщик — не разберётся в описании. Гарантировать стопроцентное исключение человеческого фактора, конечно, невозможно — но можно постараться максимально снизить вероятность проблем, которые он вызывает.
Это тоже негативно сказывается на сроках поставки фичи в продакшн и трудозатратах: ведь теперь к периодически проводимым базовым кейсам и регрессии добавляются и “хитрые” кейсы, придуманные тестировщиками в процессе.
Усугубляет ситуацию вероятность того, что часть встреченных багов ещё не будет иметь строгого описания потому что причины их возникновения пока не понятны. Как бороться с такими повторными тестированиями? Либо найти уже источник ошибки и устранить его, либо — всё таки автоматизировать прохождение проблемных кейсов — в этом случае переход к программным тестам будет вполне оправдан как с точки зрения времени, так и финансово. (Нет, это не противоречит вышесказанному — потому что такие ситуации возникают уже в ходе активной разработки и к этому времени вы уже в любом случае развернёте процессы автотестирования).
В любом случае — появление первых кейсов, нуждающихся в регрессивных тестах или релиз второй версии приложения и соответствующее этим событиям масштабирование команды — тот момент, когда автоматизация станет актуальна (но не исключит ручное тестирование новых возможностей). На этом этапе автоматизация уже начнёт экономить время: разработчик сможет сам, ещё до передачи QA-отделу запустить регресс-тесты новой фичи, чтобы убедиться, что она не ломает существующий функционал, а тестировщику не придётся лишний раз проходить по набившим оскомину базовым кейсам. Ещё одно преимущество внедрения автотестов на этом этапе — их можно запускать по определённому расписанию — каждую ночь, в дни окончания спринтов или при публикации новых сборок приложения.
При этом нельзя забывать несколько вещей:
- создание кейсов и написание автотестов будет требовать времени — закладывайте его в спринты;
- убедитесь, что кейс автотеста прописан хорошо и подробно и описывает возможную проблему или существующий сценарий во всей полноте;
- проверьте, правильно ли работает автотест и действительно ли он проверяет то, что нужно и делает это качественно.
Резюмируем: ручное тестирование даёт большое преимущество по скорости и трудозатратам на первых этапах, а по мере разрастания приложения и появления большого количества регрессивных тестов оно переходит в разряд “оперативного тестирования” новых фич в рамках отдельного спринта. Оно будет актуально и при необходимости срочно проверить как приложение отреагирует на изменение операционной системы или обновление окружения.
Этапы тестирования: что, когда и как
Если смотреть на процесс разработки в целом и на тестирование как на одну из его частей, то при грамотном планировании вы всегда будете понимать что и когда будет готово. Это позволит лучше планировать время тех или иных действий — поскольку одни события логично следуют за другими и у вас есть возможность выстраивать их в цепочки на основании своих ожиданий.
Тестировщик появляется в процессе создания приложения уже на ранних этапах. Вот у клиента появляется некая идея, бизнес-аналитики собирают из этого требования — а тестировщики уже в этот момент приступают к работе, проверяя эти требования.
Как это происходит? Они задают вопросы по предполагаемому функционалу. Пытаются представить, как будет выглядеть приложение, когда оно будет реализовано. Если речь идёт о новой фиче в уже существующем продукте — разбираются, как она будет взаимодействовать с существующим функционалом. После того, как разработчики провели оценку трудозатратности идей клиента и определили сколько потребуется времени на их реализацию.
После этого начинается этап проектирования. Здесь появляется необходимость понять, как будут осуществляться переходы между экранами, валидироваться те или иные поля, как приложение или его отдельная функция вообще будет взаимодействовать с конечным пользователем. В случае с фичами важно разобраться и с тем, как они будут входить в архитектуру существующего приложения.
На этапе дизайна, когда создаётся карта переходов между экранами, тестировщик уточняет поведение отдельных элементов из которых они состоят и то, какими визуальными эффектами будут сопровождаться те или иные действия пользователя. Кроме этого тестировщик валидирует макеты на полноту, подтверждая, что они отображают всё, что нужно для реализации задуманного функционала. Нелишней будет и самостоятельная проверка макетов на соответствие гайдлайнам.
Skillbox рекомендует: онлайн-курс Дизайн мобильных приложений
С началом разработки QA-специалисты сразу же приступают к написанию тест-кейсов. На разных этапах разработки они могут обладать различным уровнем детализации, но к её окончанию желательно обеспечить максимальное покрытие кейсами всего продукта, чтобы, получив сборку, можно было приступить к тестированию немедленно.
Первый шаг непосредственно тестирования — смоук-тест: оценка на то, что приложение или его новая часть вообще готовы к проверке. Смоук-тест — это проверка того, запускается ли приложение или конкретная функция в принципе.
Смоук-тест — быстрый способ убедиться, можем ли мы вообще начать функционально тестирование. Термин пришел от создателей плат и микросхем, которые для начала должны были убедиться не сгорит ли новая схема — отсюда и название: задымилась/не задымилась.
Это быстрый способ убедиться в том, что нам действительно сдали задачу и её можно принимать в работу, а не отправлять обратно программистам.
На примере формы авторизации смоук — это оценка того, можно ли залогиниться вообще, без уточнения того, валидны ли данные, вводимые в поля, работают ли дополнительные возможности вроде напоминания пароля и прочего. Если мы смогли авторизоваться в принципе — можно переходить к дальнейшей, углублённой проверке этого модуля: брать негативные кейсы, пограничные значения, оценивать соответствие установленным правилам валидации.
Следующий этап — проведение регресс-тестов. В ручном или автоматическом режиме проводится основной заранее запланированный массив тестов.
Регрессионное тестирование хорошо тем, что оно позволяет найти ошибки даже в тех местах, где раньше всё было в порядке. Это происходит благодаря тому что регресс — это оценка функционала на стандартный набор кейсов при внедрении каждого нового модуля и каждого изменения приложения. Ведь, когда разработчики добавляют новый функционал может быть повреждена текущая версия или новая фича может вступать в конфликт с уже существующими.
Например, добавление новых экранов, а значит и изменение навигации может нарушить функционирование меню или, как минимум — его отображение. С другой стороны неприятные сюрпризы может принести и глобальный рефакторинг кода приложения — после него тоже необходимо проводить регресс-тесты.
Проблемы могут вызвать и обновление используемой приложением библиотеки и изменение среды в которой оно работает. Чем чаще вы обновляете приложение — тем более важную роль играют регрессионные проверки. Не стоит ограничиваться однократной проверкой, проводимой, когда фича уже внедрена — проверяйте все изменения. Здесь вам поможет автоматизация регрессионного тестирования — просто потому что ручное регрессионное тестирование новой фичи, создававшейся всего неделю может занять две, а то и больше и отдел тестирования просто завязнет в этом.
Полная проверка, конечно, осуществляется когда release candidate с одной или несколькими фичами готов выкатываться в продакшн, но применять те или иные соответствующие кейсы на отдельных этапах разработки всё таки необходимо.
Завершается всё тестированием финальной сборки — release candidate. В него входят проверка бета-версии внутренними тестировщиками, бизнес-тестирование — оценка получившегося продукта самим клиентом и получение от него обратной связи, а также предложение определённой группе пользователей познакомиться с предрелизной альфа-версией приложения или его новых возможностей. После этого приложение готово к тому, чтобы его выкатили в продакшн.
Но на этом работа QA-специалиста не заканчивается — ему предстоит тестировать обновления приложения и их совместимость с более ранними версиями, составлять кейсы для проверки нововведений и, в случае необходимости, автоматизировать прохождение этих сценариев.
Параллельно с этим тестировщики участвуют в дальнейшем анализе статистики, собираемой аналитиками, мониторинге поведения приложения и того, как взаимодействуют с ним пользователи. Это позволяет не только увидеть живое использование результатов их работы, но и, порой, открыть для себя новые сценарии и неизвестные баги, вызывающие падения приложения.
Время ребуса: отгадайте его и десятипроцентная скидка на любой из курсов Skillbox ждёт вас прямо сейчас или проявите усидчивость и соберите ответы на все ребусы — эти скидки суммируются между собой (но ни с какими другими скидками на курсы Skillbox).
Однако, слишком медлить не стоит — промо работает до 30 августа 2018 года. Напомним, что тематика загадки — мобайл, а английские слова могут мешаться здесь с русскими, так что будьте внимательны! Отправьте заявку на курс, и когда с вами свяжется менеджер — назовите ему промослово, зашифрованное в ребусе (или — несколько!).
Формализация тестирования: тест-план, формат баг-репортов, отчётность
Для того, чтобы подготовиться к функциональному тестированию QA-инженер составляет тест-план. Это — документация, которая потребуется ему при тестировании продукта, список действий, которые ему нужно будет совершить. В тест-плане обозначаются сроки тестирования, описываются продукт или конкретная задача — для того, чтобы точно определить, что именно надо проверять. Детально описываются все основные тест-кейсы. Перечисляются виды тестирования, которые необходимы: функциональное и, например, нагрузочное. Описывается порядок автоматизации тех или иных кейсов и то, на каких этапах они будут автоматизированы.
Завершается тест-план описанием формата отчёта: нужно заранее объяснить, в каком виде будет предоставлен результат. Наиболее распространённым форматом отчёта является список тест кейсов со статусом их прохождения. Зная, насколько кейсы покрывают весь объём требований и прочитав отчёт, можно будет сделать вывод о текущем состоянии разработки приложения. Для этого достаточно будет посмотреть, сколько из них было успешно пройдено в той или иной сборке.
Финальной отмашкой, свидетельствующей о том, что продукт готов является статус “все требования покрыты кейсами, все кейсы пройдены успешно”.
Кроме того, в тест-плане формализуется формат отчёта по ошибкам. Это может быть баг-лист, список задач в трекере.
Задача тестировщика — предоставить наиболее полную информацию о качестве продукта всем участникам команды.
Что нужно знать и уметь, чтобы стать тестировщиком
В первую очередь тестировщик должен уметь думать и быть внимательным и усидчивым. Важен опыт — он позволяет накопить определённые наработки и закрепить знания процессов тестирования, превратив их в навыки.
Специалист по ручным тестам не обязательно должен уметь писать код и глубоко разбираться в архитектуре. Это никак не помешает ему проверять функционал и на прикладном уровне понимать принципы взаимодействия приложения и сервера.
Специалист по автоматизированному тестированию — это отдельная профессия, с абсолютно другим набором знаний. Качественное автотестирование — это не просто скрипты, но и понимание того, как приложение устроено изнутри, и специфические умения, вроде знания о том, как параллелить тесты или о том, как запускать их в облаке или на нескольких серверах. Только такой пул навыков позволяет с гордостью называть себя “автоматизатором с большой буквы”. Так что без знания языков, их фреймворков, принципов ООП и внимательной слежкой за развитием технологий настоящему автотестеру не обойтись.
Путь каждого тестировщика начинается с освоения теоретического базиса тестирования, получения первичных представлений о том, как приложение взаимодействует с сервером и со средой. Если эти знания есть, а вместе с ними человек обладает и очень серьёзным намерением учиться — он уже может считаться джуниор-тестировщиком. За группой таких новичков с горящими глазами закрепляется старший специалист — либо ведущий тестировщик, либо, если компания может себе это позволить — тренер, целенаправленно прокачивающий своих подопечных. Они объясняют джуниорам непонятные моменты и дают болевые задачи вроде прогонки фич по тест-кейсам. В процессе человек учится читать тест-кейсы и осваивает практические основы функционального тестирования. На этом этапе за джуниорами ещё нужно проверять качество проведённых ими тестов, проходя их вслед за ними.
Следующим шагом становится создание индивидуального (или коллективного, в зависимости от масштабов компании) плана по развитию, согласно которому начинающий тестировщик должен будет развиваться, осваивая новые знания и достигая определённых результатов за отведённые ему на это сроки. Именно это — путь к тому, чтобы стать специалистом миддл-уровня.
Миддл-тестировщик — это человек, который уже способен самостоятельно выполнять поставленные перед ним задачи, находить решения и вообще выполнять свою работу сознательно, а не слепо следуя установленным алгоритмам.
С развитием навыков тест-дизайна, познаний в функциональной и прикладной областях, а также освоении новых методик тестирования — которые теперь уже нужно развивать самостоятельно — происходит постепенная трансформация в ведущего специалиста. Теперь ему могут поручить ведение и поддержку таких же джуниоров, каким он сам раньше был.
Следующий уровень — это тест-лид. Он уже может управлять командой, в которую входят представители всех трёх предыдущих категорий, процессами которых он управляет и временем которых — распоряжается, в том числе участвуя в планировании глобальных процессов разработки, оценке трудозатрат и формировании бюджетов для своих команд.
Дальнейший вертикальный рост тим-лида — руководство отделом или переход в продук-менеджмент. Если же, человек стремится к новым знаниям, а не к новым административным позициям, то он может выбрать разработку, аналитику или такое направление, как DevOps, объединяющее в себе обязанности системного администратора, тестировщика и программиста.
Тестирование — лишь одна из многих областей мобильной разработки, которые мы рассматриваем в рамках курса “Fullstack-мобильный разработчик”. Сотрудничающие с нами профессионалы индустрии будут делиться с вами своим опытом и проверять ваши домашние задания, а итогом обучения может стать принятие на стажировку в крупную компанию. Приходите к нам учиться!
Skillbox рекомендует:
- Управление digital-проектами;
- Анимация интерфейсов;
- UX- дизайн.
Библиотека тестировщика: обзор полезных книг по тестированию ПО
Время на прочтение
7 мин
Количество просмотров 26K
В каждой профессии есть книги из категории «маст хэв» — те, которые любой уважающий себя специалист должен обязательно прочитать в целях самообразования. Какая полезная книга помогла бы углубить профессиональные знания тестировщика? Представляем обзор изданий, которые наверняка займут достойное место в библиотеке.
Если бы мы не писали обзор книг, а составляли их рейтинг, то на первое место с большим отрывом обязательно поставили бы книгу Ольги Назиной «Что такое тестирование. Курс молодого бойца». Да, это издание — для начинающих, для тех, кто хочет «вкатиться в профессию», но именно в этой нише конкурентов у нее практически нет.
И дело даже не в том, что книга последовательно, шаг за шагом вводит читателя в мир тестирования программ, а в том, как именно она это делает. При чтении книги невозможно отделаться от ощущения, что о секретах профессии тебе рассказывает лучший друг — настолько простым и понятным языком изложен материал. Автор приводит интересные примеры и истории из собственной практики, приводит аналогии, шутит, причем делает это действительно весело и непринужденно: вы не найдете здесь того натужного юмора, который встречается иногда в других технических книгах.
Но главное — картинки. Их очень много, из-за чего книга немного напоминает комикс, и предназначены они не столько для развлечения читателя (хотя картинки веселые!), сколько для лучшего запоминания материала. Главный герой книги Ольги Назиной — тестировщица по имени Катька, которая чуть ли не на каждой странице сталкивается с различными профессиональными задачами, решает сложные проблемы, общается с коллегами, разработчиками, пользователями… В общем, старается объяснить «на пальцах» сложные вещи — как изучить техническое задание, составить тест-кейсы и чек-листы, выделить классы эквивалентности, работать с баг-трекерами, автоматизировать тестирование, писать отчеты… В конце каждой главы приводятся вопросы для самопроверки и практические задания, которые можно выполнить, чтобы набить руку. Если набраться терпения пройти их все, получится портфолио, которое пригодится, например, при устройстве на работу.
В общем, это написанная простым и доходчивым языком книга-тренинг, выгодно отличающаяся по стилю и содержанию от классической технической литературы. К слову, автор этой замечательной книги есть на Хабре, и с ней вполне можно пообщаться — Ольга Назина охотно отвечает на вопросы читателей. Даже на самые заковыристые.
***
Еще одно полезное издание для начинающих — книга Билла Лабуна «Дружеское знакомство с тестированием программ». Она намного тоньше и лаконичней предыдущей, а форма арбуза на обложке, вероятно, намекает на форму головы неофита, которую та обретает при попытке усвоить кучу непонятных терминов из сферы тестирования. Все эти «непонятки» и призвана разъяснить книга: она рассказывает об основах профессии, о видах тестирования — дымовом, приемочном и исследовательском, о юнит-тестировании, о попарном, комбинаторном, стохастическом тестировании и тестировании на основе свойств, о тестировании производительности и безопасности. Отдельная глава посвящена приемам разработки ПО через тестирование.
Сам Билл Лабун — признанный эксперт в сфере качества ПО и преподаватель, обучающий студентов на факультете компьютерных технологий Университета Питтсбурга.
В общем, эта книга чуть более академична по сравнению с предыдущей и представляет собой неплохое справочное пособие по классификации тестирования, которое имеет смысл держать под рукой просто на всякий случай.
***
Обе упомянутые выше книги можно найти в книжных магазинах — разумеется, за деньги. Но есть и достойные бесплатные издания по этой тематике. Одно из них — это книга Святослава Куликова «Тестирование программного обеспечения. Базовый курс».
Да, это тоже пособие для начинающих, но, что называется, из категории «маст хэв». Книга постоянно обновляется, а ее автор обладает более чем десятилетним опытом обучения специалистов. Это издание часто рекомендуют новичкам, и не зря: здесь приводится разъяснение базовой терминологии, подробно описаны необходимые тестировщику навыки, дается классификация тестирования (есть даже здоровенная таблица с перечислением и разъяснением всех видов тестов). Кроме того, в книге кратко описаны правила составления тест-кейсов и чек-листов, приведены типичные ошибки при их разработке, и все это изложено доходчивым разговорным языком (правда, местами автор все же скатывается в академический стиль, но лишь местами). Очень важно, что за счет регулярного обновления книга не теряет своей актуальности.
***
Если вам лень читать толстые фолианты из категории «многабукв», у нас есть хорошие новости: в книге Романа Савина «Тестирование dot com» букв мало — она небольшая, но это ничуть не влияет в худшую сторону на ее содержательность. Книгу можно купить на бумаге или раздобыть в электронном виде — она присутствует на всех популярных литературных площадках.
Книга ориентирована в первую очередь на начинающих, на тех, кто желает освоить основы профессии. Издание выдержано в легком стиле, охватывает основные понятия в сфере тестирования ПО. В конце каждой главы приведены вопросы для самопроверки. В целом — неплохой вариант, если вы хотите не просто «вкатиться» в профессию, а понять, нужно оно вам или нет.
«До того как записался на курс по тестированию, изучал этот вопрос самостоятельно, по статьям и роликам на YouTube. Сейчас как раз начал читать книгу Романа Савина. Все описано доступно, понятно. Даже тот человек, который никогда не сталкивался с этим направлением, поймет, о чём там говорится», — рассказал Сергей Деянов, выпускник профессии
«Инженер по тестированию»
в Skillbox.
***
Книга Джеймса Уиттакера «Как тестируют в Google» вышла в свет уже довольно давно — в 2014 году, — но своей актуальности тем не менее не утратила. Это издание скорее заинтересует опытных тестировщиков, стремящихся изучить подход к тестированию в известной на весь мир корпорации. Если кратко — за качество продукта там отвечают все. Если не кратко — читайте книгу, процесс тестирования продуктов в Google там описан довольно подробно. При этом функции тестировщиков и разработчиков в корпорации совмещены: специалисты по тестированию сами улучшают продукт наравне с девелоперами, а программисты пишут юнит-тесты для своего кода. Зато никто не считает тестлаб вольером для дрессированных мартышек, которые только и умеют, что запускать автотесты. В общем, передовой опыт самой крутой IT-компании планеты наверняка будет интересен, хотя в небольших коллективах далеко не всегда применим на практике.
***
«Ключевые процессы тестирования» Рекса Блэка — это серьезное издание для серьезных людей, то есть для профессионалов, которые, что называется, «глубоко в теме». Книга сложная и тяжелая для восприятия, но если запастись корвалолом терпением и осилить её целиком, на страницах издания можно найти много ценной и полезной информации.
Автор описывает процессы тестирования, свойственные в первую очередь крупным командам и корпорациям, которые при работе над маленькими и скромными проектами не всегда применимы. Зато рассказ о фундаментальных подходах позволяет понять, «как это работает у больших ребят», и, возможно, перенять что-то полезное. В тексте встречаются занимательные и временами забавные истории о тест-менеджере Джамале, работающем над проектом «Суматра», которые периодически разбавляют довольно монотонное повествование. Описаны все стадии развития этого проекта — от идеи до завершения, что позволяет составить наглядное представление об этапах тестирования, да и вообще о жизненном цикле разработки сложного продукта.
***
Что ж, теперь от российских изданий давайте перейдем к англоязычным. Среди которых нельзя не отметить книгу Ли Копланда (Lee Copeland) A Practitioner’s Guide to Software Test Design, по мнению множества специалистов — лучшую книгу по тест-дизайну из представленных сегодня на рынке. Несмотря на то что эта книга на английском, написана она довольно простым языком, поэтому серьезных трудностей в процессе чтения представлять не должна. В книге подробно описаны два метода тестирования методом «белого ящика», семь — методом «черного ящика», приведено множество примеров тест-кейсов на все случаи жизни. В конце каждой главы даны вопросы для самопроверки. Специалисты по тестированию, прочитавшие это издание, единодушны: книга безусловно заслуживает того, чтобы стать настольной для всех, кто желает изучить тест-дизайн и углубить свои профессиональные знания.
***
Рон Петтон (Ron Patton), Software Testing — еще одна книга, содержащая огромный объем полезной информации и вопросы для самопроверки в конце каждого раздела. Рассчитана на начинающих и охватывает весь спектр основ тестирования ПО. Каждая тема в книге Петтона рассматривается очень подробно (в чем ее несомненное достоинство); это поможет новичкам освоить азы, а профессионалам — лучше уложить в голове технологические подходы к тестированию и описанные на страницах издания методики. Впрочем, добравшись до конца Software Testing, новички, скорее всего, уже перестанут быть таковыми, поскольку обретут необходимый запас теоретических знаний — останется только наработать практические навыки. В общем, книга крайне полезная, особенно для тех, кто находится на старте карьеры.
***
Кристин Жаквони (Kristin Jackvony), The Complete Software Tester: Concepts, Skills, and Strategies for High-Quality Testing — книга не только о тестировании, но и о тестировщиках, о тех знаниях и навыках, которыми должен обладать такой специалист. В издании подробно рассматриваются и практические аспекты: ручное разведочное тестирование, тестирование API, тестирование безопасности, — описаны основы автоматизации тестирования, рассказано об использовании инструментов для контроля версий. Автор дает читателю советы по созданию планов тестирования, формулированию стратегий и эффективной работе в команде. Ну и по традиции в конце каждой главы даются вопросы для самопроверки.
Самое интересное, что для подписчиков Kindle Direct книга бесплатна, поэтому если у вас есть учётка на Amazon, вы сможете насладиться творчеством Кристин, не потратив ни цента. Впрочем, по имеющейся у нас информации, одно из российских издательств сейчас готовится выпустить эту работу на русском языке. Так что, если вы готовы немного подождать, очень скоро можно будет ознакомиться с этой замечательной книгой в переводе.
***
Безусловно, мы рассмотрели в этом обзоре далеко не все доступные сегодня читателям издания по тестированию программного обеспечения. Мы не упомянули довольно популярные How to Break Web Software и How to Break Software Security (James A. Whittaker), Perfect Software: And Other Illusions about Testing (Gerald M. Weinberg), Exploratory Software Testing (James Whittaker). Однако описанные нами книги вполне могут занять достойное место в библиотеке тестировщиков — это тот «обязательный и необходимый» минимум, который следует прочитать всем, кто связан с этой профессией. Если у вас есть любимые книги по тестированию, о которых мы забыли рассказать, — обязательно делитесь своими отзывами в комментариях!
Работа тестировщика входит в пятерку самых популярных работ в сфере IT, согласно статистике за 2020 год. Рынок растет очень быстро, а IT-компании постоянно создают новые команды тестировщиков. А вот еще немного впечатляющей статистики – на тестирование уходит 50% всего времени и более 50% общей стоимости любого проекта по созданию софта. А это приличный бюджет. Это означает, что налаживание процессов тестирования позволит сэкономить не только время, но и деньги.
Сегодня тестированию обучают в некоторых университетах. Но поскольку это все еще молодая отрасль, будущие специалисты предпочитают знакомиться с инструментами для тестирования программного обеспечения на онлайн-курсах. Онлайн-курсы и самообразование – это самый короткий способ изучить тестирование и начать новую жизнь в профессии. Наше руководство содержит краткий гид по основным инструментам тестирования программного обеспечения.
Тестирование является важнейшим методом контроля качества. Под качеством программного обеспечения мы имеем в виду соответствие программного обеспечения заявленным и предполагаемым требованиям. Основная цель тестирования программного обеспечения состоит в проверке совпадений между фактическими и ожидаемыми характеристиками программы. Ручное и автоматическое тестирование – это два наиболее известных типа тестирования программного обеспечения. Оба типа моделируют возможные сценарии действий пользователей и проверяют, выполняются ли при этом требования. Но в чем разница между ними?
Типы тестирования
И ручное, и автоматическое тестирование являются частью контроля качества в процессе разработки программного обеспечения. Ручное тестирование подразумевает выполнение задокументированной процедуры. Устанавливается порядок проведения тестов и приводится список параметров. Поскольку процедуру выполняет человек, в ней могут содержаться заданные по умолчанию значения и ссылки на информацию, хранящуюся в другом документе.
Автоматизированная тестировка программного обеспечения снижает стоимость тестирования. На автоматизированную тестировку и устранение дефектов также уходит меньше времени, а инструменты по автоматизации снижают риски. Однако все перечисленное не значит, что автоматическое тестирование является универсальным решением. Если скрипты не включены в регрессионную или непрерывную интеграцию, предпочтительнее использовать ручную тестировку. Автоматизированная тестировка не подойдет, если скрипты временные или если автоматизация скриптов слишком сложная.
Выбор инструмента и способа тестирования зависит от ваших целей и от желаемого уровня тестирования.
А какие еще есть типы тестов?
При классификации типов тестирования можно использовать несколько подходов. Различают методы статического и динамического тестирования, в рамках которых используются разные методы.
При статическом тестирование не выполняется программный код. Статические методы тестирования могут быть как ручными, так и автоматическими. Их используют на ранней стадии жизненного цикла программного обеспечения и они являются важной частью процесса проверки качества. В некоторых случаях можно даже обойтись без использования компьютера, например, при проверке требований.
Динамическое тестирование – это метод, направленный на проверку функциональности программы. Он требует выполнения кода. Этот тип тестирования включает фактическую работу программы и определение ее функциональности для проверки того, оправдываются ли требования. Динамический тип тестирования направлен на тестировку программного обеспечения в режиме реального времени посредством предоставления входной информации и изучения результирующего поведения приложения.
Методы тестирования
Тестирование методом «белого ящика» и тестирование методом «черного ящика» – это ключевые методы тестирования. Разница между ними определяется наличием или отсутствием у тестировщика доступа к исходному коду программного обеспечения. В некоторых случаях он есть, в остальных тестирование выполняется через пользовательский интерфейс или интерфейс программного обеспечения, предоставленный модулем. Тестирование «белого ящика» типично для модульного тестирования, когда тестируются только определенные части системы. Это обеспечивает работоспособность и устойчивость компонентов системы. При тестировании «черного ящика» у тестировщика есть доступ к программному обеспечению только через интерфейсы, которые доступны заказчику и пользователю.
При тестировании методом «черного ящика» тестировщик знает только то, что приложение должно делать. В то же время он не может заглянуть внутрь и увидеть, как начальные значения преобразуются в окончательные. Тестирование методом «черного ящика» основано исключительно на внешних интерфейсах системы. Такой метод не требует знания внутренней структуры или всей системы.
Этот тип тестирования подразумевает процедуру написания или выбора тестовых примеров на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутренней структуры. Тестирование методом «черного ящика» выполняется с использованием спецификаций или других документов, которые описывают системные требования.
При тестировании методом «белого ящика» у тестировщика есть доступ к исходному коду приложения, он может изучить его и получить определенные подсказки. В этом случае он видит, как начальные значения преобразуются в окончательные. Тестирование методом «белого ящика» предполагает, что тестировщик знает внутреннюю структуру или устройство системы. Тестировщик выбирает входные значения на основе знаний о коде, который будет их обрабатывать. Знание возможностей тестируемой программы является обязательным для тестирования методом «белого ящика». Это тестирование, основанное на анализе внутренней структуры.
Как тестирование белого ящика, так и тестирование черного ящика предполагают, что код выполняется. Единственное отличие состоит в информации, предоставленной тестировщику. В обоих случаях мы имеем дело с динамическим тестированием. При статическом тестировании программный код не выполняется. В основе анализа программы лежит исходный код, рассчитанный вручную или проанализированный специальными инструментами.
Уровни тестирования
Что касается уровней тестирования, существует модульное тестирование, интегральное тестирование, системное тестирование и приемочное тестирование. Модульное тестирование позволяет проверять правильность отдельных модулей исходного кода программы. Оно включает написание тестов для каждой нетривиальной функции или метода. Это позволяет тестировщику быстро проверить, не привело ли следующее изменение в коде к регрессу, то есть не вызвало ли оно ошибки в уже протестированных частях программы. Более того, это облегчает выявление и устранение таких ошибок. Модульное тестирование – это тестирование отдельных модулей и компонентов программы. Обычно его выполняют сами программисты, это своего рода самопроверка. Обнаруженные таким образом дефекты немедленно исправляются.
Интегральное тестирование предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы. Есть разные уровни интегрального тестирования – тестирование компонентов интеграции и тестирование системной интеграции. Интеграция снизу вверх касается всех низкоуровневых модулей, процедур и функций, которые собираются вместе и затем тестируются. Такой подход считается удобным, если все или почти все модули разработанного уровня готовы. Интеграция сверху вниз подразумевает тестирование высокоуровневых модулей. Низкоуровневые модули добавляются один за другим.
Системное тестирование проводится на полной интегрированной системе. Его основная цель – проверить, соответствует ли система требованиям. Оно относится к тестированию методом «черного ящика» и, следовательно, не требует знания внутренней структуры. Системное тестирование делится на альфа-тестирование и бета-тестирование.
Приемочное тестирование – это процесс тестирования, направленный на определение того, соответствует ли система критериям приема. Решение касательно приема принимает заказчик или другое уполномоченное лицо. Приемочное тестирование проходит на этапе релиза продукта, так как его цель – определить готовность продукта. Для этого нужно пройти ряд тестовых сценариев и кейсов на основе спецификации требований к программному обеспечению. Такое тестирование является заключительным этапом перед запуском.
Итак, с чего начать изучение тестирования программного обеспечения? Лучший способ стать тестером – пройти онлайн-курс, который поможет вам понять, как создается программное обеспечение, с какими трудностями сталкиваются программисты и как выглядит процесс устранения ошибок. Наши курсы предоставляют качественное обучение от лучших инструкторов, поэтому присоединяйтесь к нам. Мы поможем вам изучить основы тестировки программного обеспечения и начать карьеру в IT.
Запись на курс Manual QA
В этом большом бесплатном учебнике по тестированию, ты выучишь основы тестирования программного обеспечения. Все материалы взяты с нашего сайта и расположены последовательно друг за другом — от основ до продвинутых тем. Учебник постоянно обновляется и дополняется новыми статьями.
Нужны ли мне какие-то знания для работы с учебником?
Учебник рассчитан на начинающих тестировщиков с небольшим опытом в QA (или вообще без опыта).
Содержание
- 👶 Основы тестирования
- ↔️ Типы тестирования
- 📄 Тестовая документация
- 📁 Тест-кейсы
- 🛠️ Техники тест-дизайна
- 🐞 Все о багах
- ⚙️ Автоматизация
- 🚄 Тестирование производительности
- 📱 Тестирование мобильных приложений
- 🛠️ Инструменты тестировщика
- 💬 Софт-скиллы
- 👨💼 Собеседование
- 🔥 Интересное
- ✅ Тесты для самопроверки
- 📚 Чтение для отдыха
👶 Основы тестирования
Основы профессии — разбираемся с основополагающими понятиями — что такое тестирование, из каких видов оно состоит. Смотрим, на каких этапах разработки применяется, изучаем этапы и уровни.
| Читать | Тестирование. Что это такое, описание, виды тестирования |
| Читать | Путь тестировщика: скиллы, зарплата, перспективы |
| Читать | Большая дорожная карта развития тестировщика |
| Читать | Семь главных принципов тестирования |
| Читать | STLC — жизненный цикл тестирования приложений. Этапы, критерии начала и окончания |
| Читать | V-модель тестирования |
| Читать | Этапы тестирования |
| Читать | Уровни тестирования |
| Читать | Функциональные и нефункциональные требования |
↔️ Типы тестирования
Разбираемся в видах и типах тестирования — важно понимать особенности каждого из них. Чем отличается модульное тестирование от smoke-тестирования? Что такое альфа-, бета-, гамма-тестирование? Чем функциональное тестирование отличается от нефункционального? Ответы на все эти и многие другие вопросы в статьях ниже.
| Читать | Виды и типы тестирования: подробный разбор |
| Читать | Тестирование белого ящика vs тестирование черного ящика |
| Читать | Тестирование серого ящика |
| Читать | Что такое ручное тестирование? |
| Читать | Что такое статическое и динамическое тестирование |
| Читать | Негативное тестирование: что это |
| Читать | Юзабилити-тестирование — большой гайд |
| Читать | Тестирование GUI: мини-гайд |
| Читать | Что такое функциональное тестирование? Мини-гайд |
| Читать | Нефункциональное тестирование — гайд |
| Читать | Интеграционное тестирование |
| Читать | Сквозное (E2E) тестирование |
| Читать | Что такое регрессионное тестирование? |
| Читать | Что такое системное тестирование? |
| Читать | Приемочное тестирование |
| Читать | Санитарное тестирование (sanity testing) — небольшой гайд |
| Читать | 𝛼 Что такое альфа-тестирование? |
| Читать | β Что такое бета-тестирование? |
| Читать | Что такое monkey-testing? Чем отличается от ad-hoc тестирования? Что такое torture тестирование? |
| Читать | Что такое smoke-тестирование? |
| Читать | Что такое риск-тестирование? |
| Читать | Что такое ad-hoc тестирование? |
| Читать | Что такое тестирование доступности? |
| Читать | Что такое кросс-браузерное тестирование? |
| Читать | Тестирование конфигураций |
| Читать | Тестирование масштабируемости |
| Читать | Инсталляционное тестирование |
| Читать | Тестирование пиков нагрузки |
| Читать | Исследовательское тестирование |
📄 Тестовая документация
Все о тестовой документации и о том, как ее писать.
| Читать | Что такое тестовая документация и зачем она нужна? |
| Читать | Тестовые артефакты |
| Читать | Что такое тест план и как его написать? |
| Читать | Что такое use case? Теория и примеры |
| Читать | Что такое тестовый сценарий? |
| Читать | Что такое user story и как ее писать? |
| Читать | Что такое стратегия тестирования |
| Читать | Матрица сопоставления требований с тест-кейсами |
| Читать | Стратегия обеспечения качества и вопросы в процессе ее составления |
📁 Тест-кейсы
Руководства по написанию тест-кейсов.
| Читать | Техники тест-дизайна: теория и примеры |
| Читать | Как писать тест-кейсы: полное руководство |
| Читать | Основные методики создания тест-кейсов |
| Читать | Тестовый набор (тест-свит, тест-сьют) |
Техники тест-дизайна
Классы эквивалентности, таблицы решений, предугадывание ошибок и многое другое — раздел о техниках тестирования.
| Читать | Что такое предугадывание ошибок? |
| Читать | Что такое классы эквивалентности? |
| Читать | Анализ граничных значений |
| Читать | Что такое таблица решений? |
| Читать | Попарное тестирование |
🐞 Баги
Баги, их классификация и баг-репорты — обо всем этом в разделе.
| Читать | Жизненный цикл бага |
| Читать | Как искать баги — гайд |
| Читать | Что такое баг-репорт? |
| Читать | Как составить баг-репорт: мини-гайд |
| Читать | Как написать классный баг-репорт |
| Читать | Серьезность и приоритет багов — в чем разница? |
| Читать | Верификация и валидация: что это и в чем разница? |
| Читать | Баг-трекинговые системы: Jira и альтернативные варианты |
⚙️ Автоматизация
| Читать | Что такое автоматизированное тестирование? |
| Читать | Что такое автоматизированное тестирование? Гайд по основам |
| Читать | Что такое ручное тестирование. Основные подходы и инструменты |
| Читать | В чем разница между ручным и автоматизированным тестированием? |
| Читать | Почему не получается автоматизация — 100 причин (на самом деле меньше) |
| Читать | Как не надо автоматизировать |
| Читать | Как стать автоматизированным тестировщиком? Небольшой план действий |
| Читать | Автоматизация кроссбраузерного тестирования на Java/Python/JS — гайд |
| Читать | Решаем, что и когда автоматизировать, и нужно ли |
| Читать | Как выбрать инструменты автоматизации (с таблицей) |
| Читать | Три типичных ошибки автоматизатора |
| Читать | Определяем, нужно ли автоматизировать тест-кейс? Чеклист, который вам поможет. |
| Читать | Признаки ХОРОШЕГО автотеста |
| Читать | Траблы автоматизации — как их избежать |
| Читать | Автоматизированное тестирование НИКОГДА не заменит ручное |
| Читать | Лучшие open-source инструменты для автоматизированного тестирования |
| Читать | Автоматизация: актуальные инструменты (и статистика) |
| Читать | 5 самых популярных инструментов автоматизации тестирования в 2022 году |
🚄 Тестирование производительности
| Читать | Тестирование производительности веб-сервисов — теория и инструменты |
| Читать | Что такое нагрузочное тестирование |
| Читать | Что такое объемное тестирование? |
| Читать | Что такое стресс-тестирование: мини-гайд |
| Читать | Тестирование стабильности |
| Читать | Тестирование производительности в Postman |
| Читать | Планируем нагрузочное тестирование |
| Читать | Топ-15 бесплатных инструментов для нагрузочного тестирования |
📱 Тестирование мобильных приложений
Обучающие материалы по мобильному тестированию.
| Читать | Тестирование мобильных приложений: шаги и процедуры |
| Читать | Большой гайд по тестированию Android-приложений |
| Читать | Appium — гайд |
| Читать | Автоматизация жестов в Appium: блиц-практикум |
| Читать | Моки в инструментальных тестах Android |
| Читать | Большой гайд по автоматизации в XCUITest |
| Читать | Подбор устройств для тестирования совместимости |
🛠️ Инструменты
| Читать | Chrome Developer Tools для тестировщика |
| Читать | Docker — быстрый гайд |
| Читать | Bugzilla: экспресс-гайд |
| Читать | Playwright: полный гайд + FAQ |
| Читать | Playwright: экспресс-гайд |
| Читать | SoapUI: тестирование SOAP и REST API |
| Читать | Puppeteer — большой гайд |
| Читать | Пять расширений Google Chrome для тестировщиков |
| Читать | Гайд по Selenium. Часть 1. Установка Selenium WebDriver |
| Читать | Большой гайд по тестированию с Postman для начинающих |
| Читать | TestNG — большой гайд |
| Читать | Тестирование производительности API с помощью K6 |
| Читать | Туториал по Pytest |
| Читать | 100 (да, сто) бесплатных советов по Java-инструментам QA |
| Читать | Что такое Cypress: Введение и архитектура |
| Читать | Как ускорить тесты Selenium — полный гайд |
| Читать | Ошибки в Selenium — гайд по exceptions |
| Читать | Плюшевый Cypress: 5 советов |
| Читать | Что удобнее, Cypress или Selenium |
| Читать | E2E-тестирование в Cypress |
| Читать | Бесплатные онлайн-генераторы тестовых данных |
| Читать | Десять классных генераторов тестовых данных |
| Читать | Автотесты и Docker: блиц-практикум |
| Читать | Обзор фреймворков для iOS тестирования |
| Читать | Как ускорить тесты с помощью сypress-grep |
| Читать | Регрессионное тестирование: подборка инструментов |
| Читать | Эмуляторы и симуляторы: в чем разница? |
| Читать | Playwright config — смотрим в деталях |
| Читать | Кажется, Playwright уже лучше чем Cypress |
| Читать | curl — учимся тестировать API |
💬 Софт-скиллы
| Читать | Как войти в QA: cоветы QA Lead |
| Читать | Пять технических и пять нетехнических навыков хорошего QA |
| Читать | Как стать QA-лидом |
| Читать | Как QA общаться с разработчиками? Что делать ✅ и чего не делать ❌ |
👨💼 Собеседование
Материалы для подготовки к собеседованиям — вопросы и ответы по самым разным темам.
| Читать | Что можно и чего нельзя делать на собеседовании по тестированию |
| Читать | Тестировщик без опыта — советы по резюме |
| Читать | Вопросы на собеседовании тестировщика — стажер/джуниор |
| Читать | Вопросы на собеседовании тестировщика: джуниор++/миддл |
| Читать | Собеседование тестировщика — cкользкие вопросы |
| Читать | Вопросы по SQL и базам данных на собеседовании тестировщика (+ ответы) |
| Читать | Собеседование QA — что спрашивают о CI/CD |
| Читать | О чем спрашивают на собеседовании QA Junior: Selenium |
| Читать | Собеседование QA: тестирование API |
| Читать | Идем на собеседование на позицию тестировщика — 36 частых вопросов по Postman |
| Читать | QA-интервью: как решить любую задачу |
| Читать | Метод STAR на собеседовании |
| Читать | Собеседование тестировщика в Евросоюзе и США/Канаде: вопросы |
| Читать | Тайтлы в QA |
🔥 Интересное
| Читать | Языки программирования, которые тестировщик обязан знать |
| Читать | Пирамида уровней тестирования — виды, типы, проблемы |
| Читать | Нестабильные тесты. Почему они существуют и что с ними делать |
| Читать | Тестирование API |
| Читать | ChatGPT для тестировщика — как создавать тесты и документацию |
| Читать | Экономия на тестировщиках? Что такое Lean QA |
| Читать | Вильфредо Парето говорит: сосредоточься на главном |
| Читать | Бритва Оккама: как тестировщик решает вопросы правильно и быстро |
| Читать | Что такое CI/CD (непрерывная интеграция и доставка) |
| Читать | Юнит-тесты. Очень глубокое погружение |
| Читать | Тестирование баз данных — полный гайд |
| Читать | Почему Google не нанимает тестировщиков |
| Читать | Причины провала ИТ-проектов |
| Читать | Методологии разработки ПО |
| Читать | Сбор требований — краткое руководство |
| Читать | Что такое тестовое покрытие (test coverage) |
| Читать | Покрытие кода |
| Читать | Релизим в пятницу без валидола — советы для безопасных релизов |
| Читать | Как ускорить регрессионное тестирование |
| Читать | Структуры данных — большой гайд |
| Читать | Что такое BDD? Опыт с Cucumber/Gherkin + вопросы на собеседовании |
| Читать | Контролируем тестовые девайсы (и тестировщиков) в Slack |
| Читать | Владелец продукта и скрам-мастер: в чем разница? |
| Читать | Советы для проведения эффективного ретро |
| Читать | Осваиваем Data-driven Testing в Selenium |
| Читать | Английский для тестировщиков. Грамматика с Джеймсом Виттакером, Ли Коуплендом и другими мэтрами тестирования |
| Читать | Большой гайд по Page Object Model |
| Читать | Юнит-тесты vs интеграционные тесты |
| Читать | JavaScript QA — делаем все правильно с самого начала |
| Читать | Кто такие стейкхолдеры? Определения, типы и примеры |
| Читать | Мутационное тестирование. Теория + практикум |
| Читать | Бэклог продукта и бэклог спринта: краткое руководство |
| Читать | QA-команда и DevOps: что делать |
| Читать | 10 советов по управлению проектами |
| Читать | Типичные вопросы для собеседования на проджект менеджера и как на них отвечать |
| Читать | Юнит-тесты и Jest: toBe or not.toBe |
| Читать | Как тестировать формы? Мини-руководство |
| Читать | В чем разница между QA и QC? |
| Читать | 13 вопросов и ответов на собеседовании на scrum-мастера |
| Читать | Борьба с задержкой тестов в Selenium: пример из практики |
| Читать | E2E-тестирование в Cypress |
| Читать | Параметризация тестов: JUnit |
| Читать | Искусственный интеллект в функциональном тестировании |
| Читать | Сказ о ненатуральном эджайле |
| Читать | Как тестировать GraphQL API? Гайд для начинающих |
| Читать | Введение в тестирование блокчейна |
| Читать | 6 готовых оправданий, чтобы не писать юнит-тесты |
| Читать | Что такое Test-Driven-Development? |
| Читать | Unit-тесты на фронтенде. Best practices |
✅ Тесты для самопроверки
| Читать | Тест по основам тестирования |
| Читать | Блиц-тест ISTQB — Основы |
| Читать | Тест по основам тестирования (in English) |
| Читать | Тестовый экзамен ISTQB Foundation Level (на английском) |
📚 Чтиво
По теме. Почему QA-инженеры (все еще) нужны и к чему приводит плохое тестирование.
| Читать | 7 эпичнейших багов в истории человечества |
| Читать | Баги войны |
| Читать | Баги войны: вторая часть |
| Читать | «Грудь выскочила наружу, не могу убрать ее обратно» — о багах в играх и отношении к джунам на примере Cyberpunk 2077 |
| Читать | В России растут зарплаты тестировщиков. Смотрим, кому, где и сколько платят |
| Читать | Тестирование легче программирования? Мой путь из программиста в QA |
| Читать | Обычный день твоего лида |
| Читать | Пузырь популярности ИТ скоро лопнет. Глобальное сокращение на горизонте |
| Читать | Тренды тестирования 2021. Правда и мифы |
#подборки
- 23 сен 2019
-
11
Учиться тестированию можно по-разному. Хорошие книги — источник базовых знаний и практического опыта экспертов.
vlada_maestro / shutterstock
Автор в сфере IT, digital, экономики и финансов. Ведёт некоммерческий проект для начинающих писателей «ЛитЦех».
Одна из лучших книг по тестированию программного обеспечения для начинающих. Книга рассматривает все основные понятия, необходимые для работы junior-тестировщика, и дает ответы на вопросы, с которыми часто сталкиваются новички. Форма изложения материала доступна людям без какого-либо опыта. Однако в конце книги есть главы, посвященные фреймворкам автоматизирования, которые предназначены уже для состоявшихся тестировщиков.
Это пособие для тех, кто только начинает свой путь в тестировании. Оно дает самые общие представления о профессии, погружает в суть процесса и описывает его простыми словами, без излишнего академизма и трудных для восприятия понятий. Учебник можно рассматривать как некий гейтвей в тестирование, поскольку автор знакомит читателя с основными терминами, соотносит англоязычные понятия с русскими, попутно раскрывая и объясняя каждое из них. Преимущество книги Романа Савина «tестирование dot com» еще и в русском языке оригинала, что исключает проблему неточностей перевода.
Фундаментальные концепции менеджмента бизнес-приложений
Книга больше подойдет не новичкам, а специалистам с опытом — как минимум проработавшим в профессии год и близко знакомым с тестированием. Ее можно назвать библией тестировщика: это объемный, сложный, охватывающий все концепции тестирования труд, требующий глубокого вдумчивого чтения. Из-за сложного тяжеловесного языка не многие доходят даже до середины текста.
Авторы рассматривают тестирование масштабно в связи с другими направлениями разработки, приводят много примеров из опыта реальных компаний и раскладывают по полочкам основы.
Технологии функционального тестирования программного обеспечения и систем
Классический монументальный учебник по поведенческому тестированию Бориса Бейзера. Книга посвящена базовым методикам тестирования приложений. Некоторые из них на сегодняшний день уже устарели, так как книга не переиздавалась с 2004 года, однако общие принципы и подходы остались прежними и все еще актуальны.
Учебник можно рекомендовать начинающим, если они готовы воспринимать серьезный научный стиль изложения материала. По глубине и методичности рассмотрения основных вопросов и понятий ей нет равных, поэтому она станет отличным подспорьем для желающих изучить тестирование досконально и с разных точек зрения.
Универсальный учебник, переживший третье переиздание на русском языке; в целом книге уже больше 30 лет, но она дополняется от издания к изданию. Несмотря на столь почтенный возраст, она не теряет в актуальности благодаря глубине изложенного материала. Книга посвящена не методикам или языкам тестирования. Авторы поставили своей целью рассказать об основополагающих принципах:
- тестирования мобильных приложений;
- тестирования веб-приложений;
- тестирования удобства использования;
- сквозного и гибкого тестирования;
- коллективного, то есть с привлечением пользователей, подхода к тестированию.
По уровню знаний и навыков она больше подходит начинающим специалистам, хотя может и значительно расширить кругозор уже работающих тестировщиков.
Оптимизация ресурсов и временных затрат на тестировании — важная и острая тема для команд разработки. Книга Рекса Блэка через контроль рисков рассказывает о 12 процессах тестирования.
Многим книга может показаться излишне подробной и затянутой, однако ее стоит прочитать прежде всего ведущим тестировщикам и тест-менеджерам. Они смогут адаптировать абстрактные советы на примере несуществующих американских компаний к российским реалиям и своей конкретной задаче, чтобы сэкономить время на тестировании ПО и сделать процесс разработки более эффективным.
Практическое руководство для тестировщиков ПО и гибких команд
Книга посвящена методике гибкого тестирования: это использование квадрантов гибкого тестирования, набор средств для него, требования к команде QA-специалистов, итерация гибкой разработки и факторы успеха применяемой стратегии. Рекомендуется ведущим тестировщикам и специалистам среднего уровня.
Без автоматизации в тестировании сегодня никуда: чем сильнее ускоряется темп разработки и растут объемы задач, тем больше командам требуются новые быстрые технологии.
Эта книга представляет собой полное руководство по применению приемов, методов и инструментов автоматизированного тестирования, охватывая весь жизненный цикл автоматизации. Для ее чтения и понимания уже нужна база, поэтому книга рекомендуется только работающим специалистам с опытом в качестве инструмента повышения квалификации.
Еще одна книга для сеньоров и ведущих тестировщиков. В отличие от пособий, где приводятся примеры из работы вымышленных компаний, в издании рассказывается о реальной организации процессов и управления командами тестирования в корпорации Google.
Книга будет полезна тем, кто мечтает там работать, так как содержит главы о прохождении собеседований и другие подобные рекомендации. Подача материала — легкая с профессиональным юмором, иллюстрациями и примерами. Оценивать ее стоит скорее как средство расширения кругозора, нежели учебное пособие, а читать рекомендуется на английском языке, хотя существует и перевод.
Книга привлекает практической направленностью: авторы с богатейшим опытом собрали 293 урока, где коснулись основных вопросов тестирования ПО. Будет полезна и для новичков, и для опытных специалистов.
Авторы дают конкретные практические советы по всем аспектам тестирования: планирование стратегии, методики и техники, правила написания отчетов, автоматизация, взаимодействие разработчиков и тестировщиков, документирование, управление командой и карьерный рост. Из-за особенности поурочной структуры ее можно читать с любого места.
Классический учебник Бориса Бейзера, хорошо известный за рубежом и у нас. Его отличает целостный и методичный подход к изложению информации, понятный язык и широкий охват тем тестирования.
Пособие не только поможет новичкам освоить профессию, но и останется с ними в качестве настольной книги тестировщика на долгие годы работы.
Книга содержит советы и четкие инструкции по тестированию мобильных приложений от практикующих специалистов. С помощью их рекомендаций, скриншотов и понятных объяснений начинающий легко разберется в процессе тестирования продуктов для операционных систем Android и iOS.
Базовая книга об атаках в тестировании программного обеспечения. Подходит и начинающим, и опытным специалистам, но первые испытают сложности из-за трудного языка. Для вторых же она идеальна и даст множество полезных знаний.
Ее можно перечитывать много раз и находить новые способы решения насущных задач. Автор рассказывает о различных типах атак: на сервер, на клиент, state based и других. Описание атаки состоит из вводной части, сферы применения и инструкции о том, как ее проводить.
Вторая книга Витакера — пошаговое руководство по тестированию безопасности приложений. Ее лучше читать после «How to break web software».
Подходит уже работающим специалистам с базовыми навыками в тестировании в целом, но не знающим ничего о защищенности.
Автор рассказывает о верхнеуровневых классах проверок, например, на уровне кода или GUI, и приводит 19 атак на защищенность приложения. Каждое описание атаки или инъекции состоит из вводной части, описания случаев применения и руководства по нему.
Очень интересная книга, которая понравится всем уже работающим в команде тестировщикам, а новичков может спустить с небес на землю. Увы, только в учебниках и абстрактных компаниях проекты всегда задокументированы, а в архитектуре царит полный порядок. Эта книга рассказывает о жестокой реальности и развенчивает иллюзии в тестировании.
Автор приводит реальные типичные ошибки в подходах, а учиться на ошибках — самое полезное дело. В совместной работе специалисты часто переводят стрелки друг на друга и отказываются фиксить и документировать баг, ссылаясь на то, что это не их зона ответственности. Что с этим делать и как с этим жить — в том числе рассказывает Gerald M. Weinberg.
Мы предложили вам 15 испытанных временем книг по тестированию программного обеспечения, которые помогут освоиться в этой профессии. А еще рекомендуем наш обучающий курс по тестированию. Здесь в доступной интерактивной форме под руководством наставников вы изучите актуальный материал, научитесь использовать его на практике и получите новую профессию с возможностью трудоустройства.
Научитесь: Профессия Инженер по тестированию
Узнать больше