Что такое ручное тестирование
Вручную или автоматически: Пара слов о тестировании приложений
Автоматизированное тестирование — это одна из самых обсуждаемых тем среди инженеров по контролю качества. Новые системы тестирования программного обеспечения появляются постоянно, и каждый новый фреймворк получает титул лучшего.
Однако автоматизированное тестирование основывается на предположении, что программа используется так, как это задумали разработчики. Если полагаться только на автоматические тесты, то вскоре в коде появятся ошибки, и в то же время вы получите слабое представление о качестве интерфейса приложения.
Что касается ручного тестирования, то ему уделяют всё меньше внимания, поскольку такой процесс изнуряет сотрудников, а на роль исполнителя подойдет только специалист с особым складом ума. Однако «ручные» тесты отнюдь не уступают автоматизированным. Дело здесь в том, что подходы обладают разными областями применимости, поэтому сегодня мы рассмотрим некоторые достоинства и недостатки каждого решения.
Автоматизированное тестирование
По мнению Сары Фитжи (Sarah Fittje), инженера контроля качества в компании Project A Ventures, если тест подразумевает выполнение большого числа повторяющихся задач, то его имеет смысл автоматизировать. Классический пример — регрессионное тестирование, позволяющее обнаружить серьёзные баги, поэтому его важно регулярно проводить в полном объеме до запуска конечного продукта (кстати, если вам интересно, можете почитать руководство для QA-специалистов от Сары, его вы можете найти по ссылке).
При этом не стоит думать, что настройка автоматических тестов позволит серьезно сэкономить. Написание и поддержка написанных скриптов требует определенных навыков в области QA, которыми обладают не все тестировщики, следовательно, компании придется платить своим специалистам больше (однако штат тестировщиков все же удастся сократить).
Также стоит отметить, что достаточно сложно внедрять автоматизированные тесты для большого приложения с большим функционалом – так вы рискуете потерять видение общей картины и не сможете покрыть тестами весь функционал. Однако настраивая систему автоматизированного тестирования с первых дней проекта, вы получаете возможность ускорить циклы контроля качества и наладить последовательную проверку работы приложения.
Однако важно понимать, что автоматизированное тестирование не сможет помочь в определении недостатков внешнего вида интерфейса и качества взаимодействия пользователя с продуктом. Рассмотрим направления для применения автоматизации:
Тестирование графического интерфейса
Этот тип тестирования нацелен на проверку front-end-части приложения. Без помощи автоматизации очень трудно учесть все возможные комбинации взаимодействия пользователя с интерфейсом в веб-браузерах, мобильных устройствах и прочих системах (важно понимать, что такой тест не сможет оценить UX, как было отмечено выше).
Регрессионное тестирование
С помощью этого типа тестирования разработчики находят баги, вызванные улучшениями функций приложения. Под давлением частых обновлений разработчикам приходится трудиться в бешеном ритме и иногда идти на компромиссы, чем непременно пользуются баги, «закрадываясь» в код программного обеспечения. Вручную отследить недочеты каждого релиза достаточно проблематично.
Функциональное тестирование
Это тестирование для проверки выполнения функциональных требований, то есть работает ли приложение в соответствии с ожиданиями. Определяется, насколько точно реализуются задуманные функции, проводится анализ на соответствие стандартам, оценивается защищённость решения. На повторение функционального тестирования уходит много времени, даже при небольшом изменении в приложении, поэтому выполнять все действия «руками» может быть накладно.
Ручное тестирование
Автоматизированное тестирование помогает добиться высокого качества, но на данный момент оно ещё не заменило ручные тесты полностью. Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.
Пока пользователь привыкает к приложению, он способен ошибаться, не завершать нужные шаги, вводить неожиданные значения и так далее. Пользователи знают гораздо меньше о вашем продукте, но в итоге именно они будут им пользоваться. Поэтому клиентское одобрение — самый ценный индикатор качества интерфейса.
Когда для оценки работы программы ключевую роль начинают играть поведенческие особенности человека и интуиция, то стоит обратить внимание на ручное тестирование — здесь важнее поставить себя на место пользователя. Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.
Пара юзкейсов ручного тестирования:
Юзабилити-тестирование
Это тестирование служит для проверки удобства использования приложения с точки зрения пользователя. Такую расплывчатую по своим целям задачу компьютер решить не может — машине нужны четкие формулировки.
Ad hoc тестирование
Разовое тестирование, направленное на проверку одного аспекта программы. Для такого типа тестирования нет формально определённых правил, оно проводится импровизационно — тестировщик может использовать любые доступные средства для поиска багов. Фактически ad hoc тесты – это попытка «угадать» возможную ошибку.
Комбинированный вариант
Как мы отметили выше, разные типы тестирования обладают разными сферами применимости. Автоматические тесты не заменят ручные, но они могут быть использованы для экономии рабочего времени при отработке больших однообразных наборов действий. Ручное же тестирование выполняется долго, но без него не обойтись, если вы хотите добиться высокого качества продукта. На данный момент только комбинация этих подходов способна обеспечить высокие стандарты по отношению к функциональности и удобству использования продукта.
В качестве примера такого подхода Сара Фитжи приводит процесс тестирования онлайн-магазина natue, когда после успешного внедрения новых функций в тестовом проекте, QA-команда запускала автоматизированное регрессионное тестирование.
«Пока выполнялась автоматизированная проверка, мы одновременно проводили ручное тестирование новых функций, учитывая промежуточные результаты регрессионного теста, – рассказывает Сара. – Если во время ручного или автоматизированного тестирования обнаруживались баги, то они исправлялись, а тесты запускались заново». Если же все проходило успешно, то команда Сары повторяла проверку уже перед самим запуском финальной версии.
Еще один пример приводит Стивен Аллен (Steven Allen), инженер компании TestGrid.io. Он говорит, что в iOS полноценное автоматизированное тестирование долгое время было недоступно. Несколько лет назад Apple начали выпускать инструменты для автоматизации, но они пока что не совершенны. Поэтому использовать только средства автоматизации не получается – приходится прибегать к ручному тестированию.
Разработчики автоматизируют тесты, чтобы работать эффективнее и успевать больше, но нельзя описать скриптами все возможные варианты использования приложения и учесть все ошибки. Некоторые вещи очень легко пропустить – например, если на экране входа появилось лишнее поле ввода пользовательского имени, но при этом всё остальное работает правильно.
«Очень сложно написать идеальный код для автоматических тестов, – говорит Джозеф Миллар (Joseph Millar), специалист отдела контроля качества компании Lucid Software. – Если разработчик допустит ошибку в скриптах, он рискует пропустить большой пласт ошибок, тогда как при ручном тестировании эти недочеты, скорее всего, будут обнаружены. Поэтому так важно использовать оба метода при разработке приложений. Один для экономии времени, второй для «шлифовки».
Ручное тестирование
Ручное тестирование программного обеспечения – это процесс проверки ПО, выполняемый специалистами вручную. Это значит, что для его проведения не используются какие-либо специальные автоматизированные средства.
Программное обеспечение проверяется инженерами по тестированию, которые берут на себя роль конечных пользователей, моделируют ситуации в соответствии с тестовыми сценариями и фиксируют результат. Задача ручного тестирования программного обеспечения — выявить любое поведение, отличающееся от ожидаемого пользователем. Это важный этап обеспечения качества ПО, который направлен на тщательное исследование программного кода и выявление ошибок в работе систем.
Ручное тестирование может проводиться в рамках регрессионного (тестирование различных изменений), интеграционного (взаимодействие с остальными системами и ПО) и при системном функциональном тестировании.
Ручное функциональное тестирование ПО
При ручном функциональном тестировании (РФТ) проверка различных функций ПО осуществляется тест-кейсами. Основная цель РФТ — определить, насколько разработанное программное обеспечение соответствует функциональным требованиям, то есть способно ли оно при определенных условиях решать задачи, необходимые пользователям.
Ручное и автоматизированное тестирование программного обеспечения
В основном для функционального тестирования используются именно ручные тесты, ведь их легче адаптировать под нужные цели и задачи. К тому же, ручные тестировщики могут выявить дефекты, которые не предполагались (увеличение тестового покрытия), и увидеть то, что могло быть не предусмотрено тестовыми сценариями. Однако, на крупных и длительных проектах, где может быть много повторяющихся тестов, все же целесообразнее использовать автотесты.
Для автоматизации тестирования сначала разрабатываются ручные тесты, а затем специальная программа-робот, имитируя взаимодействия программного обеспечения и пользователя, проверяет правильность работы и фиксирует все несоответствия. Автоматизированные тесты выполняются уже без привлечения инженеров по ручному тестированию и не позволяют выйти за рамки базовых сценариев.
Ключевые преимущества ручного тестирования
Благодаря ручному тестированию можно снизить количество ошибок, выявить и устранить «узкие места», обеспечить стабильную работу систем, оценить удобство эксплуатации, и, в результате, получить более качественный продукт, удовлетворяющий ожидания пользователей.
Основные этапы ручного тестирования программного обеспечения
Инструменты ручного тестирования
Поскольку ручное тестирование программного обеспечения довольно гибкое, оно допускает использование большого количества разнообразных инструментов.
Управление тестированием обычно ведется в специализированных системах, вроде HP ALM, IBM Rational Quality Manager, MS Team Foundation Server, TestRail, TestLink, Jira и Redmine.
Для поиска, конвертации и сравнения файлов могут использоваться Notepad++, Intype или PSPad. Среди файловых менеджеров популярностью пользуются Total Commander, trolCommander, Free Commander и Far Manager. Из XML-редакторов часто используются Altova XML Spy, Xsemmel и XMLPad.
Из инструментов для создания скриншотов, видео, скринкастов и анимации (gif) можно выделить Snagit, ScreenHunter, Monosnap, Snipping Tool, GreenShot, Recordit, CamStudio, Jing, LICEcap и Ashampoo Snap. Для сравнения изображений и других графических файлов инженеры по ручному тестированию часто используют FastStone Image Viewer, ImageDupeless и ImageDiscerner.
Протестируем системы любой сложности: поисковые, биллинговые, процессинговые, SAP и многие другие
Ручное интеграционное тестирование в банковском секторе. Что внутри?
Введение
Не всегда, приходя на крупный новый или старый проект, новый тестировщик знает с какой стороны подойти к началу процесса тестирования. Иногда нет куратора, иногда не настроен процесс коммуникации. И вы можете хоть сто раз плюнуть в компанию и пойти искать новую, благо рынок сейчас в дефиците. Но гораздо интереснее будет получить бесценный опыт становления вас как самостоятельного и понимающего члена команды. Данная статья будет посвящена теории тестирования реализаций системы антифрод в одном из крупнейших банков РФ. О чем мы поговорим в этой статье? Об особенностях архитектуры enterprise. Про основной инструментарий и про советы тем, кто захочет прийти в сферу интеграционного тестирования бэкэнда в крупную компанию.
Примеры будут браться из работ по интеграции антифрод-системы.
Инструментарий для тестирования
На собеседованиях на данную позицию кроме основных обязательных знаний по теории тестирования и работы с базовым инструментарием тестировщика также требуется набор знаний, нужных для понимания работы протоколов по которому это взаимодействие происходит. А также набор инструментов. Что в этот набор входит:
SOAP (состав xml сообщений);
REST (часть взаимодействий идет через OpenAPI), JSON;
принципы ssl шифрования. Шины любят общаться безопасно, поэтому требуются знания по генерации ключей;
putty + bash + linux. На некоторых сложных интеграциях нельзя слать сообщения напрямую из системы-источника (речь о way4 и транзакциях процессинга). Поэтому, дружба с linux приветствовалась на уровне “знаю как подключаться по ssh и запустить модуль с параметрами”. Для генерации ssl, кстати, тоже надо будет это знать;
Понимание клиент-серверной архитектуры и OSI на базовом уровне.
Не обязательна практика работы, но всегда хочется, чтобы кандидат был вовлечен. Любой Pet-проект подойдет чтобы рассказать о практике работы со всем вышеназванным. Связка virtualBox + http сервер + проект Postman. Или озвучивание сервисов с открытым API.
Архитектура
Встречается различный подход к документации на проектах. Кто-то требует документировать свою работу, кто-то работает по гибким методологиям и не ставит составление документации в приоритет. В общем, документация может быть, а может и не быть. И если вы не уточнили про наличие оной на собеседовании, то не удивляйтесь. Найдите сотрудника (PM, Тимлид, Техлид), который может обрисовать технологический стек и постарайтесь накидать для себя схему архитектуры сами. Потом, показывая картинку, легче понимать передвижение потоков данных и разговаривать с остальными членами команды на одном языке.
Пример состава тестового контура:
Ядро антифрод системы (+ web интерфейс к ней для настройки политик).
БД с данными транзакций, клиентов и другими, для корректных расчетов системы антифрод и применения политик скоринга.
Остальные смежные системы, требуемые для тестирования
Смежные системы общаются с шиной посредством коннекторов. Для каждого коннектора на шине пишется отдельный сервис, который конвертирует данные из формата, понятного системе-источнику, в формат понятный шине. Чаще всего это xml.
После этого документ помещается в очередь, из которой шина отправляет данные в систему-приемник. В нашем частном случае это была антифрод-система.
Для приема и корректной обработки данных из каждой системы-источника на стороне сервера антифрод пишется отдельный микросервис. Микросервисы выполняют атомарные функции доставки данных в ядро и передачу скоринговых баллов из ядра с вердиктом антифрода обратно в шину. Также могу валидировать входящие и исходящие данные в соответствии с ТЗ. При этом результаты опционально, по согласованию с заказчиком, логируются в базу данных для последующего анализа.
Процессы тестирования
Тестирование нового микросервиса включает в себя следующие этапы:
Анализ технического задания на микросервис (разрабатывается заказчиком совместно с аналитиком);
Декомпозиция требований и составление матрицы соответствия требований;
Написание тест-плана для согласования с заказчиком. Можно найти шаблон в интернет-пространстве, если такового не имеется в наличие;
Написание тест-кейсов согласно матрице. Используется любая система управления тестированием. В корпоративном секторе сейчас распространена TFS(Azure DevOps Server)
Собственно, прохождение тест-кейсов и заведение дефектов;
В корпоративном секторе роль заказчика часто принадлежит внутреннему бизнес-подразделению и лицом принимающим решение со стороны бизнеса является его руководитель. Он же ставит бизнес-задачу на разработку интеграционного взаимодействия. Например, руководитель департамента МСБ (малый-средний бизнес). Тестовые данные в данном случае могут предоставлять сотрудники подразделения-заказчика.
Бизнес-задачи для системы антифрод может звучать так:
“Требуется, чтобы все платежи от юридических лиц проверялись в системе и отправлялись на ручную проверку\блокировались при значении скорингового балла более 60”.
“Требуется блокировать все запросы от ИП с просрочкой более 1 месяца”
End-2-end тестирование отличается тем, что к обычному процессу добавляется этап согласования тест-плана не только с заказчиком, но и с командой тестирования сервиса-источника. А также в процессе прохождения тест-кейсов все тестовые данные(запросы) генерируются ролями в системах-источниках. У каждой информационной банковской системы есть своя команда(внутренняя или внешний интегратор), разрабатывающая новые функции, и также имеет своих разработчиков и тестировщиков. E2E проводится совместно с ними.
Например: Тестировщик Диасофт от роли “Оператор” отправляет платеж по карте мир от одного юрлица к другому.
Команда взаимодействия
Тестировщики системы взаимодействуют в работе со следующими ключевыми сотрудниками:
Менеджер технологической инфраструктуры (возможно DevOps)
Аналитик со стороны разработки
Аналитик со стороны заказчика (опционально)
Разработчик со стороны сервиса-источника
Разработчик со стороны антифрод
Разработчик со стороны шины
Набор ролей соответствует стандартному набору ролей в жизненном цикле ПО по любой методологии.
Базовый сценарий тестирования
После того, как заказчик прислал требования и набор политик для антифрод, аналитики или служба поддержки настраивают их на тестовом контуре в веб-интерфейсе.
В обязанности команды тестирования входит подготовка тестовых данных согласно требованиям и политикам, и создание проекта SoapUI для пересылки этих данных в соответствующий микросервис. После написания каждого нового микросервиса заново выгружается wsdl файл, который потом грузится в SoapUI.
Под тестовыми данными я подразумеваю xml-файлы, набор полей в которых соответствовал требованиям, при которых политики срабатывали корректно или отдавали соответствующий код ответа, согласно документации.
Пример: При осуществлении платежа от ИП Васечкин к ИП Петечкину платеж должен быть не более 1 млн.руб. Если больше, то антифрод возвращает ответ DECLINE и транзакция блокируется.
Код ответа может меняться, так же, как и состав политик.
Более сложный пример: При пересылке от ИП Васечкин 1 млн.руб требуется запросить наличие просроченных кредитов у данного ИП через смежную систему. При наличие просрочки, увеличить скоринговый бал у Васечкина на 50ед за каждую просрочку. При превышении скорингового балла 100ед, отправить платеж на проверку менеджеру в ручном режиме. При этом антифрод должен прислать в теле ответа код ALLOW WAIT и скоринговый бал.
Позитивные сценарии.
Для всех позитивных сценариев составляются xml с нужными данными по клиенту(id, наименование, инн) и нужной суммой в теле запроса. Запрос отправляется в микросервис и в SoapUI создаются ассерты для проверки корректности ответа.
Привел его для примера. Тестировщику желательно знать ключевые элементы схемы XML
Негативные сценарии.
Для всех негативных сценариев в ключевых полях изменяются наборы данных. Применяются различные техники тест-дизайна, чтобы проверить корректность ответа системы антифрод. Если есть требования к типам и длинне данных, надо проверять и реакцию фронта и реакцию баз данных на выход за границы значений. Желательно обрабатывать ошибки на сервере приложений, не пуская ошибочные данные в базу.
После отправки запроса в микросервис, и проверки корректности ответа с помощью ассертов также надо проверить корректность логирования в базе антифрода и отправку ответа в шину.
интерфейс создания подключения к БД в Postman
Проверка логов шины данных тоже включается в процесс тестирования микросервиса. Микросервис должен принять ответ от ядра, сформировать ответ для шины в нужном формате и отправить его в шину по соответствующему протоколу. Шина логирует входящие сообщения от сервисов и делает запись в соответствующий лог. На данном этапе проверяется состав полей ответа, соответствие с ТЗ заказчика.
Замечание. При end-2-end тестировании особое значение уделяется проверкам по составу входящих и исходящих сообщений в шину данных. Состав, наименования и структура json и xml полей, соответствие типов данных и т.д. Если типы данных или имена полей не согласуются, то мы получает 100% вероятность дефекта при записи в БД или при обработке документа соответствующим коннектором или микросервисом, как в системе приемнике, так и в системе-источнике.
Вывод
Антифрод-система в банках сейчас является одним из важнейших модулей в инфраструктуре и некорректная работа данной системы может сильно повлиять на надежность и безопасность обслуживания. Тестирование данной системы также имеет высокий приоритет для департамента финансового мониторинга. Спецификой работы над таким проектом является глубокое погружение команды тестирования в предметную область банковских операций. Взаимодействие с множеством сотрудников различных систем-источников требуют высоких аналитических навыков, ведь время погружение в задачу и предметную область диктуется релизными рамками.
Гид по ручному тестированию приложений: преимущества, этапы и методологии
Детально разбираем то, как проводить ручное тестирование, когда оно лучше автоматизированного, что нужно уметь тестировщику и как он может построить свою карьеру от джуниора до тест- лида. Гид подготовлен совместно с руководителем отдела тестирования компании Agima Дариной Гордеевой.
Привет! Меня зовут Дарина Гордеева. Работаю в компании AGIMA руководителем отдела почти 3 года. В области тестирования и обеспечения качества более 6 лет. За это время прошла путь от джуниора до руководителя отдела, занимаясь тестированием железа, а также мобильных и веб-приложений, автоматизацией и настройкой процессов QA. Сегодня я расскажу вам про особенности, возможности и скрытые проблемы ручного тестирования.
Напомним, что любой читатель, воспользовавшийся промословом “Хабр” может получить скидку в 10 000 рублей на понравившийся курс, а самые усидчивые и внимательные могут собрать себе скидку в 25 000 рублей, разгадывая ребусы из материалов, подготовленных совместно с агентством Agima:
Оперативность, гибкость, возможность импровизации и другие плюсы
Сегодня есть множество фреймворков для тестирования, поддерживающих практически все существующие языки. Казалось бы — можно брать и автоматизировать. Но даже сейчас ручные тесты важны.
Одно из объяснений их необходимости заключается в том в том, что при ручном тестировании функционала мы можем гораздо быстрее получить информацию о состоянии продукта, который анализируем, о качестве разработки. Кроме того, при автоматизации предварительно разработанные кейсы часто приходится менять и актуализировать, а на написание автотестов требуется определённое время.
При этом в процессе разработки может прийти обратная связь от заказчика, когда он увидит в готовом продукте какую-то функцию, которую решит изменить до релиза — и, если вы уже подготовили для неё программные тесты, их придётся переписать. Обновление кейсов, автотестов и их проверка отнимут ценное время, которое можно было бы использовать на само обновление этой фичи.
Всё это означает, что главная цель ручных тестов — предварительно убедиться в том, что заявленный функционал работоспособен, не имеет ошибок и выдаёт ожидаемые, запланированные результаты. Без них нельзя быть уверенным в том, что можно работать дальше. Особенно это актуально для функций, на реализацию которых завязана последующая разработка. В таком случае возня с созданием автотестов на эти фичи становится блокирующим фактором для всей разработки продукта, сдвигая сроки и срывая дедлайны. Момент, когда кейсы придёт пора автоматизировать, всё равно рано или поздно наступит — но не стоит стремиться приблизить его искусственно в погоне за тотальным исключением ручного труда.
В дополнение к этому, на первых этапах разработки приложения автоматизация может оказаться довольно дорогой. Вам потребуется специалист, обладающий специфической квалификацией (и, возможно, не один). Постоянное поддержание тестов в актуальном состоянии требует затрат ресурсов вплоть до релиза фичи. А месяцы простоя, посвященные вылизыванию автотеста ударят по мотивации команды.
Если вы хотите регулярно добавлять новый функционал и успевать за действиями конкурентов, то перед тем, как создавать автотесты всегда проверяйте возможности продукта вручную. Просто потому что ручное тестирование ускоряет ваши процессы.
Это особенно актуально для мобильной разработки. Большинство таких проектов сегодня разрабатывается короткими спринтами, а значит фичи в них внедряются в ускоренном темпе. В подобных условиях ручное тестирование позволяет максимально оперативно давать команде обратную связь: сообщать о наличии багов — или радовать её тем, что всё окей и можно двигаться дальше. Провести серию автотестов вы сможете позже, покрыв с их помощью большие массивы кода. Ручное тестирование поможет подготовить кейсы для этой проверки.
Автотесты не позволяют проверить удобно ли использовать новые возможности приложения — проверка юзабилити всегда осуществляется вручную.
В ручных тестах можно импровизировать, создавая безумные сочетания действий, которые никогда не придут в голову пользователю, но могут быть совершены им случайно. Это позволяет создавать новые кейсы.
Новые кейсы появляются еще и потому, что тестировщик постоянно задает себе вопрос «а что, если?». Так он находит оригинальные способы взаимодействия с приложением — даже если их не было в базовых сценариях.
Проблемы ручного тестирования и их решения
Самый большой из недостатков ручного тестирования — человеческий фактор. Он, конечно, влияет на всё, происходящее в команде — и на работу участников, и на события, происходящие на стороне клиента. В случае QA причиной того, что тестировщик будет слабо погружен в процесс и пропустит потенциальную ошибку может стать всё что угодно — недостаток опыта, семейные проблемы или головная боль.
Один и тот же сценарий два тестировщика могут проверить разными способами. Что с этим делать? Важно, чтобы каждый непредусмотренный или отличающийся от ожидаемого результат был зафиксирован в виде кейса. Чтобы любой тестировщик мог проверить его, совершив тот же набор действий. Но и этого может быть мало — если кейс окажется недостаточно подробным, а тестировщик — не разберётся в описании. Гарантировать стопроцентное исключение человеческого фактора, конечно, невозможно — но можно постараться максимально снизить вероятность проблем, которые он вызывает.
Это тоже негативно сказывается на сроках поставки фичи в продакшн и трудозатратах: ведь теперь к периодически проводимым базовым кейсам и регрессии добавляются и “хитрые” кейсы, придуманные тестировщиками в процессе.
Усугубляет ситуацию вероятность того, что часть встреченных багов ещё не будет иметь строгого описания потому что причины их возникновения пока не понятны. Как бороться с такими повторными тестированиями? Либо найти уже источник ошибки и устранить его, либо — всё таки автоматизировать прохождение проблемных кейсов — в этом случае переход к программным тестам будет вполне оправдан как с точки зрения времени, так и финансово. (Нет, это не противоречит вышесказанному — потому что такие ситуации возникают уже в ходе активной разработки и к этому времени вы уже в любом случае развернёте процессы автотестирования).
В любом случае — появление первых кейсов, нуждающихся в регрессивных тестах или релиз второй версии приложения и соответствующее этим событиям масштабирование команды — тот момент, когда автоматизация станет актуальна (но не исключит ручное тестирование новых возможностей). На этом этапе автоматизация уже начнёт экономить время: разработчик сможет сам, ещё до передачи QA-отделу запустить регресс-тесты новой фичи, чтобы убедиться, что она не ломает существующий функционал, а тестировщику не придётся лишний раз проходить по набившим оскомину базовым кейсам. Ещё одно преимущество внедрения автотестов на этом этапе — их можно запускать по определённому расписанию — каждую ночь, в дни окончания спринтов или при публикации новых сборок приложения.
Резюмируем: ручное тестирование даёт большое преимущество по скорости и трудозатратам на первых этапах, а по мере разрастания приложения и появления большого количества регрессивных тестов оно переходит в разряд “оперативного тестирования” новых фич в рамках отдельного спринта. Оно будет актуально и при необходимости срочно проверить как приложение отреагирует на изменение операционной системы или обновление окружения.
Этапы тестирования: что, когда и как
Если смотреть на процесс разработки в целом и на тестирование как на одну из его частей, то при грамотном планировании вы всегда будете понимать что и когда будет готово. Это позволит лучше планировать время тех или иных действий — поскольку одни события логично следуют за другими и у вас есть возможность выстраивать их в цепочки на основании своих ожиданий.
Тестировщик появляется в процессе создания приложения уже на ранних этапах. Вот у клиента появляется некая идея, бизнес-аналитики собирают из этого требования — а тестировщики уже в этот момент приступают к работе, проверяя эти требования.
Как это происходит? Они задают вопросы по предполагаемому функционалу. Пытаются представить, как будет выглядеть приложение, когда оно будет реализовано. Если речь идёт о новой фиче в уже существующем продукте — разбираются, как она будет взаимодействовать с существующим функционалом. После того, как разработчики провели оценку трудозатратности идей клиента и определили сколько потребуется времени на их реализацию.
После этого начинается этап проектирования. Здесь появляется необходимость понять, как будут осуществляться переходы между экранами, валидироваться те или иные поля, как приложение или его отдельная функция вообще будет взаимодействовать с конечным пользователем. В случае с фичами важно разобраться и с тем, как они будут входить в архитектуру существующего приложения.
На этапе дизайна, когда создаётся карта переходов между экранами, тестировщик уточняет поведение отдельных элементов из которых они состоят и то, какими визуальными эффектами будут сопровождаться те или иные действия пользователя. Кроме этого тестировщик валидирует макеты на полноту, подтверждая, что они отображают всё, что нужно для реализации задуманного функционала. Нелишней будет и самостоятельная проверка макетов на соответствие гайдлайнам.
С началом разработки QA-специалисты сразу же приступают к написанию тест-кейсов. На разных этапах разработки они могут обладать различным уровнем детализации, но к её окончанию желательно обеспечить максимальное покрытие кейсами всего продукта, чтобы, получив сборку, можно было приступить к тестированию немедленно.
Первый шаг непосредственно тестирования — смоук-тест: оценка на то, что приложение или его новая часть вообще готовы к проверке. Смоук-тест — это проверка того, запускается ли приложение или конкретная функция в принципе.
Смоук-тест — быстрый способ убедиться, можем ли мы вообще начать функционально тестирование. Термин пришел от создателей плат и микросхем, которые для начала должны были убедиться не сгорит ли новая схема — отсюда и название: задымилась/не задымилась.
Это быстрый способ убедиться в том, что нам действительно сдали задачу и её можно принимать в работу, а не отправлять обратно программистам.
На примере формы авторизации смоук — это оценка того, можно ли залогиниться вообще, без уточнения того, валидны ли данные, вводимые в поля, работают ли дополнительные возможности вроде напоминания пароля и прочего. Если мы смогли авторизоваться в принципе — можно переходить к дальнейшей, углублённой проверке этого модуля: брать негативные кейсы, пограничные значения, оценивать соответствие установленным правилам валидации.
Следующий этап — проведение регресс-тестов. В ручном или автоматическом режиме проводится основной заранее запланированный массив тестов.
Регрессионное тестирование хорошо тем, что оно позволяет найти ошибки даже в тех местах, где раньше всё было в порядке. Это происходит благодаря тому что регресс — это оценка функционала на стандартный набор кейсов при внедрении каждого нового модуля и каждого изменения приложения. Ведь, когда разработчики добавляют новый функционал может быть повреждена текущая версия или новая фича может вступать в конфликт с уже существующими.
Например, добавление новых экранов, а значит и изменение навигации может нарушить функционирование меню или, как минимум — его отображение. С другой стороны неприятные сюрпризы может принести и глобальный рефакторинг кода приложения — после него тоже необходимо проводить регресс-тесты.
Проблемы могут вызвать и обновление используемой приложением библиотеки и изменение среды в которой оно работает. Чем чаще вы обновляете приложение — тем более важную роль играют регрессионные проверки. Не стоит ограничиваться однократной проверкой, проводимой, когда фича уже внедрена — проверяйте все изменения. Здесь вам поможет автоматизация регрессионного тестирования — просто потому что ручное регрессионное тестирование новой фичи, создававшейся всего неделю может занять две, а то и больше и отдел тестирования просто завязнет в этом.
Полная проверка, конечно, осуществляется когда release candidate с одной или несколькими фичами готов выкатываться в продакшн, но применять те или иные соответствующие кейсы на отдельных этапах разработки всё таки необходимо.
Завершается всё тестированием финальной сборки — release candidate. В него входят проверка бета-версии внутренними тестировщиками, бизнес-тестирование — оценка получившегося продукта самим клиентом и получение от него обратной связи, а также предложение определённой группе пользователей познакомиться с предрелизной альфа-версией приложения или его новых возможностей. После этого приложение готово к тому, чтобы его выкатили в продакшн.
Но на этом работа QA-специалиста не заканчивается — ему предстоит тестировать обновления приложения и их совместимость с более ранними версиями, составлять кейсы для проверки нововведений и, в случае необходимости, автоматизировать прохождение этих сценариев.
Параллельно с этим тестировщики участвуют в дальнейшем анализе статистики, собираемой аналитиками, мониторинге поведения приложения и того, как взаимодействуют с ним пользователи. Это позволяет не только увидеть живое использование результатов их работы, но и, порой, открыть для себя новые сценарии и неизвестные баги, вызывающие падения приложения.
Время ребуса: отгадайте его и десятипроцентная скидка на любой из курсов Skillbox ждёт вас прямо сейчас или проявите усидчивость и соберите ответы на все ребусы — эти скидки суммируются между собой (но ни с какими другими скидками на курсы Skillbox).
Однако, слишком медлить не стоит — промо работает до 30 августа 2018 года. Напомним, что тематика загадки — мобайл, а английские слова могут мешаться здесь с русскими, так что будьте внимательны! Отправьте заявку на курс, и когда с вами свяжется менеджер — назовите ему промослово, зашифрованное в ребусе (или — несколько!).
Формализация тестирования: тест-план, формат баг-репортов, отчётность
Для того, чтобы подготовиться к функциональному тестированию QA-инженер составляет тест-план. Это — документация, которая потребуется ему при тестировании продукта, список действий, которые ему нужно будет совершить. В тест-плане обозначаются сроки тестирования, описываются продукт или конкретная задача — для того, чтобы точно определить, что именно надо проверять. Детально описываются все основные тест-кейсы. Перечисляются виды тестирования, которые необходимы: функциональное и, например, нагрузочное. Описывается порядок автоматизации тех или иных кейсов и то, на каких этапах они будут автоматизированы.
Завершается тест-план описанием формата отчёта: нужно заранее объяснить, в каком виде будет предоставлен результат. Наиболее распространённым форматом отчёта является список тест кейсов со статусом их прохождения. Зная, насколько кейсы покрывают весь объём требований и прочитав отчёт, можно будет сделать вывод о текущем состоянии разработки приложения. Для этого достаточно будет посмотреть, сколько из них было успешно пройдено в той или иной сборке.
Финальной отмашкой, свидетельствующей о том, что продукт готов является статус “все требования покрыты кейсами, все кейсы пройдены успешно”.
Кроме того, в тест-плане формализуется формат отчёта по ошибкам. Это может быть баг-лист, список задач в трекере.
Задача тестировщика — предоставить наиболее полную информацию о качестве продукта всем участникам команды.
Что нужно знать и уметь, чтобы стать тестировщиком
В первую очередь тестировщик должен уметь думать и быть внимательным и усидчивым. Важен опыт — он позволяет накопить определённые наработки и закрепить знания процессов тестирования, превратив их в навыки.
Специалист по ручным тестам не обязательно должен уметь писать код и глубоко разбираться в архитектуре. Это никак не помешает ему проверять функционал и на прикладном уровне понимать принципы взаимодействия приложения и сервера.
Специалист по автоматизированному тестированию — это отдельная профессия, с абсолютно другим набором знаний. Качественное автотестирование — это не просто скрипты, но и понимание того, как приложение устроено изнутри, и специфические умения, вроде знания о том, как параллелить тесты или о том, как запускать их в облаке или на нескольких серверах. Только такой пул навыков позволяет с гордостью называть себя “автоматизатором с большой буквы”. Так что без знания языков, их фреймворков, принципов ООП и внимательной слежкой за развитием технологий настоящему автотестеру не обойтись.
Путь каждого тестировщика начинается с освоения теоретического базиса тестирования, получения первичных представлений о том, как приложение взаимодействует с сервером и со средой. Если эти знания есть, а вместе с ними человек обладает и очень серьёзным намерением учиться — он уже может считаться джуниор-тестировщиком. За группой таких новичков с горящими глазами закрепляется старший специалист — либо ведущий тестировщик, либо, если компания может себе это позволить — тренер, целенаправленно прокачивающий своих подопечных. Они объясняют джуниорам непонятные моменты и дают болевые задачи вроде прогонки фич по тест-кейсам. В процессе человек учится читать тест-кейсы и осваивает практические основы функционального тестирования. На этом этапе за джуниорами ещё нужно проверять качество проведённых ими тестов, проходя их вслед за ними.
Следующим шагом становится создание индивидуального (или коллективного, в зависимости от масштабов компании) плана по развитию, согласно которому начинающий тестировщик должен будет развиваться, осваивая новые знания и достигая определённых результатов за отведённые ему на это сроки. Именно это — путь к тому, чтобы стать специалистом миддл-уровня.
Миддл-тестировщик — это человек, который уже способен самостоятельно выполнять поставленные перед ним задачи, находить решения и вообще выполнять свою работу сознательно, а не слепо следуя установленным алгоритмам.
С развитием навыков тест-дизайна, познаний в функциональной и прикладной областях, а также освоении новых методик тестирования — которые теперь уже нужно развивать самостоятельно — происходит постепенная трансформация в ведущего специалиста. Теперь ему могут поручить ведение и поддержку таких же джуниоров, каким он сам раньше был.
Следующий уровень — это тест-лид. Он уже может управлять командой, в которую входят представители всех трёх предыдущих категорий, процессами которых он управляет и временем которых — распоряжается, в том числе участвуя в планировании глобальных процессов разработки, оценке трудозатрат и формировании бюджетов для своих команд.
Дальнейший вертикальный рост тим-лида — руководство отделом или переход в продук-менеджмент. Если же, человек стремится к новым знаниям, а не к новым административным позициям, то он может выбрать разработку, аналитику или такое направление, как DevOps, объединяющее в себе обязанности системного администратора, тестировщика и программиста.
Тестирование — лишь одна из многих областей мобильной разработки, которые мы рассматриваем в рамках курса “Fullstack-мобильный разработчик”. Сотрудничающие с нами профессионалы индустрии будут делиться с вами своим опытом и проверять ваши домашние задания, а итогом обучения может стать принятие на стажировку в крупную компанию. Приходите к нам учиться!