Тестирование по

Чем занимается тестировщик

Нужно помнить, что тестирование сильно зависит от того, в какой компании работает тестировщик.

Это очевидно, но тем не менее акцентирую внимание на том, что очень сложно стать универсальным
тестировщиком, разве что сменив несколько работодателей из разных IT сфер.

Я прочитал некоторые вакансии в рунете и в LinkedIn и сделал подборку популярных требований и
описаний задач.

Постараюсь перевести их на понятный новичку язык.

Тестирование отдельных задач в тестовом и рабочем окружениях

Имеется в виду, что Вам придётся иногда тестировать в продакшене — то есть
не dev а prod версию.

Если Вы тестируете сервер, который хостится Вашей конторой, то разница только в ответственности.

Если сервер на стороне клиента — готовьтесь подключаться по VPN,
настраивать SSH туннель,
а в худшем случае — разбираться в SSL сертификатах.

Покрытие тест-кейсами функционала системы

Означает, что нужно изучить спецификацию и понять, что можно протестировать.
Затем описать
эти тесты.

Проверка входящих баг-репортов из Tech Support

Клиенты обычно жалуются на баги и не только на баги.

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

Вы проверяете воспроизводится ли баг в тестовом окружении,
если нет, то ковыряетесь в production логах где-нибудь на Kibana.

Функциональное тестирование и отслеживание качества выпускаемого сервиса

Здесь всё понятно — проверять нужно выполняет ли продукт свою функцию. После этого
проверить насколько качественно и удобно для пользователя он это делает

Анализ функциональности сервиса

Может означать всё что угодно. Похоже скорее на задание для исследовательского тестирования.

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

Это неотъемлемая часть работы практически любого инженера по тестированию, причём не только софта.

Локализация и документирование дефектов.

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

Документация это: описать что вызывает баг, какое действие клиента или какой конкертно запрос. Максимальное
количество полезной информации приветствуется.

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

Оптимизация процесса тестирования внутри команды и постановка задач разработчикам автотестов

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

Запуск и анализ результатов автотестов

Это очевидное продолжение предыдущего пункта.

Проведение ручного функционального тестирования

Функциональное тестирование мы уже обсудили, в этом пункте ключевое слово — ручное. Нужно будет кликать мышкой, делать
запросы к API, нажимать на кнопки, всё зависит от продукта. Если Ваша компания производит мухобойки — возможно придётся
бить мух.

Участие в регрессионном тестировании

Регрессионное тестирование обычно означает следующее.
У Вас уже есть работающий продукт, но к нему пришёл Change Request (CR)
и разработчики сделали новую фичу.

Фича работает, но теперь нужно понять не сломала ли новая фича что-то из старого функционала.

Для этого Вам придётся проделать все известные манипуляции с продуктом. Обычно под Regression Test есть
отдельный документ, если Вы придумали что-то новое — просто добавляете это туда. Довольно скучный процесс.

Ведение тестовой документации, подготовка тест кейсов

Рутина, без которой никуда особенно в большиъ компаниях.

Регистрация найденных дефектов в баг-трекере, контроль их исправления.

Взаимодействие с командой разработки.

Взаимодействие с разработчиками — это весело. Пример из жизни: в логах найдена неизвестная ошибка

2019-01-10 10:01:15 : Something is not ok

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

Прошла неделя, тестировщик тестирует совершенно другую историю и вдруг

2019-01-17 10:01:15 : Something is not ok

Тестировщик звонит разработчику и говорит, что ошибка снова появилась.

Первый вопрос разработчика — « А на каком уровне логов ты смотришь?»

Оказалось, что разработчик просто глубже закопал эту ошибку — теперь она не видна
на ERROR уровне лога а видна только на DEBUG.

Вот такой фикс.

Присылайте свои истории в комментарии. Лучшие я включу в статью.

QA, QC и тестирование

Так в чем же разница между QA и тестированием и что такое Quality Control?

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

Можно оформить их соотношение в виде таблицы:

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.

Иными словами, Quality Assurance обеспечивает правильность и предсказуемость процесса, в то время как Quality Control предполагает контроль соблюдения требований. Тестирование же, в свою очередь, обеспечивает сбор статистических данных и внесение их в документы, созданные в рамках QC-процесса.

Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину:

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

То есть качеству объекта внимание уделяется еще до создания самого объекта.

Джун, миддл, сениор. А есть ли путь дальше?

На своем проекте тестировщик обычно вынужден ограничиваться существующим стеком технологий. Смена стека, как и смелые эксперименты, обычно довольно затратна либо связана с изменением места работы. Однако и в рамках стека где-то до уровня сениора проблем вам хватит — это не один год упорного труда и самообразования.
Когда покажется, что вы уперлись в потолок, можно развиваться в управленцы или идти “вширь” — изучать новые фреймворки и инструменты, поднимая свою цену на рынке труда

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

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

Инкрементная модель

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

1. дизайн и разработка
2. тестирование
3. реализация.

В этой модели  возможна одновременная разработка разных версий продукта. Например, первая версия может проходить этап тестирования в то время, как вторая версия находится на стадии разработки. Третья версия в то же самое время может проходить этап дизайна. Этот процесс может продолжаться до самого завершения проекта.

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

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

Дополнительные ссылки

Материалы по тестированию есть на http://www.protesting.ru/. Там много теории и немного практики. Можно найти базовую информацию о том, какие бывают виды тестирования, что такое тест-кейс, тест-план и т.п. Правда, ресурс этот развивается с 2000-х годов, поэтому некоторая информация успела устареть. Но по базе здесь можно найти ценные примеры.
Форум на ресурсе https://software-testing.ru/forum/ — это своего рода аналог Хабра для тестировщиков (по большей части для автоматизаторов). Там много полезной информации именно начального уровня — на Хабре в разделе тестирования больше более продвинутых статей, а тексты для новичков появляются все реже и принимаются аудиторией все хуже.
Еще два неплохих источника информации: https://tproger.ru/digest/free-software-testing-books/ и https://automation-remarks.com/.
Спасибо специалистам по тестированию нашей компании за помощь при подготовке статьи!
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

View the discussion thread.

blog comments powered by DISQUS

Не нужно писать тесты, если

• Вы делаете простой сайт-визитку из 5 статических html-страниц и с одной формой отправки письма. На этом заказчик, скорее всего, успокоится, ничего большего ему не нужно. Здесь нет никакой особенной логики, быстрее просто все проверить «руками»
• Вы занимаетесь рекламным сайтом/простыми флеш-играми или баннерами – сложная верстка/анимация или большой объем статики. Никакой логики нет, только представление
• Вы делаете проект для выставки. Срок – от двух недель до месяца, ваша система – комбинация железа и софта, в начале проекта не до конца известно, что именно должно получиться в конце. Софт будет работать 1-2 дня на выставке
• Вы всегда пишете код без ошибок, обладаете идеальной памятью и даром предвидения. Ваш код настолько крут, что изменяет себя сам, вслед за требованиями клиента. Иногда код объясняет клиенту, что его требования — гов не нужно реализовывать

Что являет собой тестирование ПО?

Тестирование программного обеспечения — процесс, цель которого состоит в том, чтобы предотвратить и раскрыть «баги» в ПО и определить, соответствует ли оно определенным требованиям.  Считается, что половина работы по созданию программного обеспечения  — это тестирование.  Есть четыре общие категории, часто называемые этапами  тестирования программного обеспечения.  О них дальше и пойдет речь.

Юнит-тестирование тестирует самые маленькие  части программного обеспечения — юниты .  Цели такого тестирования состоят в том, чтобы оценить, удовлетворяет ли юнит  требования спецификации и/или соответствует ли его структура оговоренной структуре проекта. Юнит-тестирование должно быть реализовано программистом. Есть множество инструментов, которые могут быть использованы, чтобы оценить, были ли протестированы все пути, которыми ПО может реализоваться.

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

Видео курсы по схожей тематике:

Автоматизация тестирования мобильных приложений

Мищенко Андрей

QA Стартовый

Мизевич Кристина

Unit тестирование в C#

Дмитрий Охрименко

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

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

Принципы тестирования

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

1. Тестирование показывает наличие дефектов

Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие

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

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

2. Исчерпывающее тестирование невозможно

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

3. Раннее тестирование

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

4. Скопление дефектов

Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.

5. Парадокс пестицида

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок.

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

И еще несколько важных принципов:

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

Важные личные качества

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

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

Умение надолго концентрироваться и сохранять внимание. К слову, иногда именно тестирование позволяет наработать это навык и сохранить его для дальнейшей карьеры.

Доступ к коду программного продукта

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

• Тестирование «белого ящика» – с доступом к коду.
• Тестирование «черного ящика» – без доступа к коду продукта.
• Тестирование «серого ящика» – на основе ограниченного знания внутренней структуры ПО. Часто говорят, что это смесь тестирования «белого ящика» и «чёрного ящика», но это в корне неверно. В данном случае тестировщик не работает с кодом программного продукта, но он знаком с внутренней структурой программы и взаимодействием между компонентами.

Проверка программного продукта по каждому из сценариев требует достаточно глубоких знаний. К примеру, об особенностях тестирования «чёрного ящика» в своей книге подробно рассказал Борис Бейзер. Это фундаментальная работа, с которой полезно ознакомиться каждому на старте работы в QA. Об этой и других полезных книгах мы рассказали в статье.

Виды онлайн тестов

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

Вопросы на запоминание 

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

Например, в учебном курсе у нас содержится фраза:

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

Тогда вопрос на запоминание будет таким:

Что является качественно оказанной услугой? а) вовремя произведенный монтаж гарнитуры и оборудования б) ….

Вопросы на понимание 

Это более сложный тип задания по сравнению с запоминанием. Понимание — это способность изменить форму высказывания, сохранив при этом исходный смысл. Как сделать тест на понимание? Вы должны перефразировать сказанное в уроке другими словами, сохраняя ту же логику или причинно-следственную связь.

Рассмотрим на том же примере:

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

Вопрос остается тот же, а правильный ответ составляется уже другими словами:

Что является качественно оказанной услугой? а) кухня, установленная в оговоренный с клиентом срок б) ….

Вопросы на применение

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

Тот же пример:

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

Вопрос и ответы формируется уже в виде кейсового задания:

Можно считать, что монтажная бригада выполнила ценную и законченную работу, если … а) рабочие прибыли на объект без опоздания и выполнили все работы по монтажу в указанный срок  б) …

Чтобы провести качественный контроль знаний и гарантировать максимальное усвоение материала, мы рекомендуем использовать описанные виды вопросов в конкретном соотношении: 20% на запоминание, 50% на понимание и 30% на применение.

Тестирование безопасности

Что проверяем?

1. Пользователь не может авторизоваться: под старым паролем, заблочен в сервисе, достиг лимита авторизаций, ввел чужой код верификации.
2. Страницы, содержащие важные данные (пароль, номер кредитной карты и CVC, ответы на секретные вопросы и т. п.) открываются через HTTPS (SSL).
3. Пароль скрыт астерисками на страницах: регистрация, «забыли пароль», «смена пароля».
4. Корректное отображение сообщений об ошибках.
5. Завершение сесcии после разлогина.
6. Доступ к закрытым разделам сайта.
7. SQL-инъекции.
8. Cross-Site Scripting (XSS) уязвимости.
9. HTML-инъекции.
10. Cookie должны храниться в зашифрованном виде.
11. Роли пользователей и доступ к контенту.

Тестирование удобства использования

Что проверяем?

1. Отсутствие орфографических и грамматических ошибок, все страницы имеют корректные заголовки.
2. Выравнивание картинок, шрифтов, текстов.
3. Информативные ошибки, подсказки.
4. Подсказки существуют для всех полей.
5. Отступы между полями, колонками, рядами и сообщениями об ошибках.
6. Кнопки имеют стандартный размер, цвет.
7. На сайте нет битых ссылок и изображений.
8. Неактивные поля отображаются серым цветом.
9. Проверьте сайт при разных разрешениях экрана.
10. Скролл должен появляться только тогда, когда он требуется.
11. Отображение чекбоксов и радио-кнопок, кнопки должны быть доступны с клавиатуры, и пользователь должен быть в состоянии пользоваться сайтом, используя только клавиатуру.
12. Отображение выпадающих списков.
13. Длинный текст скрывается под многоточие.
14. Корректный выбор даты.
15. Наличие плейсхолдеров в полях.
16. Логотип ведет на главную страницу сайта.
17. Переходы и навигация между страницами и разделами меню.

Основные задачи тестирования

Еще несколько терминов, которые связаны с упомянутыми двумя задачами, которыми занимается тестировщик, это стимулы, реакции и оракул.

• Стимулы – это данные, которые подаются на вход программе.
• Реакции — это то, что получается на выходе.
• Оракул — это способ проверки наблюдаемого результата, совпадает он с некоторыми ожиданиями или не совпадает.

Программа представляет собой механизм по переработке информации. На вход поступает информация в каком-то одном виде, на выходе информация в некотором другом виде. При этом входов и выходов у программы может быть много, они могут быть разными, то есть у программы может быть несколько разных интерфейсов, и эти интерфейсы могут иметь разные виды:

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• графический,
• текстовый,
• консольный,
• и речевой.

Через пользовательский интерфейс компьютер взаимодействует с человеком, с пользователем.

Через программный интерфейс программы взаимодействуют друг с другом (человек тут не нужен).

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

Это файловая система, программы могут писать данные на диск и читать данные с диска.

Это состояние окружения, которое могут программы модифицировать и, соответственно, тоже читать.

Это события, в частности, таймер. То есть некоторые механизмы отслеживания времени.

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

Почему ручное тестирование не вымерло?

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

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

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

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

________________________________

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

________________________________

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

QA-тестировщик — кто это и чем занимается

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

1. Уточнение частей тестирования: какие части программы будут проверяться, прогноз ожидания пользователей и определение желаемого качества.
2. Разработка тестов для проверки подсистем, подготовка графика тестовых циклов.
3. Написание тестовой кодировки для проверяемого продукта.
4. Проведение тестирования, поиск багов (ошибок) у пользователей.
5. Тестирование безопасности.
6. Оценка результатов, при необходимости — повторное тестирование.
7. Утверждение критериев качества.
8. Разработка плана мероприятий по соблюдению критериев на каждом этапе разработки.
9. Устранение причин появления ошибок и предотвращение образования новых.
10. Документальное оформление обнаруженных багов.

QA-тестирование различается по степени доступа программиста к исходному коду проверяемого сервиса:

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

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

Возможно, вас интересует, где и как можно освоить профессию?

Рекомендую посмотреть подборку специализированных программ: лучшие онлайн-курсы тестировщика (QA-тестирование)

Советую также обратить внимание на эти варианты: актуальные предложения курсов по обучению тестировщиков для начинающих и специалистов

Динамическое тестирование

Динамическое тестирование (dynamic testing) — тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего приложения целиком (системное тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование), отдельных частей (модульное или компонентное тестирование) и даже отдельные участки кода.

Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.

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

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

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

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

Плюсы и минусы

Преимущества динамического тестирования

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

Недостатки динамического тестирования

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