Всем привет! Меня зовут Екатерина и я QA-специалист в компании SimbirSoft. Я уже 7 лет занимаюсь обеспечением качества IT-продуктов, и за это время прочитала множество книг и пособий. Многим книгам по QA уже много лет, а новинки появляются достаточно редко. В январе 2024 года на русском языке вышел «Идеальный тестировщик» Кристин Джеквони — поэтому я сразу обратила внимание на эту книгу. Поделюсь с вами своей оценкой и выводами — что в ней есть полезного и чего не хватило.
Немного об авторе «Идеального тестировщика»
До тестирования Кристин Джеквони работала в сфере музыкального образования. В IT начинала с должности инженера по контролю качества, после была руководителем отдела контроля качества, менеджером по контролю качества и SDET, а в настоящее время является главным инженером по качеству в компании Paylocity. Ведет авторский блог «Думай как тестировщик» и пишет книги.
Разберемся, для кого эта книга
Книга состоит из 12 частей:
Почему мы тестируем
Ручное тестирование
Как работают приложения
API-тестирование
Мобильное тестирование
Тестирование безопасности
Тестирование производительности
Тестирование юзабилити и доступности
Основы разработки программного обеспечения
Автоматизированное тестирование
Стратегии тестирования
Гибкие навыки для тестировщиков
Сама автор говорит, что книга идеальна как для начинающих тестировщиков ПО, так и для опытных специалистов, желающих восполнить пробелы в знаниях. А также она предполагает, что книга может быть интересна программистам, которые хотят думать как тестировщик.
Что мне понравилось в «Идеальном тестировщике»
Книга легко читается
Благодаря коротким главам, в которых все емко изложено, книга воспринимается легко. Кристин приводит много случаев из своей практики, поэтому после прочтения кажется, что ты на самом деле просто поговорил с коллегой-тестировщиком.
Затронуто много тем
Кристин рассуждает, зачем вообще нужно тестировать ПО, как проводить ручное тестирование функциональностей и как работают приложения, рассказывает как проводить API- и мобильное тестирование, тестирование безопасности, производительности, юзабилити и доступности. Также есть главы по основам разработки ПО и автоматизированного тестирования. В завершении автор рассказывает про стратегии тестирования и софтскилы для тестировщиков. Одновременно это можно отнести и к минусу книги, так как многие темы описано поверхностно. Но поскольку книга больше ориентирована на начинающих специалистов, полезно узнать, из чего вообще состоит тестирование. Понятно, что прочитав главы про автоматизацию, нагрузочное тестирование или тестирование безопасности, вы не станете в этом профессионалами, но это может сподвигнуть вас на изучение этих аспектов более подробно в других источниках.
Есть чек-листы для проверки отдельных функций
В книге много небольших глав, в которых собраны подсказки для тестирования тех или иных функций — например, тестирование полей даты, полей телефонных номеров, форм, советы по загрузке файлов и так далее. Возможно, для более опытных специалистов многие советы будут очевидными, но для начинающих собрано много полезной информации.
Подробные главы про API-тестирование
Мне очень понравились главы про API-тестирование. Здесь есть и скриншоты из Postman с подробными описаниями, куда нужно нажимать, чтобы начать пользоваться этим инструментом, и даже есть ссылка на тестовый сайт для того, чтобы на нем тренироваться. Я думаю, что для начинающих это очень полезно.
Еще Кристин написала, как тестировать те или иные запросы, создавать автоматические тесты в Postman, как использовать переменные. Думаю, что даже человек, который ни разу не занимался тестированием API, смог бы уже начать тестировать после прочтения данной главы.
Много примеров из личного опыта автора
Мне понравилось, что автор приводит много примеров из личного опыта. Она рассказывает как о своих успехах, так и о провалах. За счет этого появляется ощущение диалога с коллегой, ты понимаешь, что все могут ошибаться и это нормально. А еще наталкивает на мысль записывать свои успешные и не очень кейсы в работе, чтобы поделиться ими когда-нибудь.
Почему я не советую эту книгу тем, кто совсем ничего не знает про QA?
Я согласна с автором, что книга для начинающих QA-специалистов, но все-таки для тех, кто верхнеуровнево уже знаком с этим IT-направлением. На мой взгляд, в ней отсутствуют важные темы для начинающих:
Не хватает погружения в специальность
Практически в самом начале идут главы «Тестирование тестового поля» и «Сломайте свое приложение с помощью одного странного способа». Если данную книгу возьмет человек, который только хочет войти в QA, у него может сложиться впечатление, что тестирование — это только про «сломать функциональность», а не про обеспечение качества в целом.
В начале хотелось бы видеть главы про процессы тестирования, базовую терминологию, о роли QA на проекте и тех, кто еще входит в команду разработки.
Не хватает глав про теорию тестирования
В книге много шпаргалок о том, как тестировать, но нет глав с описаниями техник тест-дизайна, видов и уровней тестирования, работы с требованиями, документацией. Книга больше не про фундаментальные знания, а про практический опыт автора.
Нет информации о том, как оценивать время для выполнения задачи
В главе «Вопрос времени» автор размышляет о том, какие задачи стоит автоматизировать, а в главе «Тайм-менеджмент для тестировщиков» написаны стратегии, как успевать выполнять задачи. Но нет главы, которая бы описывала, как правильно оценивать задачу.
Еще чуть-чуть «минусов» книги
Также в «Идеальном тестировщике» есть несколько, как мне кажется, «вредных советов», и начинающие специалисты могут попасть в неловкую ситуацию, воплотив их в жизнь:
«Не хватает времени? Привлекайте разработчиков и других членов команды»
В главе «Что тестировать, когда на тестирование не хватает времени» есть совет
Привлекайте к тестированию разработчиков и других специалистов, если не хватает времени на тестирование.
Как по мне — это не жизнеспособный совет.
Если ваши члены команды понимают, что вам не дали достаточно времени на тестирование, они будут рады помочь вам.
– пишет Кристин. Далее она пишет, что при делегировании сценариев разным людям из команды «мы бы могли протестировать в четыре раза больше сценариев, чем я протестировала бы в одиночку».
У всех членов команды есть своя работа и свои сроки ее выполнения. И нельзя просто взять и попросить помочь выполнить тебе твою работу.
Организовать «охоту за дефектами»
Также Кристин советует организовать охоту за дефектами, в ходе которой все сотрудники компании будут искать ошибки.
Не смущайтесь, если кто-то найдет то, что вы пропустили. Когда мы тестируем одно и то же снова и снова, у нас иногда замыливается глаз.
Да, иногда это практикуется, но нужно понимать, что такие действия обязательно должны быть согласованы. Нельзя просто взять и написать в рабочий чат: «Ребята, посмотрите, нет ли в этом приложении дефектов».
Веcти чек-лист в Excel и Confluense
Мне показалось странным то, как Кристин Джеквони советует организовывать тест-планы (как я поняла, это что-то вроде чек листа). Она предлагает писать этот чек-лист с проверками в электронных таблицах. Для личных целей она использует Excel, а если нужно делиться с кем-то из команды, то использует таблицу в Confluence.
Из своего опыта могу сказать, что обычно в компаниях не приветствуется использование электронных таблиц, чек-листы и тест кейсы ведутся в Test Management System (TMS). Поэтому когда вы приходите в компанию, нужно узнать, в какой TMS ведется документация, а не вести ее в Excel только потому, что так удобнее.
Составлять отчеты о тестированию
В главе «Шесть шагов для написания эффективного отчета об ошибке» Кристин пишет также о том, как правильно составлять отчет в табличке. Но если вы ведете документацию в ТMS, составлять дополнительно какой-то отчет не требуется (если нет иных правил на вашем проекте). Например, я только на одном из 10 проектов встречала требование дополнительно составлять отчет. Обычно достаточно заполнить результаты прогона кейсов/чек-листа, проставив «пройден\не пройден» (зависит от выбранной TMS). Если вам не понятно, нужна ли какая-то дополнительная отчетность, лучше уточнить данный момент на старте работы.
«Нет необходимости писать тест-кейсы»
Кристин Джеквони говорит, что она не пишет пошаговых инструкций (тест-кейсов):
Если вы не пишете план тестирования для человека, которого никогда не видели, с которым никогда не будете общаться и который никогда не видел приложения, в этом нет необходимости.
Тест-кейсы долго писать и сложно поддерживать в актуальном состоянии, все так! Но если вы новичок и пришли на какой-то проект, где пишут подробные тест-кейсы, я не советую с ходу критиковать этот процесс и самостоятельно переходить на чек-листы. Нужно понять, почему в данном случае такой порядок работы — возможно, что проект сложный, присутствует текучка кадров, в таких случаях тест-кейсы необходимы.
Подведем итог
Резюмируя, могу сказать, что книга больше подойдет для начинающих специалистов, которые уже знакомы с теорией тестирования, с базовой терминологией и имеют представление о процессе разработки и роли QA в команде.
Рекомендую читать «Идеального тестировщика» после других книг для начинающих. Например, можно начать с книг Ольги Назиной «Тест-дизайн. Практическое руководство для начинающих» и «Баг-трекинг: локализация и оформление дефектов», а также с книги Святослава Куликова «Тестирование программного обеспечения. Базовый курс».
Книгу Кристин Джеквони можно назвать сборником заметок тестировщика. На мой взгляд, ей не хватает глубины и фундаментальности, но при этом есть полезная информация, которую можно взять на заметку. Отдельно отмечу, что автор рассказывает про автоматизированное тестирование и дает советы, как правильно писать код для тестов. Но если вы не автоматизировали раньше, вряд ли «Идеальный тестировщик» поможет вам начать автоматизировать тесты.
Я поставила книге 3 балла из 5. А как вы ее оцениваете, если тоже читали? :)
Полезные ссылки:
Локализация дефектов и оформление баг-репортов
Когда метрики тестирования бесполезны
Спасибо за внимание!
Больше полезных материалов для QA-специалистов читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.
Комментарии (4)
ivaniksanov
21.08.2024 13:39«Не хватает времени? Привлекайте разработчиков и других членов команды»
Как по мне этот совет имеет место быть. На своем опыте могу сказать, что при диком регрессе не остается времени качественно протестировать. Если разработчик отдает вам задачу намного позднее, чем вы ожидали, то можно договориться на дейли при всех и внедрить практику «Если задерживаешь задачу, то будь добр проверить как это работает самостоятельно»
Есть такое понятие как success test - разработчик проверяет то, что по его мнению он и задумывал реализовать. Но это не дает право не перепроверять за разрабом) Это лишь гарантия того, что вы не вернете задачу на доработку в первый час тестирования функционала.
pv_belov
21.08.2024 13:39Кристин молодец, она поняла смысл бытия.
«Не хватает времени? Привлекайте разработчиков и других членов команды»
Активно тестируем некоторые сценарии совместно, каждый со своей колокольни может подсказать что и почему, админы по своей части, поддержка по своей
Организовать «охоту за дефектами»
Сомнительно, но окей, главное что баг найден и важно что не пользователем )
Веcти чек-лист в Excel и Confluense
Я разные проекты повидал, но тысячи тестовых кейсов и десятки людей их поддерживающих - работа в стол. Расширенных чек листов хватает в большинстве случаев + это экономия ресурсов как денежных, так и человеческих, штат раздувать зачем..
Одни пишут тест кейсы, вторые их забраковывают, третьи их фиксят, четвертые амиго расставляют приоритеты, и пока до тестирования дойдёт, уже функционал свой жизненный цикл закончит )))
Составлять отчеты о тестированию
Мы на своих проектах отдельно формируемый отчёты которые в том числе содержат в себе результаты всех прогонов (не особо нравится но производство требует)
«Нет необходимости писать тест-кейсы»
Поддерживаю, но считаю необходимо делать инструкции в том же конфлюенс а в чек листах например на них ссылаться
За обзор спасибо!)
VeraKosh
Наконец-то что-то новое в базовом списке книг)