что такое ручное тестирование
Ручное тестирование
Ручное тестирование программного обеспечения – это процесс проверки ПО, выполняемый специалистами вручную. Это значит, что для его проведения не используются какие-либо специальные автоматизированные средства.
Программное обеспечение проверяется инженерами по тестированию, которые берут на себя роль конечных пользователей, моделируют ситуации в соответствии с тестовыми сценариями и фиксируют результат. Задача ручного тестирования программного обеспечения — выявить любое поведение, отличающееся от ожидаемого пользователем. Это важный этап обеспечения качества ПО, который направлен на тщательное исследование программного кода и выявление ошибок в работе систем.
Ручное тестирование может проводиться в рамках регрессионного (тестирование различных изменений), интеграционного (взаимодействие с остальными системами и ПО) и при системном функциональном тестировании.
Ручное функциональное тестирование ПО
При ручном функциональном тестировании (РФТ) проверка различных функций ПО осуществляется тест-кейсами. Основная цель РФТ — определить, насколько разработанное программное обеспечение соответствует функциональным требованиям, то есть способно ли оно при определенных условиях решать задачи, необходимые пользователям.
Ручное и автоматизированное тестирование программного обеспечения
В основном для функционального тестирования используются именно ручные тесты, ведь их легче адаптировать под нужные цели и задачи. К тому же, ручные тестировщики могут выявить дефекты, которые не предполагались (увеличение тестового покрытия), и увидеть то, что могло быть не предусмотрено тестовыми сценариями. Однако, на крупных и длительных проектах, где может быть много повторяющихся тестов, все же целесообразнее использовать автотесты.
Для автоматизации тестирования сначала разрабатываются ручные тесты, а затем специальная программа-робот, имитируя взаимодействия программного обеспечения и пользователя, проверяет правильность работы и фиксирует все несоответствия. Автоматизированные тесты выполняются уже без привлечения инженеров по ручному тестированию и не позволяют выйти за рамки базовых сценариев.
Ключевые преимущества ручного тестирования
Благодаря ручному тестированию можно снизить количество ошибок, выявить и устранить «узкие места», обеспечить стабильную работу систем, оценить удобство эксплуатации, и, в результате, получить более качественный продукт, удовлетворяющий ожидания пользователей.
Основные этапы ручного тестирования программного обеспечения
Инструменты ручного тестирования
Поскольку ручное тестирование программного обеспечения довольно гибкое, оно допускает использование большого количества разнообразных инструментов.
Управление тестированием обычно ведется в специализированных системах, вроде 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 и многие другие
Путь QA бойца
Небольшой обзор вариантов развития твоей карьеры в сфере контроля и обеспечения качества.
С чего начать?
Итак, предположим, что вы планируете карьеру в IT и впервые услышали о QA. Теперь вы хотите разобраться, что же это такое.
QA — это процесс обеспечения качества программного продукта на всех этапах разработки, но на просторах СНГ часто этот термин применяется относительно тестирования ПО.
Что же потребуется начинающему специалисту чтобы ступить на путь борца за качество? Сейчас разберемся.
Для большинства компаний и проектов будет достаточно:
Хорошо, а куда мы идем?
Дальше поговорим о том, в каких направлениях прокачиваться и каких результатов можно достичь, начав свой путь в IT с обеспечения качества.
Роли в QA
Можно выбрать направление, не меняя сферу деятельности и развиваться, как более узкий специалист. Или объединить в себе несколько ролей. Нужно осваивать стратегии и типы тестирования в разных методологиях разработки, учиться пользоваться инструментами управления тестированием (TestLink, TestRail, Test IT и т.д.) и системами баг-трекинга (Jira, Redmine) – эти знания и навыки являются фундаментальными для всех QA инженеров. Самыми востребованными вариантами специализации являются автоматизированное и нагрузочное тестирования.
Ручное тестирование
Когда ресурсов на разработку автотестов нужно потратить больше, чем на сам продукт — проще/дешевле/быстрее проверить новый функционал руками.
Многие считают, что ручное тестирование это что-то простое и с этим может справиться каждый. На самом деле ручное тестирование требует очень много навыков. Ручные тестировщики решают те задачи, с которыми другие справиться не в силах.
Для ручного тестирования потребуются:
Автоматизация тестирования
Автоматизированные тесты помогают быстрее выпускать новые функциональности, быстрее проводить тестирование, уменьшить количество ручных тестов.
Так что же может понадобиться чтобы начать автоматизировать тесты?
Нагрузочное тестирование
Смысл нагрузочного тестирования в измерении качества системы, которая работает при определенной нагрузке. Выполнив тестирование производительности, можно определить масштабируемость, отказоустойчивость и стабильность программного продукта.
В работу специалистов этого профиля входит сбор данных о производительности приложения, времени отклика и локализацией ошибок при нагрузке, превышающей нормальные сценарии использования системы.
Самые важные навыки для тех, кто хочет заниматься нагрузочным тестированием:
Тест-аналитик
Тест-аналитик- человек, работа которого заключается в создании артефактов тестирования на основании требований. В маленьких командах эти задачи решает рядовой тестировщик, в крупных же функции тестирования и тест-дизайна, зачастую, четко разделены между людьми.
Идеальная цепь взаимодействий выглядела бы так:
Альтернативные пути развития карьеры. Есть ли жизнь после QA?
Системный аналитик
Всю свою карьеру ты боролся с некачественно описанными требованиями? У тебя есть шанс все исправить. Ты будешь общаться с пользователями системы, собирать и анализировать требования, а затем фиксировать их в документации. Плотное взаимодействие с разработчиками и опыт инженера по обеспечению качества помогут в том чтобы требования были полными и проработанными. Помимо этого, возможно участие во внедрении, обучение пользователей и сбор обратной связи об эффективности системы.
Бизнес-аналитик
Основное преимущество, которое тестировщики имеют перед разработчиками, заключается в том, что они получают знания в предметной области, в области бизнеса. Частый вариант продвижения тестировщика по карьерному пути – переход в бизнес аналитики. Как бизнес-аналитик вы будете участвовать в формировании требований к продукту со стороны бизнеса.
Менеджер
Допустим, с людьми вам общаться легче, чем с базами данных — тогда можно примерить на себя роль менеджера. Специалисты по обеспечению качества имеют глубокое понимание того, как сделать программное обеспечение лучше. Если готов принимать сложные решения и нести за них полную ответственность — проблем не будет. Здесь тоже есть свое ветвление, например: проектный менеджер, ресурсный менеджер, тест-менеджер и т.д. Всё зависит от процессов, построенных в компании.
Разработчик
Часто тестировщики уходят с головой в разработку, т.к. находясь бок о бок с программистами, познать их ремесло гораздо проще, чем получать специальное образование. Причем, вам расскажут, подскажут и помогут. Это неплохой способ начать карьеру, познакомиться с процессом разработки изнутри. Особенно, если вы уже знаете языки программирования и занимались автоматизацией тестирования. Главное – желание.
Если что упустил — рад обсудить в комментариях!
Ручное и автоматизированное тестирование
При ручном тестировании (manual testing) тестировщики вручную выполняют тесты, не используя никаких средств автоматизации. Ручное тестирование – самый низкоуровневый и простой тип тестирования, не требующий большого количества дополнительных знаний.
Тем не менее, перед тем, как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость.
Мифы о ручном тестировании:
Тестирование может быть очень непростым занятием. Проведение тестирования для проверки максимально возможного количества путей выполнения, с использованием минимального числа тест-кейсов, требует серьезных аналитических навыков.
Автоматизированное тестирование (automation testing) предполагает использование специального программного обеспечения (помимо тестируемого) для контроля выполнения тестов и сравнения ожидаемого фактического результата работы программы. Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия, задачи.
Некоторые задачи тестирования, такие как низкоуровневое регрессионное тестирование, могут быть трудозатратными и требующими много времени, если выполнять их вручную. Кроме того, мануальное тестирование может недостаточно эффективно находить некоторые классы ошибок. В таких случаях автоматизация может помочь сэкономить время и усилия проектной команды.
После создания автоматизированных тестов, их можно в любой момент запустить снова, причем, запускаются и выполняются они быстро и точно. Таким образом, если есть необходимость частого повторного прогона тестов, значение автоматизации для упрощения сопровождения проекта и снижения его стоимости трудно переоценить. Ведь даже минимальные патчи и изменения кода могут стать причиной появления новых багов.
Существует несколько основных видов автоматизированного тестирования:
Для составления автоматизированных тестов QA-специалист должен уметь программировать. Автоматические тесты – это полноценные программы, просто предназначенные для тестирования.
Когда, что и как автоматизировать и автоматизировать ли вообще – очень важные вопросы, ответы на которые должна дать команда разработки. Выбор правильных элементов программы для автоматизации в большой степени будет определять успех автоматизации тестирования в принципе. Нужно избегать автоматизации тестирования участков кода, которые могут часто меняться.
Сравнение ручного и автоматизированного тестирования
Как ручное, так и автоматизированное тестирования могут использоваться на разных уровнях тестирования, а также быть частью других типов и видов тестирования.
Автоматизация сохраняет время, силы и деньги. Автоматизированный тест можно запускать снова и снова, прилагая минимум усилий.
Мануальное тестирование может быть повторяющимся и скучным.В то же время, автоматизация может помочь этого избежать – за вас все сделает компьютер.
Таким образом, на реальных проектах зачастую используется комбинация ручного и автоматизированного тестирования, причем уровень автоматизации будет зависеть как от типа проекта, так и от особенностей постановки производственных процессов в компании.
Что такое ручное тестирование. Основные подходы и инструменты
Ручное тестирование
Ручное тестирование — тип тестирования, в котором тест кейсы выполняются тестировщиком вручную, без использования инструментов автоматизации. Цель ручного тестирования — найти баги в приложении. Это одна из наиболее простых техник.
Любое приложение должно быть протестировано вручную прежде, чем автоматизировать процесс. Это необходимо для того, чтобы определить, целесообразно ли вообще внедрять автоматизацию. Для проведения ручного тестирования не нужно уметь пользоваться какими-либо инструментами. Один из фундаментальных принципов тестирования — 100% автоматизации невозможна. Поэтому ручное тестирование неизбежно в каждом проекте.
В этом гайде по ручному тестированию для начинающих мы детально разберем все основные концепции.
Цель ручного тестирования
Главная цель ручного тестирования — убедиться, что в приложении нет ошибок и что оно работает в полном соответствии с требованиями.
Для этого на стадии тестирования создаются тест кейсы, которые должны покрывать (в идеале) 100% функциональности тестируемого приложения.
Также ручной тестировщик проверяет, что обнаруженные баги исправляются разработчиками и повторно тестирует то, что было исправлено.
В целом, ручные тестировщики проверяют качество разрабатываемого приложения и обеспечивают доставку приложения максимально возможного качества конечным пользователям.
Типы ручного тестирования
На изображении выше показаны типы тестирования — в целом, тестирование любого из типов может быть как ручным, так и автоматизированным.
Выделяют следующие типы тестирования:
Как проводить ручное тестирование
Мифы ручного тестирования
Ниже мы собрали распространенные мифы и факты, относящиеся к тестированию ПО:
Миф: Ручное тестирование простое. Любой может протестировать приложение вручную.
Это неправда. Тестировщики сегодня должны обладать широким набором навыков.
Миф: Тестирование гарантирует 100%-е отсутствие багов в приложении.
Это неправда. Тестировщики пытаются обнаружить столько багов, сколько это возможно физически. Найти все возможные баги практически невероятно.
Миф: Автоматизированное тестирование более качественное, чем ручное.
Невозможно автоматизировать тестирование на 100%. Для максимально качественного тестирования продукта необходимы и ручные тестировщики.
Миф: Тестировать — очень просто.
Это неправда. Тестирование может быть очень сложным. Протестировать приложение с большим количеством сценарием использования с помощью минимального количества тест кейсов требует сильных аналитических навыков.
Ручное тестирование vs Автоматизированное тестирование
Ручное тестирование | Автоматизированное тестирование |
---|---|
В ручном тестировании тест кейсы выполняются человеком. | Автоматизированное тестирование использует специальные инструменты, которые выполняют тест кейсы. |
Ручное тестирование, как правило, занимает много времени и довольно дорого стоит (т.к. Проводится человеком) | Автоматизированное тестирование сохраняет время и деньги. Автотест создается один раз и может использоваться неограниченное количество раз. |
Любое приложение может быть протестировано вручную. | Автоматизированное тестирование применяется для более-менее стабильных систем. В большинстве случаев автотесты используются для регрессионного тестирования. |
Ручное тестирование может стать скучным (из-за того, что одни и те же действия нужно повторять большое количество раз) | В автоматизированном тестировании скучная часть (повторение тест-кейсов) выполняется с помощью специальных программ. |
Инструменты для автоматизированного тестирования:
Заключение
Ручное тестирование — неотъемлемая часть процесса разработки. Люди, вовлеченные в процесс тестирования работают с приложением точно так же, как с ним работают конечные пользователи. Невозможно автоматизировать процесс тестирования на 100%, поэтому ручные тестировщики всегда будут пользоваться спросом на рынке труда.
Ручные тестировщики не нужны или пора уже в автоматизацию
Нет, конечно же ручники будут нужны. Но с каждым годом потребностей в них будет все меньше. Уровень зарплаты быстро упрется в потолок, а от монотонных задач будет тошнить. Если у вас есть желание оставаться в QA и вырасти в автоматизатора (разработчика?), то текст ниже для вас.
Кто я?
Давайте сначала познакомимся. Меня зовут Александр, и я 15 лет работаю в тестировании. Начинал с разработки, ушел в тестирование, был ручником, сейчас автоматизатор. Тестировал десктоп, UI, мобильные приложения, API, проводил нагрузочное тестирование и много чего интересного, связанного с QA. Я кратко расскажу вам как бы построил свою карьеру в автотестировании, что бы изучал и с чего начал. Да, я что-то упущу, но мои советы это отражение моего опыта, а не истина в последней инстанции.
Какими были ручные тестировщики раньше
Раньше было лучше(с). Лет 15 назад профессия только становилась. К компаниям приходило понимание важности тестирования, и они начинали нанимать тестировщиков. Основные (не всегда!), если коротко, требования к тестировщику — лайтовый программист или специалист, который не попал в программисты, плюс знания основ тестирования. Возможно, вас смутит предыдущие предложение, но я потом поясню его.
Сами тестировщики разделились на ручников и автоматизаторов. Автоматизаторам были доступны продукты от HP, внедрялся Selenium, скриптовые языки. Ручники же тестировали руками, писали тестовую документацию.
Время шло, и ручники слились в одну ветку с автоматизаторами. Причем, по моему мнению, доминировать стали автоматизаторы. И теперь я расскажу, как можно стать AQE (automation quality engineer).
Что надо знать для старта?
Теорию тестирования. Это надо. Виды тестирования, тестовая документация, знать и уметь применять техники тест-дизайна. А также изучить пирамиду тестирования. Может не все в ней будет понятно, но со временем она раскроется во всей красе.
В принципе, для старта подойдет книга Савина “Тестирование Дот Ком” и часов двадцать на ютубе.
Книги прочитаны, ютуб просмотрен, опыт в ручном тестировании есть. Теперь попробуем двигаться в сторону автоматизатора, там интереснее.
“Работа QA, как одна из относительно легких точек входа в ИТ,”
“Автотестеры скоро вымрут. Как правило, это такие недопрограммисты”
“Мы тестеры, а не разработчики, нам это знать не надо/не положено/ не обязательно”
Первые два высказывания я нашел в интернете. Третье много раз слышал в живую. Если вы хотите достичь высокого уровня в автоматизации, то не соглашайтесь с этими мифами. Будет тяжело, долго, но интересно. Ваши знания должны быть на уровне программистов. А в большинстве случаев и более — вам же еще знать и применять теорию тестирования.
Откуда берутся такие мифы? Я думаю, что из пункта выше — Какими были ручные тестировщики раньше. Тестировщики это лайтовые программисты (НЕТ).
Думаю, что я могу это доказать. Есть знакомые тестировщики/руководители/разработчики? Спросите их, сколько автотестеров (сильных) они нашли за год? Думаю, что мало, единицы. Наша фирма за год просмотрела 20 кандидатов и взяли одного. Мидла.
Можно попробовать пройти собеседование на синьора AQE. Там уже “Мы тестеры, а не разработчики, нам это знать не обязательно” не прокатит. И собеседовать вас после теории тестирования будут разработчики. Потому что современный сильный автоматизатор — это полноценный разработчик.
Выбор языка программирования
Не особо важно. Глобально языки программирования похожи друг на друга и за свою карьеру вы будете знать несколько. Если вы поймете основы, то переход на новый язык будет быстрым.
Начинайте с изучения базовых концепций: типы данных, классы, массивы, циклы, работы со строками, функции, ООП. После перейдете к конкретному языку.
В 2020 году для разработки автотестов я бы смотрел на эти языки (напомню, что это исходя из моего опыта, а не инструкция к действию):
JavaScript отлично подходит для тестирования UI. Быстро развивается в тестировании. Фреймворки на JS активно вытесняют Selenium
Java самый популярный язык для автоматизации в России. Так исторически сложилось, очень много вакансий.
Python язык с самым быстрым входом. Язык “простой”, легко читается и изучается.
И надо понимать, что это долго, надо запастись терпением. В зависимости от интенсивности обучения от 4 месяцев до года.
Паттерны проектирования
Паттерны проектирования описывают типичные способы решения часто встречающихся проблем при проектировании программ.
Вот что я недавно услышал:
“Нам нужны крепкие мидлы, которые будут разгребать и понимать наши тесты. Мы их уже мало понимаем”.
Когда у вас сайт с 3-2 страницами, то все просто, быстро, красиво. Но, если у вас проект, где одновременно ui/api/mobile/e2e тесты, и все это написано без паттернов, то в 90% случаев это превратится в помойку (извините).
Знание Page Object это хорошо, но в мире есть еще много полезных шаблонов, которые могут сделать разработку проще. Чем раньше вы решите этот вопрос, тем меньше проблем будет в будущем (это как найти баг на раннем этапе, тогда исправить его будет дешевле).
Если пока не получается разобраться с этой темой, то попросите помощи своих разработчиков. Мы таким образом улучшили проект в несколько итераций, разобрав его с разработчиком.
Также рекомендую прочитать книгу Head First. Паттерны проектирования. Фримен Эрик, Робсон Элизабет.
Какую ОС выбрать?
Не важно. Сейчас это вопрос привычки, используйте то, на чем вам будет удобно. Если бы у меня был такой выбор сейчас, то я бы выбрал UNIX подобную систему. Опыт работы с ней ценится на рынке труда, да и проблем меньше.
Фреймворки для тестирования
Фреймворк (англ, framework — структура, каркас) — совокупность решений по архитектуре, структуре и способам объединения компонентов системы, которые могут быть применены для некоторого множества однотипных задач.
Вот уже подбираемся к тестированию. Для каждого языка есть отличные фреймворки. Для JS это Cypress, Nightwatch, Puppeteer и другие. У Java Selenide, в Python стандарт pytest. Изучайте их, как придет время. Документации по ним море.
Придет время и вы будете сами развивать свой фреймворк, естественно, перед этим хорошо поняв тему паттернов.
GIT и ревью
Git (произносится «гит») — распределённая система управления версиями.
Ваш код надо где-то хранить. Для этого есть git. Git де-факто это стандарт.
Тут процесс обучения можно построить так:
Установите git
Зарегистрируйтесь на github.com
Прочитайте документацию
Откройте ютуб, найдите уроки и работайте по ним.
Для входа вам понадобится изучить небольшое количество команд git:
clone, add, push, pull, stash, commit, status, rebase, checkout. За неделю вы это изучите и освоите. Главное практика.
Код ревью — это мощный инструмент для обмена знаний, поиска багов и “глупых” ошибок, проверки вашего кода. Первое время будут проверять чаще вас, но со временем и вы начнете ревьювить остальных. Попробуйте воспринимать ревью как помощь и развитие себя. Ошибки и опечатки есть у всех.
Что еще изучить?
CI/CD Непрерывная интеграция / Непрерывное развертывание.
Главные цели CI/CD — свести к минимуму ошибки, ускорить сборку и повысить качество конечного продукта:
Docker — это платформа, которая предназначена для разработки, развертывания и запуска приложений в контейнерах
HTTP — это протокол для обмена данными в сети. Возможно, писать UI тесты без знания HTTP вы сможете, но API тестировать нет. Да и локализация проблемы будет быстрее с этими знаниями.
xpath — язык запросов к элементам XML-документа.
SQL — это стандартный компьютерный язык для управления реляционными базами данных и обработки данных. SQL используется для запроса, вставки, обновления и изменения данных.
Этот список можно продолжать дальше, но на этом я остановлюсь.
Где получить знания?
Ютуб
Тематические форумы
Книжки
Курсы по программированию
Курсы по автоматизации тестирования
Я специально разделил курсы по программированию и курсы по автоматизации тестирования. Лучше начинайте с первых. Во вторых курсах вас будут учить автоматизации и закрывать глаза на “правильность” разработки. Лучше заложить базу, а потом двигаться в автоматизации.
Стоит ли экономить на учебе? Может взять книжку/почитать статью/ посмотреть ютуб, а не выбрать платные курсы? Нет. Если есть возможность, конечно. На курсах есть менторы, это сильно ускорит обучение. Есть куча придуманных для вас заданий, которые должны прокачать скиллы. Единственное, надо с умом подойти к выбору преподавателей. Читайте отзывы.
P.S. Я прошел все: книги, ютуб, статьи, курсы. И для меня лучше всего подошли курсы, это был скачок в развитии. Возможно, у вас будет по другому.
Ссылки
форум автотестеров (там почти все) automated-testing.info
js for testing t.me/js_for_testing
QA — автоматизатор t.me/qa_automation
Серьезный тестировщик t.me/serious_tester
Если еще не сделали, то добавляйте в закладки, это маст хэв ru.stackoverflow.com
Почему я это написал
Недавно я был на митапе, где один из докладчиков рассказывал про свой опыт применения автоматизации тестирования. И его компания пришла к выводу, что легче найти разработчиков и сделать из них AQE, чем тяжело искать автотестеров, которые на долгой дистанции не приносят той пользы, который от них ожидали. И причины были в том, что у автотестеров не хватает знаний в разработке (паттерны, знание библиотек). В чем-то я с ними согласен. Я уверен, что кто-то подумает что я описал требования к супер тестировщику или к разработчику в тестировании (Software Developer In Test). С развитием скрама, когда исчезает такое понятие, как разработчик/аналитик/ тестировщик, мы становимся инженерами и равноправными членами команды, цель которой выпустить продукт/сделать фичу за спринт. В этих условиях требования к автотестерам будут расти и на рынке будут цениться T-shaped специалисты (статья на vc.ru). Такие люди смогут не только четко локализовать проблему, но и исправить ее (например, на фронте). И за этим будущее.
Конец
Как я писал раньше, процесс обучения не будет легким. Для входа в профессию AQE надо будет потратить +- год. Написано много статей, как выстроить обучение, я же отмечу два пункта: