что такое ручное тестирование по

Ручное тестирование

Ручное тестирование программного обеспечения – это процесс проверки ПО, выполняемый специалистами вручную. Это значит, что для его проведения не используются какие-либо специальные автоматизированные средства.

Программное обеспечение проверяется инженерами по тестированию, которые берут на себя роль конечных пользователей, моделируют ситуации в соответствии с тестовыми сценариями и фиксируют результат. Задача ручного тестирования программного обеспечения — выявить любое поведение, отличающееся от ожидаемого пользователем. Это важный этап обеспечения качества ПО, который направлен на тщательное исследование программного кода и выявление ошибок в работе систем.

Ручное тестирование может проводиться в рамках регрессионного (тестирование различных изменений), интеграционного (взаимодействие с остальными системами и ПО) и при системном функциональном тестировании.

Ручное функциональное тестирование ПО

При ручном функциональном тестировании (РФТ) проверка различных функций ПО осуществляется тест-кейсами. Основная цель РФТ — определить, насколько разработанное программное обеспечение соответствует функциональным требованиям, то есть способно ли оно при определенных условиях решать задачи, необходимые пользователям.

Ручное и автоматизированное тестирование программного обеспечения

В основном для функционального тестирования используются именно ручные тесты, ведь их легче адаптировать под нужные цели и задачи. К тому же, ручные тестировщики могут выявить дефекты, которые не предполагались (увеличение тестового покрытия), и увидеть то, что могло быть не предусмотрено тестовыми сценариями. Однако, на крупных и длительных проектах, где может быть много повторяющихся тестов, все же целесообразнее использовать автотесты.

Для автоматизации тестирования сначала разрабатываются ручные тесты, а затем специальная программа-робот, имитируя взаимодействия программного обеспечения и пользователя, проверяет правильность работы и фиксирует все несоответствия. Автоматизированные тесты выполняются уже без привлечения инженеров по ручному тестированию и не позволяют выйти за рамки базовых сценариев.

Ключевые преимущества ручного тестирования

Благодаря ручному тестированию можно снизить количество ошибок, выявить и устранить «узкие места», обеспечить стабильную работу систем, оценить удобство эксплуатации, и, в результате, получить более качественный продукт, удовлетворяющий ожидания пользователей.

Основные этапы ручного тестирования программного обеспечения

Инструменты ручного тестирования

Поскольку ручное тестирование программного обеспечения довольно гибкое, оно допускает использование большого количества разнообразных инструментов.

Управление тестированием обычно ведется в специализированных системах, вроде 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 и многие другие

Источник

Ручное тестирование

Что такое ручное тестирование?

РУЧНАЯ ТЕСТИРОВАНИЕ — это тип тестирования программного обеспечения, при котором тестеры вручную выполняют тестовые случаи без использования каких-либо средств автоматизации. Ручное тестирование является наиболее примитивным из всех типов тестирования и помогает находить ошибки в программной системе.

Любое новое приложение должно быть проверено вручную, прежде чем его можно будет автоматизировать. Ручное тестирование требует больше усилий, но необходимо для проверки возможности автоматизации.

Ручное тестирование не требует знания какого-либо инструмента тестирования.

Одним из основополагающих принципов тестирования программного обеспечения является « 100% автоматизация невозможна ».

Это делает обязательным ручное тестирование.

Нажмите здесь, если видео не доступно

Цель ручного тестирования

Ключевой концепцией ручного тестирования является обеспечение того, что приложение не содержит ошибок и работает в соответствии с указанными функциональными требованиями.

Наборы тестов или кейсы, разработанные на этапе тестирования и должны иметь 100% охват тестированием.

Это также гарантирует, что заявленные дефекты были исправлены разработчиками, а тестеры выполнили повторное тестирование исправленных дефектов.

По сути, это тестирование проверяет качество системы и доставляет продукт без ошибок покупателю.

Типы ручного тестирования:

Ниже на данной диаграмме изображены виды ручного тестирования. Фактически, любой тип тестирования программного обеспечения может быть выполнен как вручную, так и с использованием средства автоматизации.

Как выполнить ручное тестирование

Мифы о ручном тестировании

Ниже приведены несколько распространенных мифов и фактов, связанных с тестированием:

Миф: Любой может сделать ручное тестирование

Факт : тестирование требует много навыков

Миф: тестирование гарантирует 100% отсутствие дефектов продукта

Факт : Тестирование пытается найти как можно больше дефектов. Выявить все возможные дефекты невозможно.

Миф: автоматизированное тестирование является более мощным, чем ручное тестирование

Факт : 100% автоматизация тестирования невозможна. Ручное тестирование также необходимо.

Миф: тестировать легко

Факт : тестирование может быть чрезвычайно сложным. Тестирование приложения на возможные варианты использования с минимальным количеством тестов требует высоких аналитических навыков.

Тестирование вручную против тестирования автоматизации

Инструменты для автоматизации ручного тестирования

Вывод

Ручное тестирование — это деятельность, в которой тестер должен быть очень терпеливым, креативным и открытым.

Они должны думать и действовать с точки зрения конечного пользователя.

Источник

Что такое ручное тестирование по

При создании типичного программного проекта около 50 % общего времени и более 50 % общей стоимости расходуется на тестирование. Эти цифры могут вызвать целую дискуссию, однако основным здесь является вопрос: как сократить расходы и повысить качество программного обеспечения?

Ручное тестирование (manual testing) — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно проводится тестировщиками или обычными пользователи путем моделирования возможных сценариев действия пользователя.

Задача тестировщика заключается в поиске наибольшего количества ошибок. Он должен хорошо знать наиболее часто допускаемые ошибки и уметь находить их за минимально короткий период времени. Остальные ошибки, которые не являются типовыми, обнаруживаются только тщательно созданными наборами тестов. Однако, из этого не следует, что для типовых ошибок не нужно составлять тесты.

Ручное тестирование заключается в выполнении задокументированной процедуры, где описана методика выполнения тесто. Методика задает порядок тестов и для каждого теста – список значений параметров, который подается на вход со список результатов на выходе. Так как процедура предназначена для выполнения человеком, в ее описании для краткости могут использоваться некоторые значения по умолчанию, ориентированные на здравый смысл, или ссылки на информацию, хранящуюся в другом документе.

Пример фрагмента процедуры

В этой процедуре тестировщик использует дополнительные документы и собственное понимание того, какую сопроводительную информацию считать “понятной и корректной”. Успех от использования процедурного подхода достигается в случае однозначного понимания тестировщиком всех пунктов процедуры. Например, в п.1 приведенной процедуры не уточняется, из какого диапазона должны быть заданы три целых числа, и не описывается дополнительно, какие числа считаются “разными”.

Автоматизированное тестирование

Попытка автоматизировать приведенный выше тест приводит к созданию скрипта, задающего тестируемому продукту три конкретных числа и перенаправляющего вывод продукта в файл с целью его анализа, а также содержащего конкретное значение желаемого результата, с которым сверяется получаемое при прогоне теста значение. Таким образом, вся необходимая информация должна быть явно помещена в текст (скрипт) теста, что требует дополнительных по сравнению с ручным подходом усилий. Также дополнительных усилий и времени требует создание разборщика вывода (программы согласования форматов представления эталонных значений из теста и вычисляемых при прогоне результатов) и, возможно, создание базы хранения состояний эталонных данных.

Методы ручного тестирования

Методы ручного тестирования достаточно эффективны с точки зрения нахождения ошибок. Их обязательно следует использовать в каждом программном продукте. Описанные методы предназначены для периода разработки, когда программа закодирована, но активный этап тестирования еще не начался. Похожие методы могут применяться и на более ранних этапах процесса создания программ, в конце каждого этапа проектирования.

Данные методы способствуют существенному увеличению производительности и повышению надежности программы. Во-первых, они обычно позволяют раньше обнаружить ошибки, уменьшить стоимость исправления последних и увеличить вероятность того, что корректировка произведена правильно. Во-вторых, психология программистов, по-видимому, изменяется, когда начинается тестирование перед релизом. Возрастает внутреннее напряжение и появляется тенденция «исправлять ошибки так быстро, как только это возможно». В итоге программисты допускают больше промахов при корректировке ошибок, уже найденных во время тестирования, чем при корректировке ошибок, найденных на более ранних этапах. Кроме того, скептицизм связан с тем, что это «первобытный метод». Сейчас стоимость машинного времени очень низка, а стоимость труда тестировщиков высока и ряд руководителей пойдут на все, чтобы сократить расходы. Однако, есть другая сторона ручного тестирования – при тестировании за компьютером причины ошибок выявляются только в программе, а самая глубокая их причина – мышление программиста, как правило, не претерпевает изменений, при ручном же тестировании, программист глубоко анализирует свой код, попутно выявляя возможные пути его оптимизации, и изменяет собственный стиль мышления, повышая квалификацию. Таким образом, можно прийти к выводу, что ручное тестирование можно и нужно проводить на первичном этапе, особенно, если нет прессинга времени и бюджета.

Сравнение ручного и автоматизированного подхода к тестированию

Сравнение показывает тенденцию современного тестирования, ориентирующую на максимальную автоматизацию процесса тестирования и генерацию тестового кода, что позволяет справляться с большими объемами данных и тестов, необходимых для обеспечения качества при производстве программных продуктов.

Инспекции и сквозные просмотры

Инспекции исходного текста и сквозные просмотры являются основными методами ручного тестирования. Так как эти два метода имеют много общего, они рассматриваются здесь совместно. Инспекции и сквозные просмотры включают в себя чтение или визуальную проверку программы группой лиц. Оба метода предполагают проведение подготовительной работы. Завершающим этапом является «обмен мнениями» – собрание, проводимое участниками проверки. Цель такого собрания – нахождение ошибок, но не их устранение (т. е. тестирование, а не отладка). Программа, тестируется не автором, а другими людьми и фактически «инспекция» и «сквозной просмотр» – просто новые названия старого метода «проверки за столом», однако они более эффективны потому что в процессе участвует не только автор программы, но и другие лица. Результатом использования этих методов является, обычно, точное определение природы ошибок. К тому же этим методом можно обнаруживать группы ошибок, что позволяет в дальнейшем корректировать сразу несколько ошибок.

Инспекции исходного кода

Инспекции исходного текста это набор процедур и приемов обнаружения ошибок при изучении текста группой тестировщиков. Во время инспекции исходного текста внимание сосредоточено на методах, процедурах, формах выполнения и т. д. Группа включает обычно четыре человека, один из которых выполняет функции председателя. Председатель должен быть компетентным программистом, но не автором программы; он не должен быть знаком с ее деталями. В обязанности председателя входят подготовка материалов для заседаний инспектирующей группы и составление графика их проведения, ведение заседаний, регистрация всех найденных ошибок и принятие мер по их последующему исправлению.

Инспекционное заседание разбивается на две части:

Сквозные просмотры

Сквозной просмотр, представляет собой набор процедур и способов обнаружения ошибок, осуществляемых группой лиц, просматривающих текст программы. Метод имеет много общего с процессом инспектирования, но их процедуры несколько отличаются и в нем используются другие методы обнаружения ошибок. Сквозной просмотр проводится как непрерывное заседание, группа состоит из 3–5 человек. Процедура отличается от процедуры инспекционного заседания тем, что участники «выполняют роль компьютера». Комиссии предлагают небольшое число написанных на бумаге тестов, представляющих собой наборы входных данных и ожидаемых выходных данных для программы или модуля. Тестовые данные подвергаются обработке в соответствии с логикой программы, состояние программы и значения переменных отслеживается на бумаге или доске.Тесты сами по себе не играют критической роли, а служат средством для первоначального понимания программы и основой для вопросов программисту о логике проектирования и принятых допущениях.

Проверка за столом

Проверка за столом может рассматриваться как проверка исходного текста или сквозные просмотры, осуществляемые одним человеком, который читает текст программы, проверяет его по списку ошибок или пропускает через программу тестовые данные. Большей частью проверка за столом является относительно непродуктивной, так как представляет собой полностью неупорядоченный процесс. К тому же проверка за столом противопоставляется одному из принципов тестирования, согласно которому программист обычно неэффективно тестирует собственные программы. Поэтому проверка за столом наилучшим образом может быть выполнена человеком, не являющимся автором программы, например, два программиста могут обмениваться программами вместо того, чтобы проверять за столом свои собственные программы. Однако даже в этом случае такая проверка менее эффективна, чем сквозные просмотры или инспекции. Данная причина является главной для образования группы при сквозных просмотрах или инспекциях исходного текста. Заседание группы благоприятствует созданию атмосферы здоровой конкуренции: участники хотят показать себя с лучшей стороны при нахождении ошибок. При проверке за столом этот, безусловно, ценный эффект отсутствует. Короче говоря, проверка за столом, конечно, полезна, но она гораздо менее эффективна, чем инспекция исходного текста или сквозной просмотр.

Источник

Что такое ручное тестирование. Основные подходы и инструменты

Ручное тестирование

Ручное тестирование — тип тестирования, в котором тест кейсы выполняются тестировщиком вручную, без использования инструментов автоматизации. Цель ручного тестирования — найти баги в приложении. Это одна из наиболее простых техник.

Любое приложение должно быть протестировано вручную прежде, чем автоматизировать процесс. Это необходимо для того, чтобы определить, целесообразно ли вообще внедрять автоматизацию. Для проведения ручного тестирования не нужно уметь пользоваться какими-либо инструментами. Один из фундаментальных принципов тестирования — 100% автоматизации невозможна. Поэтому ручное тестирование неизбежно в каждом проекте.

В этом гайде по ручному тестированию для начинающих мы детально разберем все основные концепции.

Цель ручного тестирования

Главная цель ручного тестирования — убедиться, что в приложении нет ошибок и что оно работает в полном соответствии с требованиями.

Для этого на стадии тестирования создаются тест кейсы, которые должны покрывать (в идеале) 100% функциональности тестируемого приложения.

Также ручной тестировщик проверяет, что обнаруженные баги исправляются разработчиками и повторно тестирует то, что было исправлено.

В целом, ручные тестировщики проверяют качество разрабатываемого приложения и обеспечивают доставку приложения максимально возможного качества конечным пользователям.

Типы ручного тестирования

На изображении выше показаны типы тестирования — в целом, тестирование любого из типов может быть как ручным, так и автоматизированным.

Выделяют следующие типы тестирования:

Как проводить ручное тестирование

Мифы ручного тестирования

Ниже мы собрали распространенные мифы и факты, относящиеся к тестированию ПО:

Миф: Ручное тестирование простое. Любой может протестировать приложение вручную.

Это неправда. Тестировщики сегодня должны обладать широким набором навыков.

Миф: Тестирование гарантирует 100%-е отсутствие багов в приложении.

Это неправда. Тестировщики пытаются обнаружить столько багов, сколько это возможно физически. Найти все возможные баги практически невероятно.

Миф: Автоматизированное тестирование более качественное, чем ручное.

Невозможно автоматизировать тестирование на 100%. Для максимально качественного тестирования продукта необходимы и ручные тестировщики.

Миф: Тестировать — очень просто.

Это неправда. Тестирование может быть очень сложным. Протестировать приложение с большим количеством сценарием использования с помощью минимального количества тест кейсов требует сильных аналитических навыков.

Ручное тестирование vs Автоматизированное тестирование

Инструменты для автоматизированного тестирования:

Заключение

Ручное тестирование — неотъемлемая часть процесса разработки. Люди, вовлеченные в процесс тестирования работают с приложением точно так же, как с ним работают конечные пользователи. Невозможно автоматизировать процесс тестирования на 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-мобильный разработчик”. Сотрудничающие с нами профессионалы индустрии будут делиться с вами своим опытом и проверять ваши домашние задания, а итогом обучения может стать принятие на стажировку в крупную компанию. Приходите к нам учиться!

Источник