Это имело смысл (и то спорно) несколько лет назад, но после эпидемии и агрессивной рекламы работы в IT со стороны обучающих компаний появились тысячи выпускников курсов по тестированию, так что этого "легкого пути вкатиться в айтишечку" уже нет и не будет. Конкурс на одно место на удаленку может доходить до нескольких сотен человек. Конечно, в разработке тоже конкуренции поприбавилось, но если вы нацелены стать программистом, то никакие вхождения через другие специальности не имеют ни малейшего смысла - тестирование и разработка - разные профессии и опыт работы джуниор тестировщиком вам практически ничем не пригодится, вы лишь потратите время на подготовку к собеседованиям (а требования теперь весьма высокие), а потом еще на обучение непосредственно той специальности, куда хотели изначально, т.к. опыт по сути не релевантен и спрашивать будут с нуля.
Доп. материал: Мифы о тестировании #2 / О чем не говорят на курсах по тестированию / Правда о работе в IT
Первые зарплаты будут мизерными (особенно учитывая конкурс на места), а подняться выше по карьерной лестнице без искреннего интереса и запала не получится, тестирование - слишком обширная область знаний. Без внутренней мотивации к ежедневному самообучению не получится зарабатывать больше чем в любой другой профессии на старте. Так что сферу деятельности стоит менять только если вы всю жизнь чувствовали, что занимаетесь не тем, а тут прям вот екнуло и хочется взахлеб осваивать именно тестирование. Но даже в этих случаях нужно понимать, что далеко не всем компаниям требуются профессиональные тестировщики, разработчикам в этом смысле найти применение своим навыкам куда проще. Именно по этой причине существует отток уже проработавших какое-то время в тестировании специалистов в другие направления: менеджмент, чистая автоматизация, разработка. Фактически они просто не смогли найти дальнейшие пути развития своих навыков. Соответственно и зарплаты здесь в среднем ниже, чем на многих специальностях в IT. Статистика зарплат: Россия, Украина, Беларусь К сожалению, шансы устроиться на удаленку специалисту без опыта довольно низкие - высокая конкуренция, к тому же компании охотнее берут начинающих в офис (так эффективнее обучать). Поэтому попробовать, конечно, стоит, но рассчитывать на это особо не нужно. Да и начинающему действительно продуктивнее находиться в офисе вместе со всей командой, в гуще событий. Вот пара ссылок на карты знаний для тестировщиков, но можете на просторах найти и другие. https://github.com/anas-qa/Quality-Assurance-Road-Map https://www.mindmeister.com/ru/1324282825/junior-qa?fullscreen=1 https://www.mindmeister.com/ru/1558647509?t=973hdS2AKb Некоторые компании подробно расписывают на своих порталах ожидания от каждой стадии развития сотрудника, тоже не проблема найти, по этой же теме много видео на Youtube (раз, два, три, четыре, …). Еще один ориентир – просто открыть и почитать вакансии в своем городе, что в среднем у вас требуется от новичка. Если же попытаться выделить самые частые вопросы на собеседованиях, то получится примерно следующее:- Что такое тестирование?
- Зачем оно нужно?
- QA/QC/Тестирование - разница?
- Что такое качество ПО?
- Верификация и валидация?
- Severity priority?
- Виды, типы, уровни тестирования?
- Виды документации? Тест-план, тест-кейс, чек-лист?
- Что такое баг? Его жизненный цикл?
- Техники тест-дизайна?
- SDLC, STLC; Методологии разработки ПО?
- Мобильное тестирование: его особенности (и в частности жизненный цикл Android и iOS приложения)?
- Клиент-серверная архитектура?
- API?
- Базовое знание сетей: HTTP(S), его методы, коды ответов, Query-параметры, REST/SOAP, JSON/XML
- Базы данных: что такое SQL, СУБД, основные команды (особенно любят джойны).
- Инструменты: Chrome DevTools, Postman, Charles/Fiddler, GIT, TMS
- Практика: тестирование форм или какого либо сайта, приложения (в частности составление тест-кейсов и баг-репортов), придумать хороший summary для репорта, определение severity/priority; SQL запросы; что-нибудь на "подумать".
В случае gamedev могут еще спросить про последнее во что играл, что понравилось/не понравилось и т.п.
Помимо вышеперечисленного нужно помнить об английском языке и его важности в работе. Конечно, есть небольшое количество компаний, которые не станут уделять этому внимания, но если в вакансии указан необходимый уровень владения языком, то будьте готовы к тому, что как минимум попросят ответить на какой-нибудь простенький житейский или из списка HR-вопросов на английском. В отдельных случаях, где явно указана необходимость разговорного уровня, все собеседование вполне может пройти на английском.
Доп. материал:
- Образ современного тестировщика. Что нужно знать и уметь
- Что должен знать тестировщик бэкенда
- Тестировщик ПО / что делает QA Engineer / интервью с Artsiom Rusau QA
- Исследование рынка труда в QA
- Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает, что надо знать и где учиться
- Качественное тестирование ПО
- ML&AI в QA
- QAOps
- Тестирование IoT
- Тестирование больших данных
Дополнительные ссылки: Тестирование в эпоху ИИ 12 Important Software Testing Trends for 2021 You Need to Know Как учиться, чтобы научиться
Telegram: Must have! Каналы это: знакомство с коммьюнити, живое общение, уникальный опыт тысяч коллег; богатая история сообщений, где поиском по истории сообщений можно найти все что угодно; в шапке каждого канала закреплено сообщение со своим набором полезностей. Кроме того, некоторые каналы специализируются на мониторинге нового полезного материала с основных порталов, так что можно даже не погружаться с головой в хабр, доу, медиум и т.п., вам отберут все самое полезное. В конце концов, в этих каналах публикуются анонсы грядущих онлайн-мероприятий, чтобы ничего не упустить.
- Всем новичкам сюда! Тренировочные собеседования, интересные обсуждения https://t.me/qa_interviews
- Огромный чат, ориентированный на джуниоров https://t.me/qajuniors
- Огромный чат, ориентированный на уже работающих в сфере тестирования https://t.me/qa_ru
- Чат по геймдеву https://t.me/qa_gamedev
- Обсуждение курсов, отзывы о них https://t.me/qa_courses
- Тут можно размещать свое резюме https://t.me/qa_resumes
- Тут отзывы о компаниях https://t.me/qa_bad_company
- Обсуждение финансов https://t.me/qa_fin
- Публикация книг https://t.me/booksqa
- Авторский бложик https://t.me/shooandendlessagony
- Репосты новых статей и полезных ссылок с разных сайтов:
Youtube-каналы:
- Вадим Ксендзов (тренировочные собеседования!) https://www.youtube.com/channel/UC6hNNlCXv1ZgdGpziNf83RA
- Mikhail Portnov: https://www.youtube.com/channel/UCDbzkNMBNZJBKP4C-9qGw4Q
- Podlodka Podcast https://www.youtube.com/channel/UCOei1E1Vqq10S913OEqTWGw
- QA START UP: https://www.youtube.com/channel/UCAlCZby7zJHzyhOmS8issDQ
- Компания DINS: https://www.youtube.com/channel/UCmJYB3hvbF3AlVh9HFeXX3A
- Artsiom Rusau QA Life https://www.youtube.com/c/ArtsiomRusauQALife
- Леша Маршал https://www.youtube.com/channel/UCTVciJQp8eYwKLLQIl-iSJw
- Тестирование: https://www.youtube.com/channel/UC9VeXtf7fcCJUfmZ_cyweXA
- Fest Group: https://www.youtube.com/channel/UClTnsvgTiW2YcfP1tcI2oKA
- QAGuild: https://www.youtube.com/channel/UCHtyBZ2XbtsRmNiAxh48RGg
Web:
- Большой список тестовых площадок для тренировок
- https://cantunsee.space/
- https://software-testing.ru/ (+форум)
- http://www.mobileappstesting.com/
- https://www.guru99.com
- https://www.softwaretestingmaterial.com/
- https://www.ministryoftesting.com/
- http://www.testingeducation.org/BBST/foundations/
- https://www.learnqa.ru/
Книги:
Очень хвалят вот эту подборку http://okiseleva.blogspot.com/2014/02/blog-post_6.html?m=1
Подборка книг по ИБ https://habr.com/ru/company/mailru/blog/282700/
Перевод книги Ли Копланда "A Practitioner's Guide to Software Test Design"
Еще встречал вот такой список:
- Роман Савин «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах» (можно сказать худ.лит, «для чайников»)
- Святослав Куликов «Тестирование программного обеспечения. Базовый курс.»
- Арбон Джейсон, Каролло Джефф, Уиттакер Джеймс «Как тестируют в Google»
- Борис Бейзер «Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем»
- Рекс Блэк «Ключевые процессы тестирования»
- Гленфорд Майерс, Том Баджетт, Кори Сандлер «Искусство тестирования программ.»
- Microsoft Corporation - Performance testing Guidance for Web Applications
Мобильные приложения:
Другие сборники материала и ответов на вопросы:- https://drive.google.com/file/d/1x9oeWuPiVqytNYTKunJgLLarq4IBdeTY/view?usp=sharing
- https://www.istqb.org/downloads/category/2-foundation-level-documents.html
- https://github.com/ultragreatester/how-to-qa
- https://habr.com/ru/post/257529/
- https://docs.google.com/file/d/18yJqziwhxz5khP1mtrme1mNJW95mwrgc/edit?filetype=msword
Словари терминов (в т.ч. элементов интерфейса):
- Словарик айтишника или Что? Где? Куда? Часть 1
- IT-словарик для не-айтишников
- https://docs.google.com/spreadsheets/d/1LgytNrl7ep9wlr3A_3u0NitQsrZzKhEQwC-OTQfbLAM/edit?usp=sharing
- https://docs.google.com/spreadsheets/d/1r5Ek83V4IHkOsW52DyVT8iJepR20oZu_Jy5vAkq7SrI/edit?usp=sharing
- Элементы интерфейса сайта
- UI-элементы и жесты в мобильных приложениях
- Словарь тестировщика
Чек-листы и идеи для тестов:
- Где брать идеи для тестов (подборка полезных ссылок)
- 37 источников тест-идей
- Checklists Base :)
- Чек-лист тестирования мобильных приложений
- Дополняем чек-лист тестирования при обновлении иконки и сплеша в мобильных приложениях
- Чеклист для тестирования мобильных приложений
- Чек-лист для тестирования числового поля
- Чек-лист тестирования WEB приложений
- Testing checklist for mobile applications
- iOS App Testing Template
- Getting started with mobile testing
- Mobile testing in a nutshell
- Am I Really Done Testing?
- Mobile Testing Checklist
- Testing Criteria for Android Applications
- A mnemonic for mobile app testing
- Test Mobile Applications with I SLICED UP FUN!
- Mobile App Test Coverage Model : LONG FUN CUP
- Тестирование новой фичи
- Мультитул: DevTools;
- Снифферы: Charles Proxy, Fiddler;
- Тестирование API: Postman, SoapUI;
- Тестирование производительности: JMeter;
- Тестирование безопасности: Kali linux, Santoku Linux + drozer, OWASP ZAP, …;
- Тестирование UI/UX: Figma, Zeplin, любой mindmap-like продукт;
- Фермы устройств для тестирования мобильных приложений: BrowserStack, Xamarin, AWS;
- Инструменты тестирования Android приложений
- Системы контроля версий: GIT;
- Взаимодействие с базами данных: язык SQL, системы СУБД;
- Системы CI/CD: Jenkins/TeamCity;
- Прочее: мессенджеры, баг-трекинговые системы и TMS, генераторы тестовых данных и т.п.
DevTools: В каждый современный браузер встроены инструменты разработчика — они позволяют быстро отловить и исправить ошибки в разметке или в коде. С их помощью можно узнать, как построилось DOM-дерево, какие теги и атрибуты есть на странице, почему не подгрузились шрифты и многое другое:
- Проверка ответа сервера
- Проверка мобильной адаптивности
- Проверка мобильной выдачи
- Региональная поисковая выдача
- Изменение дизайна
- Анализ протокола безопасности
- Анализ скорости загрузки страницы
Postman: Постман представляет собой мультитул для тестирования API. В нем можно создавать коллекции запросов, проектировать дизайн API и создавать для него моки (заглушки-имитации ответов реального сервера), настраивать мониторинг (периодическая отправка запросов с журналированием), для запросов возможно написание тестов на JS, есть собственный Runner и т.д. Однако постман сложно назвать подходящим инструментом для серьезной автоматизации ввиду сложности поддержки тестов, но при этом он хорошо подойдет в простых случаях или как инструмент поддержки а анализа: проверка работоспособности endpoint, дебаг тестов, простая передача информации о дефектах (можно сохранить запрос в curl, ответ в json и т.п.). Postman также может работать без графического интерфейса (newman).
- Аналог: https://hoppscotch.io/
- Курс Тестирование ПО. Занятие 30. POSTMAN. Ручное тестирование API | QA START UP
- API testing using Postman
Proxy (снифферы трафика): Charles — инструмент для мониторинга HTTP/HTTPS трафика. Программа работает как прокси-сервер между приложением и сервером этого приложения. Charles записывает и сохраняет все запросы, которые проходят через него и позволяет их редактировать.
- Charles: незаменимый тул в арсенале QA-инженера
- Breakpoints charles proxy Подмена данных
- Как приручить Charles Proxy?
- Using Web Debugging Proxies for Application Testing
- Перехват SSL трафика с Android-приложения
- Certificate and Public Key Pinning
Тестирование безопасности:
- Чем искать уязвимости веб-приложений: сравниваем восемь популярных сканеров
- 20 мощных инструментов тестирования на проникновение в 2019 году
- 10 лучших инструментов сканирования уязвимостей для тестирования на проникновение – 2020
- Пентест веб сайта с помощью Owasp Zap
- Проверяем безопасность приложений с помощью Drozer
GIT:
Git - это консольная утилита, для отслеживания и ведения истории изменения файлов, в вашем проекте. Чаще всего его используют для кода, но можно и для других файлов. Например, для картинок - полезно для дизайнеров.
С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.
Так же ваши репозитории можно хранить и в интернете. Обычно для этого используют три сервиса: GitHub, Bitbucket, GitLab
Знать команды нужно для:
"1. Если надо что-то сделать с гитом по SSH.
2. Если надо сравнить диффы огромных файлов. Vimdiff вытянет, многие тулы сдохнут или будут сильно тормозить.
3. Тулы часто тупят и работают неправильно.
4. Хорошие тулы платные)" (с) @anton_smolianin
В любом случае, даже нажимая кнопки, требуется понимать, как это работает под капотом хотя бы на элементарном уровне.
Все что нужно для работы с GIT
- Git для новичков (часть 1)
- Git изнутри и на практике
- Git, я хочу все отменить! Команды исправления допущенных ошибок
SQL: Все что нужно для работы с SQL:
- Официальные сайты
- GUI клиенты
- Основы SQL
- Алан Бьюли "Изучаем SQL"
- Линн Бейли "Изучаем SQL"
- W3C Introduction to SQL
- guru99 | SQL Tutorial for Beginners: Learn SQL in 7 Days
- Продвинутый уровень
- Энтони Молинаро "SQL. Сборник рецептов"
- Алекс Кригель "SQL. Библия пользователя"
- Джеймс Грофф, Пол Вайнберг, Эндрю Оппель "SQL Полное руководство. Третье издание."
- Практика
- SQLAcademy | Онлайн тренажер с упражнениями по SQL
- SQLBolt | Introduction to SQL
- W3C | The Try-SQL Editor
- HackerRack SQL
- Упражнения по SQL
- Тест на знание SQL
- https://www.db-fiddle.com/
- Shit happens
Mind maps:
- 12 программ и сервисов для создания майндкарт
- Как нарисовать карту приложения (mind map)
- Mind map вместо тест-кейса, или Как визуализация позволяет тестировать приложение быстрее
- Mind Map в помощь тестировщику
- Mind Map в тестировании — или легкий способ тестировать сложные приложения
TMS: Топ-12 лучших систем управления тестированием 2020
Все зависит от компании и в меньшей степени от уровня позиции. В среднем это выглядит так:- Отклик на вакансию;
- *Опционально: выполнение тестового задания, п.2 и п.3 могут меняться местами;
- Скрининг по телефону (небольшая беседа с HR);
- Полноценное собеседование с HR;
- Техническое собеседование, п.4 и п.5 иногда делают за раз;
- *Опционально: собеседование с боссом;
- Развитые софт-скиллы (например, уметь в коммуникацию, не перебивать собеседника и т.п.);
- Общая грамотность;
- Умение обучаться;
- Пытливый ум и желание выяснить первопричину проблемы;
- Устойчивость к рутине;
Доп. материал: Миф об образе мышления в тестировании
Кратко о базовых рекомендациях. Резюме стажера или джуниора – ровно 1 страница (имеется в виду вариант в файле, а не на площадках). Помимо PDF желательно иметь вордовскую копию на google-диске. Язык резюме – русский, если нацелены на компании из РФ с клиентами из РФ. В остальных случаях – английский. Лучший вариант оформления шапки:
Вообще на тему составления резюме в IT есть миллион статей (пример) и видео на youtube, да и не стоит исключать фактор личных пристрастий нанимателя, так что следует просто ознакомиться с базовыми рекомендациями, при желании скинуть итоговый вариант на оценку в коммьюнити и заняться более насущными вопросами. Насчет самих откликов, тут на мой взгляд уместна аналогия с холодными звонками, т.е. не нужно на начальном этапе выбирать место работы так, будто собираетесь в ней состариться. Вообще слать резюме стоит не только откликаясь на вакансии. Есть мнение, что когда компания уже выкинула вакансию на работные сайты, это уже тупик (т.к. не нашли кандидата по своим каналам). Шлите на почты компаний, HR-ов, расширяйте сеть контактов в linkedin и т.п.. Слышал, что активные джуны рассылали по несколько сотен писем в неделю. Стоит ли говорить, что они быстро нашли свою первую работу?
Доп. материал:
- Что писать в резюме, если нет опыта работы
- Инхаус, фриланс, аутсорс компания: куда приземлиться тестировщику, чтобы не разлюбить профессию и расти как на дрожжах
- Официальное ли оформление, тип. Белая ли заработная плата? Предусмотрены ли премии?
- Есть ли KPI, что в них входит?
- Какой график работы, как происходят отработки?
- Как часто бывают переработки и оплачиваются ли они?
- Время начала рабочего дня и отношение к опозданиям?
- Схема карьерного роста, матрица компетенций, период и порядок пересмотра з.п.?
- Приветствуется ли инициатива и если нет, насколько она наказуема?
- Есть ли командировки, какие направления и как часто?
- Что входит в социальный пакет и когда он предоставляется?
- Если работа удаленная или частично удаленная — какая техника предоставляется?
- Как организовано рабочее место, что в него входит? Опенспейс или кабинет?
- Есть ли наставничество или менторство в первое время работы в компании?
- Практикуется ли компенсация обучения, заинтересован ли работодатель в сертификации, участии сотрудника в митапах, конференциях и т.п.?
- Как осуществляется контроль за сотрудниками: есть ли тайм-трекеры, камеры и т. д.?
- Наличие спортзала, столовой, душа?
- Наличие библиотеки с актуальной литературой?
Если на собеседовании несколько иерархически подчиненных человек (HR и директор, начальник отдела и директор или топ-менеджер), обратите внимание на модель их общения, на то, слаженно ли они работают, есть ли контакт или же только благоговейное молчание. Команду видно издалека.
- Как отнеслись к вашему резюме: оно одно из многих и вы здесь «на потоке» или оно лежит одно, и вы в фокусе.
- Как распределено время на собеседование и часто ли отвлекаются его участники, вовремя ли начато общение или вам пришлось ждать больше 15 минут.
- Как вам представили руководителя — с регалиями или нет, по имени-отчеству или имени, формально или неформально.
- Как отнеслись к ходу решения вами заданий — как к экзамену или как к деловому обсуждению задачи. Это говорит о вашем уровне в глазах собеседующего.
Собеседование на английском языке практическое такое же*, просто из-за языкового барьера могут возникать трудности. Практикуйтесь! И помните, что вашему собеседнику может быть так же трудно, как и вам. *- при собеседовании в другую страну следует учитывать культурные особенности (да и законодательство), потому что некоторые ценности и взгляды могут совершенно не очевидным образом быть разными и при этом иметь решающее значение. Здесь нужно целенаправленно читать статьи о найме или релокации в интересующую страну, там упоминаются эти нюансы и особенности. Доп. материал:
- Вопросы для собеседования — от кандидата к работодателю
- Как собеседовать работодателя?
- О чем поговорить на собеседовании с выпускником онлайн-курсов по тестированию
- Как QA найти «ту самую» компанию и стать тимлидом
- Собеседование для QA: резюме, вопросы на интервью, переговоры о зарплате + полезные ссылки
- Сценарий идеального технического собеседования
- Собеседование для собеседующих
- Обратное собеседование
- Чек-лист для подготовки к собеседованию на английском (linkedin, в РФ нужен VPN/proxy)
- Во всем видят дефекты. Как избежать:
- Внимательно анализировать требования
- Владеть информацией о том, как должен работать продукт
- Если сомневаешься, что это дефект – спроси БА или ответственного
- Несколько раз перепроверь прежде чем регистрировать дефект
- Пытаются сразу все сломать. Как избежать:
- Начинать тестирование только с положительных тестов
- Акцентировать внимание на том, что в приоритете для заказчика
- Не проверять редкие сценарии в первую очередь
- Боятся задавать вопросы. Как избежать:
- Начать понимать, что коммуникация это важная и неотъемлемая часть работы
- Не интересуются, кто и за что отвечает, как устроены процессы. Как избежать:
- Узнать у ПМ об областях ответственности каждого члена команды
- Узнать у ПМ о всех процессах на проекте
- Паникуют при малейшей трудности. Как избежать:
- Без паники, п. 3 и 4 помогут разобраться
- Пытаются применить сразу все, что изучили. Как избежать:
- Помнить, что у каждого вида тестирования своя цель
- Бюджет всегда ограничен, расставлять приоритеты
- Задают один и тот же вопрос несколько раз
- Дёргают разработчиков по каждой мелочи (прерывают состояние потока, контекст. Разработка требует держать огромное количество абстракций в голове во время работы над задачей. Это очень легко сбить элементарным вопросом, который находится в первой строчке поисковой выдачи)
Доп. материал:
- Как выжить на новой работе или онбординг снизу
- Шесть тест-персон, с которыми не стоит иметь дела
- Лучше не знать и спросить, чем притворяться, что знаешь, или Шесть подсказок новичку в тестировании
- Мои 3 ошибки, которые я совершала как junior QA engineer
Доп. материал:
- Как организовать работу QA. Один практически примененный способ
- Как QA организовать автоматизацию тестирования на проекте. Один практически примененный способ
- Как QA выстроить эффективное взаимодействие с разработчиками. Один возможный путь
- Никогда такого не было и вот опять: Построение отдела тестирования - Андрей Мясников. QA Fest 2018
- Процесс: как наладить, а не нагадить - Андрей Мясников. QA Fest 2015
- Как проходит организация тестирования и составление тест планов (в зависимости от проекта)
- Концепция построения процесса тестирования в Agile-проектах: 3+1
- Построение процессов тестирования на новом проекте
- Мифы о тестировании #2 / О чем не говорят на курсах по тестированию / Правда о работе в IT
- Что нужно знать о Value Driven Testing. Анализируем ценность и экономическую целесообразность тестирования
- Расскажи о себе (все что хочешь, что нам нужно знать о тебе)
- Есть ли релевантный опыт?
- Какие курсы проходил и вообще, что изучал?
- Что не устраивало на прошлом месте работы (если было), особенно если решил сменить сферу?
- Почему выбрал именно тестирование?
- Чем заинтересовала именно наша компания?
- Как часто бываешь на собеседованиях?
- Уровень английского? (вопрос могут задать на английском, многие теряются в этот момент)
- (Если требуется и уровень хороший) расскажите на английском: как доехали до собеседования/о себе (только не как в обществе анонимных алкоголиков) /почему считаешь, что можешь стать тестировщиком/ как прошел вчерашний день/о своих хобби/ и т.п.
- Как в целом смотришь на мир, как решаешь возникающие проблемы?
- 3 твоих сильных и 3 слабых стороны?
- Как отдыхаешь? Как проводишь свободное время?
- Какие хобби?
- Что последнее прочитал техническое? Не техническое?
- Если бы мог вернуться в начало осознанной жизни, выбрал бы иной карьерный путь?
- 3 примера, что тебе положительного дал предыдущий опыт работы (если есть)
- 3 плюса и 3 минуса в сфере тестирования лично для тебя
- Как видишь развитие в этой сфере, кем видишь себя через год, три?
- Какая-то одна вещь или ситуация, которой ты гордишься
- Представим, что остальных кандидатов много и они опытнее (обычно так и есть), может у тебя есть какие-то преимущества перед ними? Почему ты думаешь, что лучше других кандидатов?
- Зарплатные ожидания сейчас, после испытательного срока, через год?
- Есть ли какие-то факторы, с которыми ты согласишься на меньшие деньги?
- С чем точно не готов мириться в отношении компании или руководителя?
- Ожидания от работы?
- Отношение к переработкам?
- Представь, что ты работаешь уже полгода. Опиши свой рабочий день.
- Что если при выполнении задачи понимаешь, что не укладываешься в сроки?
- Процесс тестирования гарантирует, что ПО будет работать в соответствии с ожиданиями клиентов и на имеющемся у них оборудовании.
- Это уменьшает циклы кодирования, выявляя проблемы на начальном этапе разработки. Обнаружение проблем на более ранних этапах SDLC обеспечивает правильное использование ресурсов и предотвращает повышение стоимости.
- Команда тестирования привносит взгляд клиента в процесс и находит варианты использования, о которых разработчик может не подумать.
- Любой сбой, дефект или ошибка, обнаруженные клиентом в готовом продукте, нарушают доверие к компании.
- Определение всех лиц, так или иначе заинтересованных в исполнении и результатах данного проекта.
- Определение критериев, формирующих представление о качестве для каждого из участников.
- Приоритезацию критериев, с учетом важности конкретного участника для компании, выполняющей проект, и важности каждого из критериев для данного участника.
- Определение набора критериев, которые будут отслежены и выполнены в рамках проекта, исходя из приоритетов и возможностей проектной команды. Постановка целей по каждому из критериев.
- Определение способов и механизмов достижения каждого критерия.
- Определение стратегии тестирования исходя из набора критериев, попадающих под ответственность группы тестирования, выбранных приоритетов и целей.
- https://analytics.infozone.pro/software-quality/
- https://www.intuit.ru/studies/courses/48/48/lecture/1440?page=1
- Кто несет ответственность за качество тестирования приложения? 10 причин попадания ошибки в продакшен
- На ком лежит ответственность за качество программного обеспечения?
- What Is Cost Of Quality (COQ): Cost Of Good And Poor Quality
- Верификация — это процесс включающий в себя проверку Plans, Requirement Specifications, Design Specifications, Code, Test Cases, Check-Lists, etc.
- Верификация всегда проходит без запуска кода.
- Верификация использует методы — reviews, walkthroughs, inspections, etc.
- Верификация отвечает на вопрос "Делаем ли мы продукт правильно?"
- Верификация поможет определить, является ли программное обеспечение высокого качества, но оно не гарантирует, что система полезна. Проверка связана с тем, что система хорошо спроектирована и безошибочна.
- Верификация происходит до Validation.
- Inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process. (Fagan inspection)
- Walkthroughs In software engineering, a walkthrough or walk-through is a form of software peer review «in which a designer or programmer leads members of the development team and other interested parties go through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems».
- Reviews In software development, peer review is a type of software review in which a work product (document, code, or other) is examined by its author and one or more colleagues, in order to evaluate its technical content and quality.
- Валидация всегда включает в себя запуск кода программы.
- Валидация использует методы, такие как тестирование Black Box, тестирование White Box и нефункциональное тестирование.
- Валидация отвечает на вопрос "Делаем ли мы правильный продукт?"
- Валидация проверяет, соответствует ли программное обеспечение требованиям и ожиданиям клиента.
- Валидация может найти ошибки, которые процесс Verification не может поймать.
- Валидация происходит после Verification.
| Верификация | Валидация |
| По факту отвечает на вопрос, правильно ли создается и тестируется ПО и все ли требования учитываются при этом. | Отвечает на вопрос, создается ли продукт правильно с точки зрения ожиданий клиента. |
| В процессе верификации убеждаемся в том, что весь созданный функционал приложения работает корректно и логически верно. | При процессе валидации убеждаемся в том, что продукт полностью соответствует поведению, которое от него ожидается и то, что клиент знает о наличии подобного функционала. |
| В структуру верификации входят такие компоненты, как сверка завалидированным требованиям, технической документации и корректное выполнения программного кода на любом этапе создания и тестирования ПО. | Валидация, по своей сути, в большей степени включает в себя общую оценку ПО и может основываться исключительно на субъективном мнении касательно правильности работы приложения или его компонентов. |
Источник: Верификация и валидация Доп. материал:
- Большое обсуждение: Verification & Validation - что это такое?
- Чем отличается валидация от верификации
- Тестирование демонстрирует наличие дефектов
- Исчерпывающее тестирование недостижимо
- Раннее тестирование
- Скопление/кластеризация дефектов
- Парадокс пестицида
- Тестирование зависит от контекста
- Заблуждение об отсутствии ошибок
- Garbage in, garbage out (GIGO)
Принцип 1. Тестирование показывает наличие дефектов Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов нет. Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку. Но если мы нашли хотя бы один дефект, мы уже можем утверждать, что в данном ПО присутствуют дефекты.
Принцип 2. Исчерпывающее тестирование невозможно Вместо попыток «протестировать все» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками – одна из наиболее важных активностей в любом проекте.
Принцип 3. Раннее тестирование Тестовые активности должны начинаться как можно раньше в цикле разработки и быть сфокусированы на определенных целях. Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить. Дефект, найденный в требованиях, обходится дешевле всего. Еще одно важное преимущество раннего тестирования – экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.
Принцип 4. Скопление дефектов Небольшое количество модулей содержит большинство дефектов, обнаруженных на этапе предрелизного тестирования, или же демонстрируют наибольшее количество отказов на этапе эксплуатации. Многие тестировщики наблюдали такой эффект – дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов – тестировщики фокусируются на известных «проблемных зонах». Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
Принцип 5. Парадокс пестицида
Если повторять те же тесты снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты. Повторное применение тех же тестов и тех же методик приводит к тому, что в продукте остаются именно те дефекты, против которых эти тесты и эти методики неэффективны.
Чтобы преодолеть «парадокс пестицидов», необходимо регулярно пересматривать существующие тест-кейсы и создавать новые, разнообразные тесты, которые будут выполняться на различных частях системы.
Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск – это потенциальная проблема. У риска есть вероятность (likelihood) – она всегда выше 0 и ниже 100% – и есть влияние (impact) – те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние.
То же можно сказать и о мире ПО: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьируется. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей. Заказчики ПО – люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи – на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают. Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей. Иначе говоря, верификация != валидация.
- Принцип 8. GIGO. В компьютерной науке «garbage in – garbage out» (GIGO) — это концепция, в которой ошибочные или бессмысленные входные данные создают бессмысленный вывод или «мусор», т.е. при неверных входящих данных будут получены неверные результаты, даже если сам по себе алгоритм правилен. В тестировании такие случаи иногда создают намеренно, но я добавил этот принцип в общий список для того, чтобы подчеркнуть важность подготовки качественных тестовых данных, положительные они или отрицательные.
Доп. материал: The Cold Hard Truth About Zero-Defect Software
Требования к идеальному критерию тестирования:- Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы.
- Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.
- Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы.
- Критерий должен быть легко проверяемым, например вычисляемым на тестах.
- Структурные критерии используют информацию о структуре программы (критерии так называемого "белого ящика").
- Функциональные критерии формулируются в описании требований к программному изделию ( критерии так называемого "черного ящика" ).
- Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.
- Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.
- Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
- Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
- Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раза. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто - 2, или числом классов выходных путей).
- Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза. Спецификация требований может содержать сотни и тысячи пунктов требований к программному продукту и каждое из этих требований при тестировании должно быть проверено в соответствии с критерием не менее чем одним тестом.
- Тестирование классов входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что перебирая в соответствии с критерием величины входных переменных (например, различные файлы - источники входных данных), мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия.
- Тестирование правил - набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики. Следует заметить, что грамматика должна быть достаточно простой, чтобы трудоемкость разработки соответствующего набора тестов была реальной (вписывалась в сроки и штат специалистов, выделенных для реализации фазы тестирования).
- Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out). При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
- Тестирование функций - набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза. Очень популярный на практике критерий, который, однако, не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту). Критерий тестирования функций объединяет отчасти особенности структурных и функциональных критериев. Он базируется на модели "полупрозрачного ящика", где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
- Комбинированные критерии для программ и спецификаций - набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза. При этом все комбинации непротиворечивых условий надо подтвердить, а условия противоречий следует обнаружить и ликвидировать.
Стохастическое тестирование применяется при тестировании сложных программных комплексов - когда набор детерминированных тестов (X,Y) имеет громадную мощность. Мутационный критерий (класс IV). Постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа - перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе. Подход базируется на следующих понятиях: Мутации - мелкие ошибки в программе. Мутанты - программы, отличающиеся друг от друга мутациями . Метод мутационного тестирования - в разрабатываемую программу P вносят мутации, т.е. искусственно создают программы-мутанты P1, P2... Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X,Y). Если на наборе (X,Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной. Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X,Y) и продолжать тестирование.
Подробнее и с примерами в источнике: https://www.intuit.ru/studies/courses/48/48/lecture/1428?page=1 Доп. материал: https://www.youtube.com/watch?v=qkUCzvP-5mg&t=20547s
Impact Analysis (импакт анализ) - это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты. Затронутые области требуют большего внимания во время проведения регрессионного тестирования. Импакт анализ может быть полезным в следующих случаях:- есть изменения в требованиях;
- получен запрос на внесение изменений в продукт;
- ожидается внедрение нового модуля или функциональности в существующий продукт;
- каждый раз, когда есть изменения в существующих модулях или функциональностях продукта.
- сфокусироваться на тестировании функциональности, где изменения были представлены;
- принять во внимание части проекта, которые были затронуты изменениями и, возможно, пострадали;
- не тратить время на тестирование тех частей проекта, которые не были затронуты изменениями.
Источник: Impact Analysis: 6 шагов, которые облегчат тестирование изменений
Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Сложность современного ПО и инфраструктуры сделало невыполнимой задачу проведения тестирования со 100% тестовым покрытием. Поэтому для разработки набора тестов, обеспечивающего более-менее высокий уровень покрытия можно использовать специальные инструменты либо техники тест дизайна. Существуют следующие подходы к оценке и измерению тестового покрытия:- Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceability matrix).
- Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей ПО.
- Тестовое покрытие на базе анализа потока управления - это одна из техник тестирования белого ящика, основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.
- Метод оценки покрытия кода не выявит нереализованные требования, так как работает не с конечным продуктом, а с существующим исходным кодом.
- Метод покрытия требований может оставить непроверенными некоторые участки кода, потому что не учитывает конечную реализацию.
Альтернативное мнение:
Покрытие кода — совершенно бесполезная метрика. Не существует «правильного» показателя. Это вопрос-ловушка. У вас может быть проект со 100% покрытием кода, в котором по-прежнему остаются баги и проблемы. В реальности нужно следить за другими метриками — хорошо известными показателям CTM (Codepipes testing Metrics).
PDWT (процент разработчиков, пишущих тесты) — вероятно, самый важный показатель. Нет смысла говорить об антипаттернах тестирования ПО, если у вас вообще нет тестов. Все разработчики в команде должны писать тесты. Любую новую функцию можно объявлять сделанной только если она сопровождается одним или несколькими тестами.
PBCNT (процент багов, приводящих к созданию новых тестов). Каждый баг в продакшне — отличный повод для написания нового теста, проверяющего соответствующее исправление. Любой баг должен появиться в продакшне не более одного раза. Если ваш проект страдает от появления повторных багов даже после их первоначального «исправления», то команда действительно выиграет от использования этой метрики.
PTVB (процент тестов, которые проверяют поведение, а не реализацию). Тесно связанные тесты пожирают массу времени при рефакторинге основного кода.
PTD (процент детерминированных тестов от общего числа). Тесты должны завершаться ошибкой только в том случае, если что-то не так с бизнес-кодом. Если тесты периодически ломаются без видимой причины — это огромная проблема.
Если после прочтения о метриках вы по-прежнему настаиваете на установке жесткого показателя для покрытия кода, я дам вам число 20%. Это число должно использоваться как эмпирическое правило, основанное на законе Парето. 20% вашего кода вызывает 80% ваших ошибок
Доп. материал: Лекция 4: Оценка оттестированности проекта: метрики и методика интегральной оценки
Существует определение Maturity Models, то есть модели зрелости различных процессов в организации, состоящая из 5 уровней. Нас же в рамках этого материала интересует один конкретный подвид моделей MM - модель зрелости тестирования, которая тоже состоит из 5 уровней. TMM в свою очередь основан на модели зрелости возможностей (CMM — Capability Maturity Model). Модель зрелости ПО (CMM или SW-CMM) — это модель для оценки зрелости программных процессов в организации. В ней также перечислены некоторые стандартные практики, которые увеличивают зрелость этих процессов. TMM это подробная модель для улучшения процесса тестирования. Она может быть дополнена любой моделью улучшения процесса или может использоваться как одиночная модель. Модель ТММ имеет два основных компонента:- Набор из 5 уровней, которые определяют возможности тестирования (testing capability)
- Модель оценки (An Assessment Model)
- Уровень 1. Начальный. ПО должно успешно работать.
- На этом уровне области процессов не определены.
- Цель тестирования — убедиться, что ПО работает нормально.
- На этом уровне не хватает ресурсов, инструментов и обученного персонала.
- Нет проверки качества перед поставкой ПО.
- Уровень 2. Определенный. Разработка целей и политик тестирования и отладки.
- Этот уровень отличает тестирование от отладки, и они считаются различными действиями.
- Этап тестирования наступает после кодирования.
- Основная цель тестирования — показать, что ПО соответствует спецификации.
- Основные методы и методики тестирования.
- Уровень 3: Комплексный. Интеграция тестирования в жизненный цикл ПО.
- Тестирование интегрируется в весь жизненный цикл.
- На основании требований определяются цели испытаний.
- Структура тестирования существует.
- Тестирование на уровне профессиональной деятельности.
- Уровень 4: Управление и измерение. Создание программы тестовых измерений.
- Тестирование — это измеренный и количественный процесс.
- Проверка на всех этапах разработки признается как тестирование.
- Для повторного использования и регрессионного тестирования есть Test case и они записаны в базу тестов.
- Дефекты регистрируются и получают уровни серьезности.
- Уровень 5: Оптимизированный. Оптимизация процесса тестирования.
- Тестирование управляется и определено.
- Эффективность и стоимость тестирования можно отслеживать.
- Тестирование может постоянно настраиваться и улучшаться.
- Практика контроля качества и предотвращения дефектов.
- Практикуется процесс повторного использования (Reuse).
- Метрики, связанные с тестированием, также имеют средства поддержки.
- Инструменты обеспечивают поддержку разработки тестовых наборов и сбора дефектов.
Доп. материал: 7 подходов к тестированию
В попытке перенести тестирование на более ранний этап жизненного цикла разработки при одновременном улучшении показателей качества, задачи смещаются влево в схеме жизненного цикла разработки ПО. По возможности, тестирование должно проводиться с самого начала фазы проектирования, чтобы построить соответствующую стратегию тестирования. Проще говоря, это подход к тестированию программного обеспечения и тестированию системы, при котором тестирование выполняется на более раннем этапе жизненного цикла. Ключевые преимущества:- Сокращение затрат
- Более высокое качество
- Повышение эффективности
- Конкурентные преимущества
Доп. материал: Экономим ресурсы и успеваем в срок: зачем подключать QA-инженера в начале работы над фичей
Можете ли вы доверять вердикту судьи, который является частью внутреннего круга людей, которых он должен судить? Чтобы этот процесс был справедливым, лица, принимающие решения, должны быть беспристрастными. Теперь, когда вы активно участвуете в разработке какого-либо продукта или программного обеспечения, тестировать его с нейтральным мышлением это легче сказать, чем сделать. Как разработчик, вы бы хотели отгружать продукт в кратчайшие сроки и считать его безупречным и в конечном итоге упустите из виду некоторые ошибки. Чтобы избежать такой ситуации, иногда следует нанять независимую организацию по тестированию, которая тщательно проверит ваш продукт на наличие сбоев, готовя его к развертыванию. Тестирование по уровням независимости:- Программист тестирует свой код
- Тестирование проводится другим программистом в организации
- Внутренняя команда тестирования
- Независимая организация тестирования
- Когда программист проверяет свой код: Вы бы никогда не попросили шеф-повара быть его собственным критиком. И даже если вы это сделаете, вам будет трудно поверить всему, что он говорит. Смысл - создатель никогда не может быть хорошим критиком своей собственной работы. Программист знает свой код от и до. Их цель - создать продукт и отправить его в кратчайшие сроки. Вместо того, чтобы искать ошибки со всех возможных точек зрения, они будут искушены найти способы обойти найденные ошибки. Писатель Гленфорд Майерс в своей книге «Искусство тестирования программного обеспечения» перечислил разницу в мышлении разработчика и тестировщика. Он сказал, что разработчик думает как строитель, сосредоточенный на строительстве, в то время как тестировщик ищет недостатки, которые приведут к разрушению здания, если не будут решены.
- Тестирование проводится другим программистом в организации: Компромисс - это найти кого-то в организации. Это может быть какой-то другой программист, который участвует в некоторых других проектах. Это дает определенный уровень независимости. Но проблема возникает из-за того же reporting manager. Менеджер может попросить программиста пропустить некоторые тесты, когда есть ограничения по времени. Это приведет к неполному тестированию продукта. Кроме того, если попросить других разработчиков провести тестирование, это приведет к развертыванию различных ресурсов в одном проекте. Это будет вредно для всей работы организации.
- Внутренняя команда тестирования: Наличие другой внутренней команды - это хорошее решение. Но поскольку они будут в организации, на них будут влиять ограничительные сроки. Кроме того, это будет дорого поддерживать внутреннюю команду. Это приведет к большим бюджетным и ресурсным ограничениям для команды. Команда может иметь доступ к ограниченным инструментам и программному обеспечению, таким образом, не отвечая требованиям всех проектов. Среда тестирования также будет варьироваться в зависимости от количества пользователей и числа выполненных интеграций. Затем тестирование будет проводиться в спешном порядке, что приведет к упущению некоторых ошибок, которые могут появиться после выпуска продукта. Решение, которое позаботится обо всех этих недостатках, - «Независимое тестирование».
- Почему независимое тестирование? Независимые тестирующие организации изучат все аспекты вашей продукции. Они работают с мышлением поиска недостатков и ошибок. Они не будут использовать ярлыки в процессе тестирования. И поскольку они не были частью процесса разработки, они будут проводить тесты на нейтральной основе, чтобы прежние интересы не мешали процессу тестирования. Мысль о поиске максимальных «точек останова» пойдет на пользу вашему продукту. Почти все сторонние тестирующие организации предоставят вам подробные отчеты об ошибках и предложат корректирующие меры.
В чем разница между превентивным и реактивным подходами в тестировании? (Preventative and Reactive approaches)
- Превентивный (профилактический) подход: он также известен как Verification Process. Этот подход заключается в предотвращении дефектов. При таком подходе тесты разрабатываются на ранних этапах SDLC, то есть до того, как программное обеспечение было создано. Он подпадает под анализ качества (QA).
- Реактивный подход: он также известен как Validation Process. Этот подход заключается в выявлении дефектов. При таком подходе тесты предназначены для выполнения после того, как программное обеспечение было произведено. Здесь мы пытаемся найти недостатки. Подпадает под контроль качества (QC).
- Команда QA отвечает за мониторинг всего процесса разработки.
- Они несут ответственность за отслеживание результатов каждого этапа SDLC и корректировку их в соответствии с ожиданиями.
- Они несут ответственность за чтение и понимание необходимых документов.
- Анализируют требования к тестированию, а также разрабатывают и выполняют тесты.
- Разрабатывают Test case и расставляют приоритеты в тестировании.
- Записывают проблемы и инциденты в соответствии с задачами проекта и планами управления инцидентами.
- Работают с командой приложения и/или клиентом для решения любых проблем, возникающих в процессе тестирования.
- Проводят регрессионное тестирование каждый раз, когда в код вносятся изменения для исправления дефектов.
- Должны взаимодействовать с клиентами, чтобы лучше понять требования продукта.
- Принимают участие в прохождении процедур тестирования.
- Каждый этап испытаний имеет свое назначение
- Проще управлять поэтапно
- Мы можем запустить разные тесты в разных средах
- Производительность и качество тестирования улучшаются с помощью поэтапного тестирования
- Спецификации ПО могут быть субъективными и приводить к различным интерпретациям.
- ПО может потребоваться слишком много входов, слишком много выходов и слишком много комбинаций путей для тестирования.
- Улучшение документа продукта
- Улучшение процесса (как производства документов, так и проверки)
Доп. материал:
- Product Owner vs Product Manager или Product Owner/Product Manager
- Продакт-менеджмент как профессия: востребованность, зарплата и другие нюансы
- Кто такой продакт-менеджер? Или не все PM’ы — проджект-менеджеры
- Knowledge management: как перестать изобретать велосипеды
- Заметки knowledge manager'a. Как работает управление знаниями в Exness
- Профессия СТО
- Кто такой DevOps-инженер, что он делает, сколько зарабатывает и как им стать
- Гайд по DevOps для начинающих
Опишите жизненный цикл продукта по этапам - какие участники на каждом этапе, какие у них роли? Какие артефакты на каждом этапе?
- Анализ. Участники: Product owner, BA(бизнес-аналитик), QA. Артефакты: спецификация требований к ПО (Software Requirement Specification, SRS).
- Проектирование. Участники: Product owner, разработчики, системные архитекторы, QA. Артефакты: дизайн-спецификация (Design Specification Document, DSD), Тест-план, тест-сценарии, тест-кейсы; вариативно: тестовая стратегия.
- Разработка. Участники: разработчики. Артефакты: -.
- Тестирование. Участники: QA. Артефакты: дефект-репорты, сводный отчет о тестировании.
- Внедрение и сопровождение. Участники: команда технической поддержки. Артефакты: замечания, запросы на исправление/улучшение.
| SDET | Manual Tester |
| Знает всю систему от начала до конца | Ограниченные знания о системе |
| SDET участвует в каждом этапе процесса разработки ПО, как Проектирование, разработка и тестирование. | QA участвует только в жизненном цикле тестирования процесса разработки ПО. |
| Высококвалифицированный специалист со знаниями как в разработке, так и в тестировании | Тестировщик ПО участвует только в подготовке и выполнении Test case |
| SDET может участвовать в разработке средств автоматизации тестирования | Не ожидается разработка средств автоматизации тестирования. |
| SDET должны выполнять такие обязанности, как тестирование производительности, автоматическое создание тестовых данных и т. д. | Только задачи по ручному тестированию |
| Знает требования и гайдлайны для продуктов | От QA таких знаний не ожидается. |
- Среда разработки (Development Env) – в ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.
- Среда тестирования (Test Env) – в этой среде работают тестировщики. Тут тестируются новые билды. Здесь тестировщики проверяют функционал, проводят регрессионные проверки, воспроизводят ошибки. Эта среда появляется во время начала динамического тестирования;
- Интеграционная среда (Integration Env) – иногда реализована в рамках среды тестирования, а иногда в рамках превью среды. В этой среде собрана необходимая для end-to-end тестирования схема взаимодействующих друг с другом модулей, систем, продуктов. Собственно, необходима она для интеграционного тестирования. Поддержка среды – также, как и в случае со средой тестирования
- Превью среда (Preview, Preprod Env) – в идеале, это среда идентичная или максимально приближенная к продуктивной: те же данные, то же аппаратно-программное окружение, та же производительность. Она используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к «боевым». Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и/или пользователи проводят UAT, а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.
- Продакшн среда (Production Env) – среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3
Доп. материал:
Тестовые данные - это набор входных значений, необходимых для выполнения Test case. тестировщики определяют данные в соответствии с требованиями. Они могут сделать это вручную или использовать инструменты генерации.- Pre-Alpha: - ПО является прототипом. Пользовательский интерфейс завершен. Но не все функции завершены. На данном этапе ПО не публикуется.
- Alpha: является ранней версией программного продукта. Цель - вовлечь клиента в процесс разработки. Хороший Альфа-тест должен иметь четко определенный план тестирования с комплексными тестовыми примерами. Это дает лучшее представление о надежности программного обеспечения на ранних стадиях. В некоторых случаях тестирование может быть передано на аутсорс.
- Beta: ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
- Release Candidate (RC): основываясь на отзывах Beta Test, вы вносите изменения в ПО и хотите проверить исправления ошибок. На этом этапе вы не хотите вносить радикальные изменения в функциональность, а просто проверяете наличие ошибок. RC также выпущен для общественности
- Release: Все работает, ПО выпущено для общественности.
- Традиционное бета-тестирование: продукт распространяется на целевой рынок, и соответствующие данные собираются по всем аспектам. Эти данные могут быть использованы для улучшения продукта.
- Публичное бета-тестирование: продукт публикуется во внешнем мире через онлайн-каналы, и данные могут быть получены от любого пользователя. На основе обратной связи могут быть сделаны улучшения продукта.
- Техническое бета-тестирование: продукт передается во внутреннюю группу организации и собирает отзывы / данные от сотрудников организации.
- Целевая бета-версия: продукт выпущен на рынок для сбора отзывов об особенностях программы.
- Бета-версия после выпуска. Продукт выпущен на рынок, и данные собираются для внесения улучшений в будущем выпуске продукта.
- Функциональные виды («Что?» - проверяет весь функционал продукта):
- Функциональное тестирование (Functional testing)
- Тестирование взаимодействия (Interoperability testing)
- Нефункциональное («Как?»):
- Производительности (Performance)
- Тестирование емкости/способностей (Capacity testing)
- Стрессовое (Stress testing)
- Нагрузочное (Load testing)
- Объемное тестирование (Volume testing)
- Выносливости (Soak/Endurance testing)
- Стабильности/надежности (Stability / Reliability testing)
- Шиповое (Spike)
- Отказоустойчивости (Stability testing)
- Масштабируемости (Scalability test)
- Отказ и восстановление (Failover and Recovery testing)
- Удобство пользования (Usability testing)
- Тестирование установки (Installation testing)
- Тестирование безопасности (Security and Access Control testing)
- Конфигурационное (Configuration testing)
- Связанное с изменениями:
- Регрессионное (Regression testing)
- Санитарное (Sanity testing)
- Дымовое (Smoke testing)
- Тестирование сборки (Build Verification testing)
- Охват операторов: - Этот метод требует, чтобы каждое возможное утверждение в коде было проверено хотя бы один раз в процессе тестирования разработки ПО.
- Покрытие ветвления - этот метод проверяет все возможные пути (если-еще и другие условные циклы) программного приложения.
- Матричное тестирование: этот метод тестирования включает в себя определение всех переменных, которые существуют в их программах.
- Регрессионное тестирование: чтобы проверить, повлияло ли изменение в предыдущей версии другие аспекты программы в новой версии.
- Тестирование ортогональных массивов или OAT: обеспечивает максимальное покрытие кода с минимальным количеством тестов.
- Pattern testing: это тестирование выполняется на данных истории предыдущих дефектов системы. В отличие от тестирования черного ящика, в тестировании серого ящика копаются в коде и определяют причину сбоя.
Доп. материал:
- Пирамида тестов на практике
- Антипаттерны тестирования ПО
- Unit, API и GUI тесты — чем отличаются
- Почему тестировать должны не только QA. Распределяем тест-кейсы между Dev, Analyst и QA
- The Practical Test Pyramid
- Test Pyramid
- Метод анализа точек отказа: это пошаговое прохождение системы, проводящее оценку того, что может пойти не так в разных точках. Для этой стратегии может быть использована помощь BA (Business Analyst).
- Экспертная проверка тестировщика: проанализируйте или дайте на ревью ваши Test вашему коллеге-тестировщику, который менее знаком с системой/функцией
- Бизнес-анализ тестовых случаев. Конечные пользователи или эксперты могут подумать о многих допустимых сценариях, которые иногда тестировщики могут не учитывать или упустить, так как все их внимание будет сосредоточено на тестировании требований.
- Проведите предварительное тестирование с использованием контрольных таблиц (run sheets). Исследовательское тестирование с использованием контрольных таблиц поможет определить, что было проверено, повторить тесты и позволит вам контролировать охват тестами.
- Используйте другой источник: вы можете попросить кого-нибудь сломать программный продукт и проанализировать различные сценарии.
Доп. материал: Топ 10 негативных кейсов
НЕДЕСТРУКТИВНОЕ ТЕСТИРОВАНИЕ - это тип тестирования программного обеспечения, который включает в себя правильное взаимодействие с программным обеспечением. Другими словами, неразрушающее тестирование (NDT) также можно назвать позитивным тестированием или тестированием «счастливого пути». Это дает ожидаемые результаты и доказывает, что программное обеспечение ведет себя так, как ожидалось. Пример: - Ввод правильных данных в модуль входа в систему и проверка, принимает ли он учетные данные и переходит на следующую страницу С этими терминами происходит путаница и даже глоссарий ISTQB не проясняет ситуацию. Обычно эти термины используют как синонимы, а конкретика варьируется от компании к компании. Но если копнуть и попробовать разобраться, получается примерно следующее: Модульное тестирование (юнит-тестирование). Модульные тесты используются для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками. Целью тестирования модуля является не демонстрация правильного функционирования модуля, а демонстрация наличия ошибки в модуле, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования. Изоляция тестируемого блока достигается с помощью заглушек (stubs), манекенов (dummies) и макетов (mockups). Являясь по способу исполнения структурным тестированием или тестированием "белого ящика", модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст). Тесты, связанные со структурным тестированием, строятся по следующим принципам:- На основе анализа потока управления. В этом случае элементы, которые должны быть покрыты при прохождении тестов, определяются на основе структурных критериев тестирования С0, С1,С2. К ним относятся вершины, дуги, пути управляющего графа программы (УГП), условия, комбинации условий и т. п.
- На основе анализа потока данных, когда элементы, которые должны быть покрыты, определяются при помощи потока данных, т. е. информационного графа программы.
- Конструирование УГП.
- Выбор тестовых путей.
- Генерация тестов, соответствующих тестовым путям.
- Статические методы.
- Динамические методы.
- Методы реализуемых путей.
- Тестирование компонентов в малом (CTIS — Component testing In Small). Тестирование компонентов может проводиться с или без изоляции остальных компонентов в тестируемом программном обеспечении или приложении. Если это выполняется с изоляцией другого компонента, то это называется CTIS. Пример: веб-сайт, на котором есть 5 разных веб-страниц, тестирование каждой веб-страницы отдельно и с изоляцией других компонентов.
- Тестирование компонентов в целом (CTIL — Component testing In Large). Тестирование компонентов, выполненное без изоляции других компонентов в тестируемом программном обеспечении или приложении, называется CTIL. Давайте рассмотрим пример, чтобы понять это лучше. Предположим, что есть приложение, состоящее из трех компонентов, таких как Компонент A, Компонент B и Компонент C. Разработчик разработал компонент B и хочет его протестировать. Но для того, чтобы полностью протестировать компонент B, некоторые его функции зависят от компонента A, а некоторые — от компонента C. Функциональный поток: A -> B -> C, что означает, что существует зависимость от B как от A, так и от C, заглушка - вызываемая функция, а драйвер - вызывающая функция. Но компонент A и компонент C еще не разработаны. В этом случае, чтобы полностью протестировать компонент B, мы можем заменить компонент A и компонент C заглушкой и драйверами по мере необходимости. Таким образом, в основном, компоненты A & C заменяются заглушками и драйверами, которые действуют как фиктивные объекты до тех пор, пока они фактически не будут разработаны.
| Unit testing | Component testing |
| Тестирование отдельных программ, модулей, функций для демонстрации того, что программа выполняется согласно спецификации | Тестирование каждого объекта или частей программного обеспечения отдельно с или без изоляции других объектов |
| Проверка в(на) соответствии с design documents | Проверка в(на) соответствии с test requirements, use case |
| Пишутся и выполняются(обычно) разработчиками | Тестировщиками |
| Выполняется первым | Выполняется после Unit |
Другой источник: Разница между компонентным и модульным тестированием: По-существу эти уровни тестирования представляют одно и тоже, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном тестировании - конкретные значения.
Доп. материал:
Интеграционное тестирование предназначено для проверки насколько хорошо два или более модулей ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). С технологической точки зрения интеграционное тестирование является количественным развитием модульного, поскольку так же, как и модульное тестирование, оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки ( Stub ) на месте отсутствующих модулей. Основная разница между модульным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. В частности, на уровне интеграционного тестирования часто применяются методы, связанные с покрытием интерфейсов, например, вызовов функций или методов, или анализ использования интерфейсных объектов, таких как глобальные ресурсы, средства коммуникаций, предоставляемых операционной системой. Больше: https://www.intuit.ru/studies/courses/48/48/lecture/1432?page=1 Уровни интеграционного тестирования:- Компонентный интеграционный уровень (Component Integration testing): Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
- Системный интеграционный уровень (System Integration testing): Проверяется взаимодействие между разными системами после проведения системного тестирования.
- Подход Большого взрыва:
- Инкрементальный подход:
- Нисходящий подход
- Подход снизу-вверх
- Сэндвич-подход
- Интеграционные тесты в микросервисах
- Лекция 6: Интеграционное тестирование и его особенности для объектно-ориентированного программирования
- использует базу данных,
- использует сеть для вызова другого компонента/приложения,
- использует внешнюю систему (например, очередь или почтовый сервер),
- читает/записывает файлы или выполняет другие операции ввода-вывода,
- полагается не на исходный код, а на бинарник приложения,
- Юнит-тесты легче поддерживать.
- Юнит-тесты легко воспроизводят пограничные случаи и редкие ситуации.
- Юнит-тесты выполняются гораздо быстрее интеграционных тестов.
- Сбойные юнит-тесты легче исправить, чем интеграционные.
- Полнота решения функциональных задач.
- Стрессовое тестирование - на предельных объемах нагрузки входного потока.
- Корректность использования ресурсов (утечка памяти, возврат ресурсов).
- Оценка производительности.
- Эффективность защиты от искажения данных и некорректных действий.
- Проверка инсталляции и конфигурации на разных платформах.
- Корректность документации
- на базе требований (requirements based): Для каждого требования пишутся Test case, проверяющие выполнение данного требования.
- на базе случаев использования (use case based): На основе представления о способах использования продукта создаются случаи использования системы (Use Cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся Test case, которые должны быть протестированы.
- имитирует фактическое использование системы;
- возможность упущения логических ошибок в программном обеспечении;
- вероятность избыточного тестирования.
- Аппаратное обеспечение: проверяет совместимость программного обеспечения с различными аппаратными конфигурациями.
- Операционные системы: Он проверяет ваше программное обеспечение на совместимость с различными операционными системами, такими как Windows, Unix*, Mac OS и т. д.
- Программное обеспечение: проверяет ваше разработанное программное обеспечение на совместимость с другим программным обеспечением. Например, приложение MS Word должно быть совместимо с другими программами, такими как MS Outlook, MS Excel, VBA и т. д.
- Сеть: оценка производительности системы в сети с различными параметрами, такими как пропускная способность, скорость работы, емкость.
- Браузер: проверяет совместимость вашего сайта с различными браузерами, такими как Firefox, Google Chrome, Internet Explorer и т. д.
- Устройства: проверяет совместимость вашего программного обеспечения с различными устройствами, такими как устройства USB-порта, принтеры и сканеры, другие мультимедийные устройства и Bluetooth.
- Mobile: проверка совместимости вашего программного обеспечения с мобильными платформами, такими как Android, iOS и т. д.
- Версии программного обеспечения. Он проверяет совместимость вашего программного приложения с различными версиями программного обеспечения. Например, проверка вашего Microsoft Word на совместимость с Windows 7, Windows 7 SP1, Windows 7 SP2, Windows 7 SP3.
- Тестирование обратной совместимости предназначено для проверки поведения разработанного аппаратного / программного обеспечения с использованием более старых версий аппаратного / программного обеспечения.
- Тестирование прямой совместимости заключается в проверке поведения разработанного аппаратного / программного обеспечения с использованием более новых версий аппаратного / программного обеспечения.
- Подключите (connect) два или более устройств от разных производителей
- Проверьте связь между устройствами
- Проверьте, может ли устройство отправлять / получать пакеты или фреймы друг от друга
- Проверьте, правильно ли обрабатываются данные на уровне сети и объектов
- Проверьте, правильно ли работают реализованные алгоритмы
- Результат в порядке: проверьте следующий результат. Результат не в порядке: используйте инструменты мониторинга, чтобы обнаружить источник ошибки
- Отчет о результатах в тестовом отчете.
- Производительность
- Функции
- Прочность (Robustness)
- Совместимость (Interoperability)
- Поведение системы
- Тестирование на соответствие (Compliance testing)
- Нагрузочное тестирование (Load testing)
- Стресс тестирование (Stress testing)
- Объемное тестирование (Volume testing)
| Conformance testing | Compliance testing |
| Conformance является формальным и точным способом тестирования стандартов | Compliance является неформальным и менее точным способом тестирования стандартов |
| Сертификация Conformance применима только к операционной системе, имеющей официальный Certification Authority | Операционная система, которая обеспечивает единый API (Portable Operating System Interface), считается совместимой |
| Conformance testing используется для тестирования системы, которая обеспечивает полную поддержку данных стандартов | Compliance testing используется для тестирования системы, обеспечивающей поддержку некоторых из указанных стандартов |
- Нефункциональное тестирование должно повысить удобство использования, эффективность, ремонтопригодность и portability продукта.
- Помогает снизить производственный риск и затраты, связанные с нефункциональными аспектами продукта.
- оптимизировать способ установки, настройки, выполнения, управления и мониторинга продукта.
- Собирать и производить измерения и метрики для внутренних исследований и разработок.
- Улучшать и расширять знания о поведении продукта и используемых технологиях.
Основные нефункциональные типы тестирования:
- Производительности (Performance)
- Стрессовое (Stress testing)
- Тестирование емкости/способностей (Capacity testing)
- Нагрузочное (Load testing)
- Объемное тестирование (Volume testing)
- Выносливости/стабильности/надежности (Soak/Endurance/Stability/Reliability testing)
- Шиповое (Spike)
- Масштабируемости (Scalability Test)
- Тестирование времени отклика (Response Time testing)
- Тестирование на отказоустойчивость (Failover testing)
- Тестирование совместимости (Compatibility testing)
- Тестирование на удобство пользования (Usability testing)
- Тестирование на поддерживаемость/ремонтопригодность (Maintainability testing)
- Тестирование безопасности (Security testing)
- Тестирование аварийного восстановления (Disaster Recovery testing)
- Тестирование на соответствие (Compliance testing)
- Тестирование переносимости (Portability testing)
- Тестирование эффективности (Efficiency testing)
- Базовое тестирование (Baseline testing)
- Тестирование документации (Documentation testing)
- Тестирование восстановления (Recovery testing)
- Интернационализация (Globalization/Internationalization testing)
- Тестирование локализации (Localization testing)
- Время задержки (Latency) - временной интервал между запросом и ответом. Например, у вашего сервиса время задержки составляет 100ms, что означает, что такому сервису потребуется 100 миллисекунд на обработку запроса и генерирование ответа. Как правило, чем ниже время задержки, тем лучше клиентский опыт.
- Время ответа (Response time) - время, необходимое для ответа на запрос
- Пропускная способность (Throughput) - фактическое количество запросов (или пользователей), которое может обработать система за определенное время. В то время как время задержки говорит вам только о времени, метрика пропускной способности информирует об объеме данных, полученных и обработанных в момент времени. Важно не отделять показатели времени задержки от пропускной способности, т.к. высокий показатель времени задержки часто прямо связан с увеличением показателей метрики пропускной способности. Пропускная способность обычно измеряется в rps – (кол-во) запросов в секунду (requests per second).
- Ширина пропускания канала (Bandwidth) - максимальное число запросов (или пользователей), которое может обработать система. В отличие от пропускной способности ширина пропускания канала измеряет максимальный объем, который может обработать приложение.
- Транзакции в секунду. Пользовательские транзакции – это последовательность действий пользователя в интерфейсе. Сравнивая реальное время прохождения транзакции с ожидаемой (или количество транзакций в секунду), вы сможете сделать вывод о том, насколько успешной системой было пройдено нагрузочное тестирование.
- Процент ошибок рассчитывается как отношение невалидных ответов к валидным за промежуток времени.
- Про Average, медианы, перцентили и т.п. углубляться в рамках этой статьи не буду, есть в гугле.
- Измерить время отклика самых важных бизнес-транзакций;
- Определить предельный уровень допустимой нагрузки;
- Выявить «узкие» места в производительности системы;
- Составить рекомендации по улучшению производительности;
- Найти возможные дефекты, проявляющиеся только при одновременной работе большого количества пользователей.
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций
- определение количества пользователей, одновременно работающих с приложением
- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций)
- исследование производительности на высоких, предельных, стрессовых нагрузках
Важно понимать, что все подвиды тестирования производительности это, грубо говоря, одно и то же, просто в зависимости от конкретного подвида выбираются разные параметры (показатели нагрузки/пользователей, длительности и т.п.) и собираются соответствующие метрики. Точкой отсчета принято брать результаты Capacity testing. В реальном мире проводят только часть из перечисленных подвидов в соответствии с бюджетом и приоритетами данного ПО, а параметры тестов и метрики могут корректироваться в разных ситуациях.
Доп. материал:
- Анализ результатов нагрузочного тестирования
- Нагрузочное тестирование выполнять сложно, а инструменты далеки от совершенства. Почему?
- Нагрузочное тестирование: особенности профессии
- Увеличится ли производительность приложения, если добавить дополнительные аппаратные ресурсы?
- Увеличится ли производительность пропорционально количеству добавленных аппаратных средств?
Доп.материал: Chaos Monkey
Время ответа относится ко времени, которое требуется одному системному узлу для ответа на запрос другого. Среднее время ответа - это среднее время, затрачиваемое на каждый запрос в оба конца. Пиковое время отклика помогает нам определить, какие компоненты потенциально проблематичны. Коэффициент ошибок - это математический расчет, который отображает процент проблемных запросов. Три критических значения времени отклика: 0,1 секунды, 1,0 секунды и 10 секунд. Это метод тестирования, который предлагает ступенчато поднимать нагрузку до тех пор, пока система не выйдет из строя. Тестирование хранилища определяется как тип тестирования программного обеспечения, который проверяет, сохраняет ли тестируемое приложение соответствующие данные в соответствующих каталогах и достаточно ли у него места для предотвращения неожиданного завершения из-за недостатка дискового пространства. Это также называется тестированием производительности хранилища (Storage Performance testing). Зачем оно нужно?- Медленное хранилище означает медленное время отклика, длительные запросы и более низкую availability приложений.
- Медленное хранилище - это накладные расходы на обслуживание серверной инфраструктуры.
- Также помогает найти практическое ограничение хранилища перед деплоем.
- Помогает понять, как система будет реагировать при замене или обновлении аппаратного обеспечения.
- Application testing: Тестирование приложений с примерами запросов в production like environment
- Сравните время ответа OLTP
- Сравните время выполнения batch
- Сравните rates непрерывной потоковой передачи
- Application Simulation: Проведите тестирование с использованием стандартного программного обеспечения, аналогичного целевому приложению
- Протестировать на пиковые значения IOPS для баз данных
- Тест пика для data streaming environments
- Проверка задержек хранилища для обмена сообщениями или других однопоточных приложений
- Benchmarking: Провести тестирование с использованием стандартного программного обеспечения.
- Проверка на повреждение данных.
- Отказ электричества на компьютере-сервере
- Отказ электричества на компьютере-клиенте
- Незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации).
- Объявление или внесение в массивы данных невозможных или ошибочных элементов.
- Отказ носителей данных.
- производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т. д. ? (меньше - лучше)
- правильность (accuracy) - сколько ошибок сделал пользователь во время работы с приложением? (меньше - лучше)
- активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя)
- эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше)
Доп. материал: Вкусный и здоровый гайд по юзабилити-тестированиям
Отличия тестирование на удобство пользования и тестирования доступности? (Usability Vs. Accessibility testing)
- Speech Recognition Software - ПО преобразует произнесенное слово в текст, который служит вводом для компьютера.
- Программа для чтения с экрана - используется для озвучивания текста, отображаемого на экране
- Программное обеспечение для увеличения экрана - используется для увеличения масштаба элементов и облегчения чтения для пользователей с нарушениями зрения.
- Специальная клавиатура, облегчающая ввод для пользователей, у которых проблемы с двигательными функциями.
- Предоставляет ли приложение клавиатурные эквиваленты для всех действий мышью и окон?
- Предоставляются ли инструкции как часть пользовательской документации или руководства? Легко ли понять и использовать приложение, используя документацию?
- Упорядочены ли вкладки логически для обеспечения плавной навигации?
- Предусмотрены ли сочетания клавиш для меню?
- Поддерживает ли приложение все операционные системы?
- Четко ли указано время отклика каждого экрана или страницы, чтобы конечные пользователи знали, как долго ждать?
- Все ли надписи правильно написаны?
- Являются ли цвета подходящим для всех пользователей?
- Правильно ли используются изображения или значки, чтобы их было легко понять конечным пользователям?
- Есть ли звуковые оповещения?
- Может ли пользователь настроить аудио или видео элементы управления?
- Может ли пользователь переопределить шрифты по умолчанию для печати и отображения текста?
- Может ли пользователь настроить или отключить мигание, вращение или перемещение элементов?
- Убедитесь, что цветовое кодирование никогда не используется в качестве единственного средства передачи информации или указания на действие
- Видна ли подсветка с инвертированными цветами?
- Тестирование цвета в приложении путем изменения контрастности
- Правильно ли слышат люди с ограниченными возможностями все имеющее отношение к аудио и видео?
- Протестируйте все мультимедийные страницы без мультимедиа-оборудования.
- Предоставляется ли обучение пользователям с ограниченными возможностями, что позволит им ознакомиться с программным обеспечением или приложением?
Доп. материал:
- QA и его роль в создании ресурсов для людей с ограниченными возможностями
- Чеклист по UX из 30 пунктов для мобильных приложений
- Web Content Accessibility Guidelines
- Интерфейс веб-сервера и сервера приложений
- Интерфейс сервера приложений и базы данных
- Начальная фаза (Inception phase): эта фаза включает начальное планирование испытаний и тестирование прототипа
- Фаза разработки (Elaboration phase): Эта фаза включает базовую архитектуру тестирования
- Фаза строительства (Construction phase): эта фаза включает в себя значительные испытания в каждой сборке
- Фаза перехода (Transition phase): Эта фаза включает в себя регрессионные тесты и повторные тесты исправлений
- Test engineer: планирует цели теста и график. Определяет Test case и процедуры. Оценивает результаты теста.
- Component engineer: Разработка тестовых компонентов. Автоматизирует некоторые тестовые процедуры.
- Integration Tester: Выполнение интеграционных тестов и выявление дефектов
- System Testers: Выполнение системных тестов и отчеты о дефектах
- Анализ бизнес-требований
- Создать плана тестирования UAT
- Определить Test Scenario
- Создать Test case UAT
- Подготовить Test Data (Production like Data)
- Запустить Test case
- Записать результаты
- Подтвердить бизнес-цели
- Installation testing
- Load & Performance Test Operation
- Backup and Restore testing
- Security testing
- Code Analysis
- Fail over testing
- Recovery testing
- End-to-End Test Environment Operational testing
- Operational Documentation Review
- Резервные копии, сделанные на одном сайте, могут быть развернуты на тот же сайт
- Резервные копии, сделанные на одном сайте, можно развернуть на другом сайте.
- Внедрение любых новых функций в живую производственную среду не должно отрицательно влиять на целостность текущих производственных услуг.
- Процесс внедрения может быть воспроизведен с использованием действующей документации
- Каждый компонент может быть отключен и успешно запущен в согласованные сроки.
- Для оповещений - все критические оповещения должны идти в TEC и ссылаться на документ правильного разрешения.
- Оповещения созданы и выдаются при превышении согласованных пороговых значений
- Любая документация по восстановлению, созданная или измененная, включая сервисные диаграммы, действительна
- Это должно быть передано в соответствующие области поддержки.
- Любой компонент, на который влияет сбой, должен показывать рекомендуемый порядок перезапуска, время завершения и т. д.
- Установка должна начаться при клике по кнопке, подтверждающей данное действие
- Установки во всех поддерживаемых окружениях и на всех поддерживаемых платформах
- Установки в неподдерживаемых окружениях, а также в нужных окружениях с некорректными настройками
- Права, которые требует инсталляция (чаще всего они должны быть админскими), проверить установить приложение как гость
- Установки в clean state (при отсутствии любых возможных связанных файлов и предыдущих версий)
- Подсчитывается ли при установке количество свободного места на диске и выдается ли предупреждение если места недостаточно
- Установки загруженного ранее приложения, а также прямая установка с использованием сети/беспроводного соединения
- Восстановится ли процесс установки при внезапном его прерывании (отключение устройства, отказ сети, отключение беспроводного соединения)
- Установка приложения, его запуск, удаление приложения должны возвращать систему в исходное состояние
- Распознается ли наличие в системе приложений/программ, необходимых для корректной работы устанавливаемого приложения
- Повторный запуск установки приложения при уже текущем должен выдавать корректное сообщение, двойная установка должна быть исключена
- Процесс установки может быть настраиваемый/дефолтный. Убедиться, что оба корректно работают
- Наличие кнопки, которая предложит сохранить приложение в определенную папку, а также указывает дефолтное местоположение ("C:/programs/.")
- Правильно ли установлены, сохранены ли в корректных папках файлы приложения
- Наличие созданных ярлыков, корректно ли они расположены
- После установки в системной вкладке " Программы и компоненты" должны быть доступны: название приложения, иконка, имя издателя, размер приложения, дата установки и номер версии
- Настройки переменных сред PATH
- Убедиться, что лицензионный ключ сохраняется в Windows Registry library
- Поддерживает ли приложение функции ‘UnInstall’, ‘Modify’, ‘ReInstall’ и корректно ли они работают
- Работа приложения с уже существующими DLL-файлами, с DLL-файлами приложений, которые необходимы для корректной работы устанавливаемого приложения
- Наличие информации/сообщение о том, когда истекает срок действия установленной пробной версии приложения
- Поддерживает ли приложение функцию обновления/автообновления
- При попытке установить ранее установленную версию приложения система должна ее распознать и выдать корректное сообщение
- Сохраняются ли пользовательские настройки при попытке загрузить новую версию/обновить старую версию
- При попытке обновить версию должны быть доступны функции удалить приложение и восстановить приложение
- Стандартные проверки как при первичной установке приложения
- Убедиться, что номер версии приложения сменился новым
- Запустить приложение и убедиться, что оно работает корректно
- Попробовать установить старую версию на более новую
- Наличие корректного сообщения при попытке отката
- Убедиться, что приложение работает корректно
- Не остается ли в системе никаких папок/файлов/ярлыков/ключей реестра после полного удаления приложения
- Корректно ли работает система после установки и последующего удаления приложения
- Конфиденциальность - сокрытие определенных ресурсов или информации
- Целостность – ресурс может быть изменен только в соответствии с полномочиями пользователя
- Доступность - ресурсы должны быть доступны только авторизованному пользователю, внутреннему объекту или устройству
- попытки узнать пароль с помощью внешних средств;
- атака системы с помощью специальных утилит, анализирующих защиты;
- подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);
- целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;
- просмотр несекретных данных в надежде найти ключ для входа в систему.
- Сканирование уязвимостей/оценка защищенности (Vulnerability Scanning) выполняется с помощью автоматизированного ПО для сканирования системы на наличие известных сигнатур уязвимостей.
- Сканирование безопасности (Security Scanning) включает в себя выявление слабых сторон сети и системы, а затем предоставляет решения для снижения этих рисков. Это сканирование может быть выполнено как ручным, так и автоматизированным.
- Тестирование на проникновение (Penetration testing) - этот тип тестирования имитирует атаку злоумышленника. Это тестирование включает анализ конкретной системы для проверки потенциальных уязвимостей при попытке внешнего взлома.
- Оценка рисков (Risk Assessment) тестирование включает анализ рисков безопасности, наблюдаемых в организации. Риски классифицируются как Низкие, Средние и Высокие. Это тестирование рекомендует меры по снижению риска.
- Аудит безопасности (Security Auditing) - внутренняя проверка приложений и операционных систем на наличие уязвимостей. Аудит также может быть выполнен путем построчной проверки кода
- Этический взлом (Ethical hacking) - совершается с целью выявления проблем безопасности в системе. Это делается White Hat хакерами - это специалисты по безопасности, которые использует свои навыки законным способом для помощи в выявлении дефектов системы, в отличии от Black Hat (преступников) или Gray Hat (что-то между).
- Оценка состояния (Posture Assessment) объединяет сканирование безопасности, этический взлом и оценки рисков, чтобы показать общее состояние безопасности организации.
| SDLC фаза | Security Processes |
| Requirements | Анализ безопасности для требований и проверка случаев злоупотребления / неправильного использования |
| Design | Анализ рисков безопасности для проектирования. Разработка плана тестирования с учетом тестирования безопасности |
| Coding and Unit testing | Статическое и динамическое тестирование безопасности и тестирование белого ящика |
| Integration testing | Тестирование черного ящика |
| System testing | Тестирование черного ящика и сканирование уязвимостей |
| Implementation | Тестирование на проникновение, сканирование уязвимостей |
| Support | Анализ воздействия патчей |
Доп. материал:
- Топ-10 уязвимостей мобильных приложений и способы их устранения
- Безопасность веб-приложений: от уязвимостей до мониторинга
- Социотехническое тестирование: какое лучше выбрать в 2021 году?
- Анализ безопасности веб-проектов
- Безопасность интернет-приложений
- Red Teaming — комплексная имитация атак. Методология и инструменты
- cHack
- OWASP Top Ten
- Santoku Linux
- Kali Linux
- https://github.com/FSecureLABS/drozer
- SQL-инъекции' union select null,null,null --
- Что такое XSS-уязвимость и как тестировщику не пропустить ее
- Активное тестирование
- Inactive testing, тестировщик вводит новые test data и анализирует результаты.
- В процессе тестирования тестировщики создают интеллектуальную модель процесса, и она будет расти и дальше во время взаимодействия с тестируемым программным обеспечением.
- Выполняя тест, тестировщик будет активно вовлекаться в процесс обнаружения новых Test case и новых идей. Вот почему это называется Active testing.
- Пассивное тестирование
- Пассивное тестирование - отслеживание результатов запуска тестируемого программного обеспечения без введения новых Test case или data.
- Тестирование сети
- Тестирование сети - это процесс измерения и записи текущего состояния работы сети за определенный период времени.
- Тестирование в основном проводится для прогнозирования работы сети под нагрузкой или для выявления проблем, создаваемых новыми сервисами.
- Нам нужно проверить следующие характеристики сети:
- Уровни утилизации
- Количество пользователей
- Использование приложения
- Распределенное Тестирование
- Распределенные тесты применяются для тестирования распределенных приложений, то есть приложений, работающих с несколькими клиентами одновременно. По сути, тестирование распределенного приложения означает тестирование его клиентской и серверной частей по отдельности, но с помощью метода распределенного тестирования мы можем протестировать их все вместе.
- Части теста будут взаимодействовать друг с другом во время теста. Это делает их синхронизированными соответствующим образом. Синхронизация является одним из наиболее важных моментов в распределенном тестировании.
- Тест на проникновение в сеть:
- выявлении уязвимостей сетевого и системного уровня;
- определение неправильных конфигураций и настроек;
- выявление уязвимости беспроводной сети;
- мошеннические услуги;
- отсутствие надежных паролей и наличие слабых протоколов.
- Тест на проникновение приложений:
- выявление недостатков прикладного уровня;
- подделка запросов;
- применение злонамеренных скриптов;
- нарушение работы управления сеансами;
- и т.п.
- Тест на физическое проникновение:
- взлом физических барьеров;
- проверка и взлом замков;
- нарушения работы и обход датчиков;
- вывод из строя камер видеонаблюдения;
- и т. д.
| Vulnerability Assessment | Penetration testing | |
| Working | Нахождений уязвимостей | Выявление и использование уязвимостей |
| Mechanism | Обнаружение и сканирование | Симуляция |
| Focus | Ширина | Глубина |
| Coverage of Completeness | Высокое покрытие | Низкое |
| Cost | Низкая стоимость | Высокая |
| Performed By | Внутренний персонал | Атакующий или пентестер |
| How often to Run | После каждой сборки | Реже, зависит от политики безопасности компании и продукта |
| Result | Предоставит частичную информацию об уязвимостях | Предоставит полную информацию об уязвимостях |
- Mutation-Based Fuzzers: изменяет существующие образцы данных для создания новых test data. Это очень простой и понятный подход, он начинается с действительных образцов и постоянно корректирует каждый байт или файл.
- Generation-Based Fuzzers: определяет новые данные на основе ввода модели. Он начинает генерировать ввод с нуля на основе спецификации.
- PROTOCOL-BASED-fuzzer: самый успешный фаззер - это детальное знание тестируемого формата протокола. Понимание зависит от спецификации. Это включает в себя запись массива спецификации в инструмент, а затем с помощью метода генерации тестов на основе модели проходится спецификация и добавляется неравномерность в содержимое данных, последовательность и т. д. Это также известно как синтаксическое тестирование, грамматическое тестирование, тестирование надежности, и т. д. Fuzzer может генерировать Test case из существующего или использовать допустимые или недействительные входные данные.
Типы ошибок, обнаруживаемых Fuzz testing:
- Сбои ассертов и утечки памяти (Assertion failures and memory leaks). Эта методология широко используется для больших приложений, где ошибки влияют на безопасность памяти, что является серьезной уязвимостью.
- Некорректный ввод (Invalid input). Фаззеры используются для генерирования неверного ввода, который используется для тестирования процедур обработки ошибок, и это важно для программного обеспечения, которое не контролирует его ввод. Простой фаззинг может быть способом автоматизации отрицательного тестирования.
- Исправление ошибок (Correctness bugs). Fuzzing также может использоваться для обнаружения некоторых типов ошибок «правильности». Например, поврежденная база данных, плохие результаты поиска и т. д.
Доп. материал: Фаззинг тестирование веб-интерфейса. Расшифровка доклада
Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тестирования?
Мнение: "<..> Есть функциональное требование: "Пользователь должен иметь возможность перевести деньги со своей карты на другую карту по номеру". Это функциональное требование (ну, на самом деле это целая тонна требований, но обобщим их до одной user story). Оно отвечает на вопрос "какие операции должен уметь выполнять сервис". К этой функциональности может предъявляться еще куча требований - по безопасности, по скорости, по отказоустойчивости, и т.д. Они описывают то, как система должна работать, а не что она должна уметь. Нефункциональные требования могут быть критичными, могут блокировать выпуск той или иной функциональности. Но это все еще свойство фичи, а не какая-то самостоятельная ее функция. В то же время, есть, например, функциональные требования безопасности, типа "автоматически блокировать транзакции обладающие характеристиками А, Б, В". © @azshoo Это снова нас возвращает к тому, что система должна обладать какими-то функциями."
Конфигурационное тестирование (Configuration testing) — специальный вид тестирования, направленный на проверку работы ПО при различных аппаратных и программных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д. ) В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:- Проект по профилированию работы системы Цель Тестирования: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы.
- Проект по миграции системы с одной платформы на другую Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.
- Серверный
- Клиентский
- Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т. д.)
- Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т. д.)
- Тип, версия и битность операционной системы (подобный вид тестирования называется кроссплатформенное тестирование)
- Тип и версия Web браузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование)
- Тип и модель видеоадаптера (при тестировании игр это очень важно)
- Работа приложения при различных разрешениях экрана
- Версии драйверов, библиотек и т. д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки)
- создавать матрицу покрытия (матрица покрытия - это таблица, в которую заносят все возможные конфигурации),
- проводить приоритезацию конфигураций (на практике, скорее всего, все желаемые конфигурации проверить не получится),
- шаг за шагом, в соответствии с расставленными приоритетами, проверять каждую конфигурацию.
- Сайт открывается
- Можно выбрать случайный товар и добавить его в корзину
- Можно оформить и оплатить заказ
- Приложение устанавливается и запускается
- Можно авторизоваться
- Можно написать сообщение случайном контакту
Синонимом в некоторых источниках указан breath testing. Небольшая шпаргалка по степени важности:
- smoke - самое важное
- critical path - повседневное
- extended - все
В русском языке термин ошибочно переводят как проверка дыма, корректнее уж говорить "на дым". История термина: Первое свое применение этот термин получил у печников, которые, собрав печь, закрывали все заглушки, затапливали ее и смотрели, чтобы дым шел только из положенных мест. Повторное «рождение» термина произошло в радиоэлектронике. Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме. Если первое включение не выявило перегрева, то прибор включается снова на большее время. Проверка повторяется. И так далее несколько раз. Выражение «smoke-test» используется инженерами в шуточном смысле, так как появления дыма, а значит и порчи частей устройства, стараются избежать.
Доп. материал: QA Outsourcing: Smoke Testing, Critical Path Testing, Extended Testing
Стандартного определения ISO для теста на встряхивание для ПО не существует. Говорят, что это синоним к Smoke тестированию. Для начала стоит сказать, что санитарным оно в русскоязычной среде назвалось по совершенно непонятным причинам, но гуглится только так. На самом же деле корректно говорить тестирование на вменяемость или разумность. Санитарное тестирование - это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений, произведенных в ней или окружающей среде. Обычно выполняется вручную.Доп. материалы: Definition of sanity What is Sanity testing? Advantages, disadvantages & differences
Эти виды тестирования имеют "вектора движения", направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.Доп. материал: В чем разница Smoke, Sanity, Regression, Re-test и как их различать?
При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках этапа сопровождения, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям. Главной задачей этапа сопровождения является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям. Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться. Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов. Можно заключить, что регрессионное тестирование выполняется чтобы минимизировать регрессионные риски. То есть, риски того, что при очередном изменении продукт перестанет выполнять свои функции. С регрессионным тестированием плотно связана другая активность - импакт анализ (или иначе, анализ влияния изменений). Обычно под импакт анализом имеют в виду одно из следующих:- Попытку оценить регрессионные риски еще на этапе планирования изменений (этим определением, по моему опыту, чаще пользуются менеджеры и разработчики);
- Попытку определить объем регрессионного тестирования с учетом изменений, которые уже произошли (это определение чаще используют сами тестировщики). У Пола Джеррарда есть серия статей, где более детально раскрывается понятие импакт анализа, причем не только с позиции тестировщика. Очевидно, что от эффективности импакт анализа зависит эффективность регрессионного тестирования. Но не всегда тщательно проведенный импакт анализ позволяет сократить затраты на последующее тестирование.
- Некоторые участки кода программы не получают управление при выполнении некоторых тестов.
- Если участок кода реализует требование, но измененный фрагмент кода не получает управления при выполнении теста, то он и не может воздействовать на значения выходных данных программы при выполнении данного теста.
- Даже если участок кода, реализующий требование, получает управление при выполнении теста, это далеко не всегда отражается на выходных данных программы при выполнении данного теста. Действительно, если изменяется первый блок программы, например, путем добавления инициализации переменной, все пути в программе также изменяются, и, как следствие, требуют повторного тестирования. Однако может так случиться, что только на небольшом подмножестве путей действительно используется эта инициализированная переменная.
- Не каждый тест, проверяющий код, находящийся на одном пути с измененным кодом, обязательно покрывает этот измененный код.
- Код, находящийся на одном пути с измененным кодом, может не воздействовать на значения выходных данных измененных модулей программы.
- Не всегда каждый оператор программы воздействует на каждый элемент ее выходных данных.
- Множество тестов, пригодных для повторного использования. Это тесты, которые уже запускались и пригодны к использованию, но затрагивают только покрываемые элементы программы, не претерпевшие изменений. При повторном выполнении выходные данные таких тестов совпадут с выходными данными, полученными на исходной программе. Следовательно, такие тесты не требуют перезапуска.
- Множество тестов, требующих повторного запуска. К ним относятся тесты, которые уже запускались, но требуют перезапуска, поскольку затрагивают, по крайней мере, один измененный покрываемый элемент, подлежащий повторному тестированию. При повторном выполнении такие тесты могут давать результат, отличный от результата, показанного на исходной программе. Множество тестов, требующих повторного запуска, обеспечивает хорошее покрытие структурных элементов даже при наличии новых функциональных возможностей.
- Множество устаревших тестов. Это тесты, более не применимые к измененной программе и непригодные для дальнейшего тестирования, поскольку они затрагивают только покрываемые элементы, которые были удалены при изменении программы. Их можно удалить из набора регрессионных тестов.
- Новые тесты, которые еще не запускались и могут быть использованы для тестирования.
Дополнительный материал.
- Регрессионное тестирование: разновидности метода отбора тестов
- Регрессионное тестирование: методики, не связанные с отбором тестов и методики порождения тестов
- Регрессионное тестирование: алгоритм и программная система поддержки
- Регрессия багов (Bug regression) — попытка доказать, что исправленная ошибка на самом деле не исправлена
- Регрессия старых багов (Old bugs regression) — попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.
- Регрессия побочного эффекта (Side effect regression) — попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения
- Регрессионное тестирование проводится для подтверждения того, что недавнее изменение программы или кода не оказало неблагоприятного воздействия на существующие функции. Повторное тестирование проводится для подтверждения того, что тест-кейсы, которые не прошли, проходят после устранения дефектов.
- Цель регрессионного тестирования подтвердить, что новые изменения кода не должны иметь побочных эффектов для существующих функций. Повторное тестирование проводится на основе исправлений дефектов.
- Проверка дефектов не является частью регрессионного тестирования. Проверка дефекта является частью повторного тестирования
- В зависимости от проекта и наличия ресурсов, регрессионное тестирование может проводиться параллельно с повторным тестированием. Приоритет повторного тестирования выше, чем регрессионное тестирование, поэтому оно проводится перед регрессионным тестированием.
- Вы можете сделать автоматизацию для регрессионного тестирования, ручное тестирование может быть дорогим и трудоемким.
- Регрессионное тестирование называется общим (generic) тестированием. Повторное тестирование - это плановое (planned) тестирование.
- Регрессионное тестирование проводится для пройденных Test case. Повторное тестирование проводится только для неудачных тестов.
- Регрессионное тестирование проверяет наличие неожиданных побочных эффектов. Повторное тестирование гарантирует, что первоначальная ошибка была исправлена.
- Регрессионное тестирование проводится только тогда, когда есть какие-либо изменения или изменения становятся обязательными в существующем проекте. Повторное тестирование выполняет дефект с теми же данными и той же средой с разными входными данными с новой сборкой (build).
- Test case для регрессионного тестирования могут быть получены из функциональной спецификации, user tutorials and manuals, а также defect reports в отношении исправленных проблем. Test case для повторного тестирования не могут быть получены до начала тестирования.
- Однопоточное тестирование включает одну транзакцию приложения за раз
- Многопоточное тестирование включает одновременно несколько активных транзакций
- Тестирование на основе потоков является обобщенной формой тестирования на основе сеансов (session-based testing), в котором сеансы являются формой потока, но поток не обязательно является сеансом.
- Для тестирования потока, поток или программа (небольшая функциональность) интегрируются и тестируются постепенно как подсистема, а затем выполняются для всей системы.
- На самом низком уровне оно предоставляет интеграторам лучшее представление о том, что тестировать.
- Вместо непосредственного тестирования программных компонентов требуется, чтобы интеграторы сосредоточились на тестировании логических путей выполнения в контексте всей системы.
- Requirement documents
- Test Plan
- Test case
- Traceability Matrix (RTM)
- Unit-слой — это когда тестируется один модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего. Unit-тест для данных — это когда мы определяем требования для каждой ячейки. Нет смысла тестировать дальше, если у нас есть ошибки на уровне ячеек. Если, например, в фамилии содержатся цифры, то какой смысл проверять что-то дальше? Возможно, там должны быть буквы, похожие на эти цифры. И тогда нам нужно все исправлять и проверять следующий уровень, чтобы у нас все было в единственном числе и не было дубликатов, если так сказано в требованиях.
- Integration-слой — это когда несколько кусков программы тестируются вместе. Слой API для данных — это когда мы говорим о всей таблице. Допустим, у нас могут быть дубликаты, но не больше ста штук. Если у нас город-миллионник, то на одной улице не может жить миллион человек. Поэтому если мы сделаем выборку по улице, то количество адресов должно быть десять тысяч или тысяча — это надо определить. А если у нас миллион, то с данными что-то не так.
- System-слой — это когда вся программа тестируется полностью. В случае с данными этот слой означает, что тестируется вся система. Здесь включается статистика. Например, мы говорим, что у нас не может быть больше 30% мужчин, рожденных после 1985 года. Или мы говорим, что 80% данных должны быть одного типа.
- Приемочное тестирование - это тест, проводимый для определения того, удовлетворяются ли требования спецификации или контракта в соответствии с его поставкой. Приемочное тестирование в основном выполняется пользователем или заказчиком. Тем не менее, другие акционеры могут быть вовлечены в этот процесс.
Доп. материал: Subcutaneous Test
Расскажите о локализации, глобализации и интернационализации? (Localization/ globalization/internationalization testing)
Тестирование глобализации, в свою очередь, можно разделить на два подвида:
- Тестирование интернационализации (118N);
- Тестирование локализации (L10N);
(Цифра означает количество пропущенных букв, типа как k8s - kubernetes)
Интернализация ПО – это особый процесс, при котором веб-софт создается таким образом, чтобы оно было равноудаленным от какой-либо культуры и (или) специфики определенного географического региона. Например, одна из задач по интернационализации ПО– корректное редактирование логики всех подключенных параметров форматирования (формат даты, времени, цифровое и валютное форматирование). Также, тестировщики во время проверки на соответствие ПО требованиям 118N тестируют работу продукта на равномерность работы в разных регионах и культурах мира. Основной задачей тестирования интернациональности является проверка того, может ли программный код работать со всей международной поддержкой без нарушения функциональности, что может привести к потере данных или проблемам целостности информации. В основном, фокус тестирования интернациональности направлен на:
- Тестирование языковой совместимости. Проводятся проверки того, может ли веб-продукт корректно работать в определенной языковой среде;
- Проверка функциональности: полное выполнение регрессионных тестов в разнообразных языковых средах (корректное отображение специфической информации – даты, времени и валюты);
- Тестирование на корректность отображения графического интерфейса;
- Проверка удобства пользования: тестирование простоты использования ПО на различных операционных системах, разнообразных устройствах и прочее.
Локализация ПО – деятельность по модификации ПО в соответствии с определенными региональными настройками (языком, географической территорией, кодировкой и прочим), которая должна бесперебойно работать. В данный вид проверки входит необходимость выполнения работ по переводу всего контента программного обеспечения для конечного пользователя. Во время перевода должны учитываться иконки, информационная графика, справочные материалы, техническая документация и иные культурные особенности регионов, где в будущем будет доступно это программное обеспечение.
На что обратить внимание:
- Длина переведенных слов
- Параметры шрифта пользовательского интерфейса
- Ввод текста в разных локализациях
- RTL-языки (справа-налево) или вертикальных
- Перевод сокращений или аббревиатур
- Мета-теги (проблемы с SEO или отображением имени вкладки (title, description, keywords))
- Соответствие мер исчисления, валюты, postal code и т.п.
Доп. материал:
- Локализационное тестирование: зачем оно нужно приложению или сайту?
- Почему интернационализация и локализация имеют значение
- Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist
- Accelerate localization from code to delivery
- Исследовательское тестирование: пустая трата времени или мощный инструмент?
- Rapid Software Testing Methodology
- Exploratory Testing
- Exploratory Testing
- Exploratory Testing
- Exploratory Testing Dynamics
- A Tutorial in Exploratory Testing
- Plan your next exploratory testing session
Доп. материал:
- Туры в исследовательском тестировании. Личный перевод из книги Д. Виттакера «Исследовательское тестирование ПО»
- Переводы туров для исследовательского тестирования
- Исследовательское тестирование и исследовательские туры Виттакера
- Buddy testing – процесс, когда 2 человека, как правило разработчик и тестировщик, работают параллельно и находят дефекты в одном и том же модуле тестируемого продукта. Такой вид тестирования помогает тестировщику выполнять необходимые проверки, а разработчику исправлять множество дефектов на ранних этапах.
- Pair testing – процесс, когда 2 тестировщика проверяют один модуль и помогают друг другу. К примеру, один может искать дефекты, а второй их документировать. Таким образом, у одного тестировщика будет функция, скажем так, обнаружителя, у другого – описателя.
- Monkey testing – произвольное тестирование продукта с целью как можно быстрее, используя различные вариации входных данных, нарушить работу программы или вызвать ее остановку (простыми словами – сломать).
Различия между Buddy testing и Pair testing:
- Buddy testing (Совместное тестирование) – это сочетание модульного тестирования и системного тестирования между разработчиком и тестировщиком.
- Pair testing (Парное тестирование) – выполняется только тестировщиками с разным уровнем знаний и опыта (такое сочетание поможет поделиться взглядами и идеями).
Основные преимущества ad-hoc testing:
- нет необходимости тратить время на подготовку документации;
- самые важные дефекты зачастую обнаруживаются на ранних этапах;
- часто применяется, когда берут нового сотрудника. С помощью этого метода, человек усваивает за 3 дня то, что, разбираясь тестовыми случаями, разбирал бы неделю – это называется форсированное обучение новых сотрудников;
- возможность найти трудновоспроизводимые и трудноуловимые дефекты, которые невозможно было бы найти, используя стандартные сценарии проверок.
Если нам нужно провести ad-hoc тестирование интернет-магазина, то этот краткий список может помочь с тем, что нужно проверить:
- все возможности сайта доступны без регистрации;
- корректность отображения анимаций и картинок;
- все возможности сайта доступны после регистрации;
- процесс регистрации;
- процесс добавления/удаления из корзины;
- процесс оплаты покупок;
- удобство в пользовании для новичков, простота, подсказки, помощь.
- Шаг 1: Ошибки вводятся в исходный код программы путем создания множества версий, называемых мутантами. Каждый мутант должен содержать одну ошибку, и цель состоит в том, чтобы заставить версию мутанта потерпеть неудачу, что демонстрирует эффективность Test case.
- Шаг 2: Test case применяются к исходной программе, а также к программе мутанта.
- Шаг 3: Сравните результаты оригинальной и мутантной программы.
- Шаг 4: Если исходная программа и программы-мутанты генерируют разные выходные данные, то этот мутант уничтожается by the Test case. Следовательно, Test case достаточно хорош, чтобы обнаружить изменение между оригинальной и мутантной программой.
- Шаг 5: Если исходная программа и программа-мутант генерируют одинаковые выходные данные, мутант остается в живых. В таких случаях необходимо создать более эффективные Test case, которые убивают всех мутантов.
- Операторы замены операндов (Operand replacement operators) – например, в условии if (x> y) поменять местами значения x и y
- Операторы модификации выражений (Expression Modification Operators) – например, в условии if (х == у) Мы можем заменить == на >=
- Операторы модификации операторов (Statement modification Operators) – например, удалить часть else в конструкции if-else или удалить целиком конструкцию if-else, чтобы проверить, как ведет себя программа
Автоматизированные инструменты для разных ЯП: mutmut, Humbug и Infection и т.п.
Доп. материал: Мутационное тестирование
Это скриптовая техника, которая использует файлы данных, которые содержат ключевые слова, связанные с тестируемым ПО. Эти ключевые слова описывают набор действий, необходимых для выполнения определенного шага. Тест на основе ключевых слов состоит из ключевых слов высокого и низкого уровня, включая аргументы ключевых слов, которые составлены для описания действия Test case. Это также называется тестированием на основе таблиц (table-driven testing) или тестированием на основе action word (action word based testing). В тестировании по ключевым словам вы сначала идентифицируете набор ключевых слов, а затем связываете действие (или функцию), связанную с этими ключевыми словами. Здесь каждое действие тестирования, такое как открытие или закрытие браузера, щелчок мыши, нажатия клавиш и т. д., описывается ключевым словом, таким как openbrowser, click, Typtext и т. д. Тестирование на основе ключевых слов обычно выполняется с помощью автоматического тестирования.Что вы знаете о тестировании интерфейса прикладного программирования (API - Application Programming Interface)?
С чего начать.
- Почитать про инструменты, что это такое и как оно работает.
- Потренироваться на любом открытом API посылать/получать/обрабатывать запросы любым удобным вам способом - хоть с помощью python (разобраться можно за 2-3 вечера неспешного изучения с нуля), хоть с помощью GUI инструментов, хоть с помощью CURL.
- Получить список функциональности API:
- - Кто является "клиентом" для этого АПИ (использует его ваше приложение/фронтенд или вы его отдаете во вне).
- - Какие функции доступны через API.
- Для списка функциональности выше составить список функциональных тест-кейсов, начиная с того, что представляет большую бизнес значимость.
- Для того же списка функциональности получить все нужные данные:
- - Эндпоинты (если они есть в вашем случае).
- - Схему авторизации.
- - Документацию (если есть) или описание работы.
- Дополнить список функциональных проверок из п.3 более подробными тестами про схему взаимодействия, авторизацию, тестирование контракта, валидацию значений и пр.
- Начать писать запросы следуя списку тест-кейсов из п.3 и 4 с помощью инструмента, который выбрали в п.1"
Типы тестирования API:
- Unit testing: Для проверки функциональности отдельной операции
- Functional testing: Чтобы проверить функциональность более широких сценариев с помощью блока результатов unit-тестирования, протестированных вместе
- Load testing: Чтобы проверить функциональность и производительность под нагрузкой
- Runtime/Error Detection: Мониторинг приложения для выявления проблем, таких как исключения и утечки ресурсов
- Security testing: Чтобы гарантировать, что реализация API защищена от внешних угроз
- UI testing: Это выполняется как часть end-to-end integration тестов, чтобы убедиться, что каждый аспект пользовательского интерфейса функционирует должным образом.
- Interoperability and WS Compliance testing: Совместимость и WS Compliance testing - это тип тестирования, который применяется к SOAP API. Функциональная совместимость между API-интерфейсами SOAP проверяется путем обеспечения соответствия профилям функциональной совместимости веб-служб. Соответствие WS- * проверено, чтобы гарантировать, что стандарты, такие как WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security и WS-Trust, должным образом реализованы и используются
- Penetration testing: Чтобы найти уязвимости при атаках злоумышленников
- Fuzz testing: Для проверки API путем принудительного ввода в систему некорректных данных для попытки принудительного сбоя
- Возвращаемое значение на основе входных условий: его относительно легко проверить, поскольку входные данные могут быть определены и результаты могут быть проверены.
- Ничего не возвращает: при отсутствии возвращаемого значения проверяется поведение API в системе.
- Вызов другого API / события / прерывания: если выход API инициирует какое-либо событие или прерывание, то эти события и прерывания listeners следует отслеживать
- Обновление структуры данных: Обновление структуры данных будет иметь определенный эффект или влияние на систему, и это должно быть проверено
- Изменение определенных ресурсов: если вызов API изменяет некоторые ресурсы, его следует проверить путем доступа к соответствующим ресурсам.
- Курс Тестирование ПО. Занятие 29. Тестирование API | QA START UP
- От шока до принятия: пять стадий тестирования API
- Тестирование API
- Swagger/OpenAPI Specification как основа для ваших приемочных тестов
- История одного сервера и тестировщика Васи
- What Is an API?
- Тестирование API простыми словами за 8 минут / Тестировщик API
Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints? Если дело совсем плохо - просканируйте порты, например, с помощью netcat. Открытые порты сохраните в файл. Эта операция займет довольно много времени. Можете почитать советы по работе с Nmap и Netcat. Если Вам известен нужный порт и соответствующий endopoint - переберите все возможные HTTP методы. Начните с наиболее очевидных POST, PUT, GET. Для ускорения процесса напишите скрипт, например, на Python.
В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придется перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.
Разработчики обычно не особо заморачиваются и закладывают минимально-необходимую информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты.
Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
- Как найти границы на клиенте и сервере
- Как Иван ошибку в бэкенде локализовывал
- Круглый стол "Почему не стоит тестировать бэкенд руками"
- Baseline предназначено для оценки производительности приложения. Benchmark сравнивает производительность приложения с отраслевым стандартом.
- Baseline тестирование использует данные, собранные для повышения производительности. Benchmark возвращает информацию о целевом приложении по сравнению с другими приложениями.
- Baseline тестирование сравнивает текущую производительность с предыдущей производительностью приложения, тогда как Benchmark сравнивает производительность нашего приложения с производительностью конкурентов.
- Определяет влияние одновременного доступа к одним и тем же записям базы данных, модулям или коду приложения.
- Определяет и измеряет уровень взаимоблокировки, блокировки и использования однопоточного кода и ограничения доступа к общим ресурсам
- Адаптивность: Адаптируемость определяется как способность программного приложения адаптироваться к конкретной среде без каких-либо усилий. Общие стандарты связи между несколькими системами помогают повысить адаптивность системы в целом.
- Installability: Устанавливаемость определяется как способность программного приложения быть установленным в желаемой среде без использования дополнительных ресурсов. Устанавливаемость выполняется на программном обеспечении, которое должно быть установлено в целевой среде.
- Заменяемость: Возможность замены определяется как способность программного приложения заменять другое программное обеспечение в конкретной среде. Приложение, которое заменяет предыдущее приложение, должно давать одинаковые результаты во всех целевых средах.
- Сосуществование: Сосуществование определяется как способность программного приложения работать с другим программным приложением в системе, не мешая друг другу и совместно используя один и тот же ресурс. Специально это тестирование используется в больших системах, которые включают в себя несколько подсистем.
Что такое тестирование графического интерфейса/визуальное тестирование? (GUI - Graphical User Interface testing)
- Тестирование размера, положения, ширины, высоты элементов.
- Тестирование сообщений об ошибках, которые отображаются.
- Тестирование разных разделов экрана.
- Проверка шрифта, читаемый ли он или нет.
- Тестирование экрана в разных разрешениях с помощью увеличения и уменьшения масштаба, например, 640 x 480, 600x800 и т. д.
- Проверка выравнивания текстов и других элементов, таких как значки, кнопки и т. д. , находятся на своем месте или нет.
- Тестирование цветов шрифтов.
- Проверка цветов сообщений об ошибках, предупреждающих сообщений.
- Проверка, имеет ли изображение хорошую четкость или нет.
- Тестирование выравнивания изображений.
- Проверка орфографии.
- Пользователь не должен разочаровываться при использовании системного интерфейса.
- Тестирование, является ли интерфейс привлекательным или нет.
- Тестирование полос прокрутки в соответствии с размером страницы, если таковые имеются.
- Тестирование отключенных полей, если таковые имеются.
- Тестирование размера изображений.
- Проверка заголовков, правильно ли они выровнены или нет.
- Тестирование цвета гиперссылки.
Визуальное тестирование проверяет корректность отображения пользователю web-сайта, мобильного или десктопного приложения, дизайн-системы, PDF-файла или отдельного изображения на наличие расхождений с спецификацией дизайна (рендеринг страниц, шрифтов, изображений и т. д.). Раньше выполнялось вручную, т.к., например, в случае веб-сайта классическое автоматизированное тестирование было бесполезно – большинство инструментов сверялись с DOM и не видели те ошибки, что человек мог увидеть вживую. Сейчас визуальное тестирование выполняется автоматизированными инструментами создания скриншотов и сверки их с эталоном. Там все еще очень много нюансов, но это уже не относится к статье о ручном тестировании.
Доп. материал: Эффективное тестирование верстки
A / B-тестирование также называется сплит-тестированием (split). При тестировании AB мы создаем и анализируем два варианта приложения, чтобы найти, какой вариант работает лучше с точки зрения пользовательского опыта, потенциальных клиентов, конверсий или любой другой цели, а затем в конечном итоге сохранить наиболее эффективный вариант. Давайте попробуем понять это на примере. Предположим, у нас есть интернет магазин и каталог отображается определенным образом. В какой-то момент (новые маркетинговые исследования/пожелания клиента и т. д.) решено изменить дизайн выдачи товаров в каталоге. Независимо от того, сколько проведено анализа, выпуск нового пользовательского интерфейса будет большим изменением и может иметь неприятные последствия. В этом случае мы можем использовать A / B-тестирование. Мы создадим интерфейс нового варианта и выпустим его для некоторого процента пользователей. Например - мы можем распределить пользователей в соотношении 50:50 или 80:20 между двумя вариантами - A и B. После этого в течение определенного периода времени мы будем наблюдать эффективность обоих вариантов. Таким образом, тестирование A/B помогает принять решение о выборе лучшего варианта.Доп. материал: Ошибки в дизайне A/B тестов, которые я думала, что никогда не совершу
Сквозное тестирование - это стратегия тестирования для выполнения тестов, которые охватывают все возможные потоки приложения от его начала до конца; проверяет программную систему вместе с ее интеграцией с внешними интерфейсами. Целью сквозного тестирования является создание полного производственного сценария, выявление программных зависимостей и утверждение, что между различными программными модулями и подсистемами передается правильный ввод. Сквозное тестирование обычно выполняется после функционального и системного тестирования. Оно использует реальные данные, такие как данные и тестовая среда, для имитации настроек в реальном времени. Сквозное тестирование также называется цепным тестированием (Chain testing). Для чего оно нужно? Современные программные системы являются сложными и взаимосвязаны с несколькими подсистемами. Подсистема может отличаться от текущей системы или может принадлежать другой организации. Если какая-либо из подсистем выйдет из строя, вся система программного обеспечения может рухнуть. Это серьезный риск, и его можно избежать путем сквозного тестирования.| End to End testing | System testing |
| Проверяет программную систему, а также взаимосвязанные подсистемы | Проверяет только программную систему в соответствии со спецификациями требований. |
| Проверяет весь E2E flow | Проверяет функциональные возможности и функции системы. |
| Все интерфейсы, бэкэнд-системы | Функциональное и нефункциональное тестирование |
| Выполняется после завершения System testing | Выполняется после завершения Integration testing |
| Сквозное тестирование включает проверку внешних интерфейсов, которые могут быть сложными для автоматизации. Следовательно, ручное тестирование является предпочтительным. | Как ручное, так и автоматическое могут быть выполнены для тестирования системы |
| Это Parallel testing | Это НЕ Parallel testing |
|
|
- анализ имеющихся проектных артефактов: документация (спецификации, требования, планы), модели, исполняемый код и т. д.
- написание спецификации по тест дизайну (Test Design Specification)
- проектирование и создание Test case
- Тест аналитик - определяет "ЧТО тестировать?"
- Тест дизайнер - определяет "КАК тестировать?"
- Cтатические (Static):
- Review:
- Неформальное ревью (Informal review)
- Прохождение (Walkthrough)
- Техническое ревью (Technical Review)
- Инспекция (Inspection)
- Статический анализ (Static Analysis):
- Поток данных (Data Flow)
- Поток управления (Control Flow)
- Путь (Path)
- Стандарты (Standards)
- Динамические (Dynamic):
- Белый ящик (White-box)
- Выражение (Statement)
- Решение (Decision)
- Ветвь (Branch)
- Условие (Condition)
- Конечный автомат (FSM)
- Основанные на опыте (Experience-based):
- Предугадывание ошибки (Error Guessing - EG)
- Исследовательское тестирование (Exploratory testing)
- Ad-hoc testing
- Черный ящик (Black-box):
- Эквивалентное Разделение (Equivalence Partitioning - EP)
- Анализ Граничных Значений (Boundary Value Analysis - BVA)
- Комбинаторные техники (Combinatorial Test Techniques)
- Переходы между состояниями (State transition)
- Случаи использования (Use case testing)
Альтернативный источник:
- Specification-Based Testing Techniques (or Black Box techniques):
- Equivalence Partitioning
- Boundary Value Analysis
- Combinatorial Test Techniques:
- Decision Table Testing
- Classification Tree Method
- State Transition Testing
- Cause-Effect Graphing
- Scenario Testing
- Random Testing
- Syntax Testing
- Structure-Based Testing Techniques (or White Box techniques):
- Statement Testing
- Decision Testing
- Condition Testing:
- Branch Condition Testing
- Branch Condition Combination Testing
- Modified Condition Decision Coverage (MCDC) Testing
- Data Flow Testing
- Experience-Based Testing Techniques:
Все методы тестирования на основе спецификаций (черного ящика) могут быть удобно описаны и систематизированы с помощью следующей таблицы:
| Группа | Техника | Когда используется |
| Элементарные методы: - сфокусированы на анализе входных / выходных параметров - могут быть объединены для обеспечения лучшего покрытия - обычно не используют и не зависят от других приемов | Equivalence Partitioning | Входные и выходные параметры имеют большое количество возможных значений |
| Boundary Value Analysis | Значения параметров имеют явные (например, четко определенные в документации) границы и диапазоны или неявные (например, известные технические ограничения) границы | |
| Комбинаторные стратегии: - объединить возможные значения нескольких входных / выходных параметров - можно использовать элементарные приемы, чтобы уменьшить количество возможных значений | All Combinations | Количество возможных комбинаций входов достаточно мало, или каждая отдельная комбинация входов приводит к определенному выходу |
| Pairwise Testing | Количество входных комбинаций чрезвычайно велико и должно быть сведено к приемлемому набору cases | |
| Each Choice Testing | У вас есть функциональность, при которой конкретное значение параметра чаще вызывает ошибку чем комбинация значений | |
| Base Choice Testing | Вы можете выделить набор значений параметров, которые имеют наибольшую вероятность использования | |
| Продвинутые техники: - помочь проанализировать Систему с точки зрения бизнес-логики, иерархических отношений, сценариев и т. д. - анализ основан на данных, организованных в виде таблиц, диаграмм и шаблонов - может полагаться на элементарные и комбинаторные методы для разработки Test case | Decision Table Testing | Существует набор комбинаций параметров и их выводов, описываемых бизнес-правилами или другими правилами. |
| Classification Tree Method | У вас есть иерархически структурированные данные, или данные могут быть представлены в виде иерархического дерева | |
| State Transition Testing | В функциональности есть очевидные состояния, у которых переходы регулируются правилами (например, потоками) | |
| Cause-Effect Graphing | Причины (входы) и следствия (выходы) связаны большим количеством сложных логических зависимостей | |
| Scenario Testing | Есть четкие сценарии в функционале | |
| Другие | Random Testing | Вы должны подражать непредсказуемости реальных входных данных, или функциональность имеет несистематические дефекты |
| Syntax Testing | Функциональность имеет сложный синтаксический формат для ввода (например, коды, сложные имена электронной почты и т. д.) |
Методы тестирования на основе структуры (Structure-Based Testing Techniques): также известны как методика тестирования White Box, это означает, что мы знакомы с кодом, который собираемся тестировать. Чтобы понять эти методы, мы должны определить, что такое покрытие в контексте разработки теста. Вот хорошее определение из Книги ISTQB: Тестирование покрытия определенным образом измеряет количество тестов, выполненных набором тестов (полученных другим способом, например, с использованием методов, основанных на спецификациях). Везде, где мы можем посчитать вещи и сказать, была ли каждая из этих вещей проверена каким-либо тестом, мы можем измерить охват. Основная мера покрытия:
Number of coverage items exercised Coverage = -------------------------------------- x 100% Total number of coverage items
где «coverage item» - это то, что мы смогли подсчитать и посмотреть, выполнил ли тест этот элемент или использовал его. Для методов, основанных на спецификациях, это могут быть случаи использования, разделы эквивалентности, граничные значения, состояния из диаграммы перехода состояний, процент бизнес-правил из таблицы решений и т. д. Для методов, основанных на структуре, элементы покрытия представлены структурные элементы кода. В принципе, оценка покрытия означает, что мы должны решить, какие структурные элементы мы будем использовать (например, заявления или решения). Затем найдите общее количество этих элементов в коде. Введите дополнительные операторы (например, ведение журнала) рядом с каждым структурным элементом, чтобы выяснить, использовался ли этот элемент во время выполнения Test case. И, наконец, измерьте охват, выполнив тесты и используя формулу, упомянутую выше. Но, как правило, вы не должны думать обо всех этих шагах, потому что есть много автоматизированных инструментов для измерения покрытия. Методы структурного тестирования обычно подразумевают, что вы должны измерить покрытие для существующих наборов тестов (включая наборы черного ящика), а затем разработать дополнительные Test case белого ящика, основанные на элементах структурного кода, для достижения максимально возможного покрытия.
Доп. материал:
- Тест дизайн методом Interface — Model — State
- Paradigms Paradigms of Black Box Software Software Testing Testing
- Test Design: A Survey of Black Box Software Testing Techniques
- Unit Test cases
- Business Requirements Document (BRD)
- Use Cases
- System/Functional Requirements
- Prototype
- Prototype Specification Document
- DB Fields Dictionary Spreadsheet
- Test Data
- Traceability Matrix Document
- User Manual/Training Guides/Documentation
- Test Plan Strategy Document/Test cases
- Automation/Performance Test Scripts
- Неофициальные reviews: это один из видов рецензирования, который не сопровождается каким-либо процессом поиска ошибок в документе. При использовании этого метода вы просто просматриваете документ и оставляете неофициальные комментарии к нему.
- Технические reviews: команда, состоящая из ваших коллег, изучает технические характеристики программного продукта и проверяет, подходят ли он для проекта. Они пытаются найти любые несоответствия в спецификациях и стандартах. Этот обзор концентрируется главным образом на технической документации, связанной с программным обеспечением, такой как: Стратегия тестирования, План тестирования и спецификации требований.
- Пошаговое руководство. Автор рабочего продукта объясняет продукт своей команде. Участники могут задавать вопросы, если таковые имеются. Встреча проводится автором.
- Инспекция: Основная цель - найти дефекты, а встречу проводит обученный модератор. Этот обзор является формальным типом обзора, где следует строгий процесс поиска дефектов. У рецензентов есть контрольный список для проверки рабочих продуктов. Они фиксируют дефект и информируют участников об устранении этих ошибок.
- Code Walk Through: Это неформальный анализ исходного кода программы для выявления дефектов и проверки методов кодирования.
- ~ - переменная еще не существует или предыдущий этап был последним
- d - определено, создано, инициализировано
- k - не определено, убито
- u - используется (c - использование вычислений; p - использование предикатов)
- блок процесса - одна точка входа и одна точка выхода
- точка альтернативы - одна точка входа, две и более точки выхода
- точка соединения - две и более точек входа, одна точка выхода
| Уровень | Название | Краткое описание |
| Уровень 0 | -- | "Тестируй все что протестируешь, пользователи протестируют остальное" На английском языке это звучит намного элегантнее: "Test whatever you test, users will test the rest" |
| Уровень 1 | Покрытие операторов | Каждый оператор должен быть выполнен как минимум один раз. |
| Уровень 2 | Покрытие альтернатив / Покрытие ветвей | Каждый узел с ветвлением (альтернатива) выполнен как минимум один раз. |
| Уровень 3 | Покрытие условий | Каждое условие, имеющее TRUE и FALSE на выходе, выполнено как минимум один раз. |
| Уровень 4 | Покрытие условий альтернатив | Тестовые случаи создаются для каждого условия и альтернативы |
| Уровень 5 | Покрытие множественных условий | Достигается покрытие альтернатив, условий и условий альтернатив (Уровни 2, 3 и 4) |
| Уровень 6 | "Покрытие бесконечного числа путей" | Если, в случае зацикливания, количество путей становится бесконечным, допускается существенное их сокращение, ограничивая количество циклов выполнения, для уменьшения числа тестовых случаев. |
| Уровень 7 | Покрытие путей | Все пути должны быть проверены |
Подробный разбор с примерами доступен в источнике: flylib.com/books/en/2.156.1/control_flow_testing.html
Loop testing определяется как тип тестирования программного обеспечения методом белого ящика, который полностью фокусируется на валидности конструкций цикла. Это одна из частей тестирования структуры управления (Control Structure testing): тестирование пути, проверка данных, тестирование условий (path testing, data validation testing, condition testing). Этот показатель сообщает, выполняли ли вы каждое тело цикла ноль раз, ровно один раз и более одного раза (последовательно). Для циклов do-while покрытие цикла сообщает, выполняли ли вы тело ровно один раз и более одного раза. Ценным аспектом этой метрики является определение того, выполняются ли циклы while и for более одного раза, т.к. эта информация не сообщается другими метриками.
- Неиспользованные выражения (Unused Statements)
- Мертвый код (Dead Code)
- Неиспользуемые ветви (Unused Branches)
- Недостающие операторы (Missing Statements)
Если тесты имеют полный branch coverage, то мы можем сказать, что они также имеют полный statement coverage, но не наоборот. Причина заключается в том, что в branch coverage, кроме выполнения всех statements, мы также должны проверить, выполняют ли тесты все ветви, что можно интерпретировать как охват всех ребер в control flow branch.
- Decision coverage включает в statement coverage, поскольку выполнение каждой ветви должно приводить к выполнению каждого statement. Эта связь сохраняется только тогда, когда control flows непрерывно до конца всех основных блоков. Например, функция C / C ++ может никогда не вернуться для завершения вызывающего базового блока, потому что она использует throw, abort, семейство exec, exit или longjmp.
- Path coverage включает в себя Decision coverage.
- Predicate coverage включает в себя Path coverage и multiple condition coverage, а также большинство других метрик.
- Определить условия и последствия
- Нарисовать график со всеми логическими зависимостями и ограничениями
- Преобразовать график в Decision Table, отслеживая каждую комбинацию причин, которые приводят к эффекту от эффекта (tracing each combination of causes that lead to an effect from the effect).
Тестирование каждого выбора (Each choice testing): эта стратегия означает, что каждое значение каждого конкретного параметра должно использоваться как минимум один раз в тестовом наборе. Таким образом, полученное количество случаев будет равно количеству значений параметра с наибольшим диапазоном. Каждый выбор - это минимальная стратегия покрытия.
| param1 | param2 | param3 | |
| a | 1 | X | |
| b | 2 | Y | |
| c | 3 | ||
| 4 | |||
| 5 | |||
| Test Case | param1 | param2 | param3 |
| 1 | a | 1 | X |
| 2 | b | 2 | Y |
| 3 | c | 3 | X |
| 4 | a | 4 | Y |
| 5 | b | 5 | X |
Тестирование базового выбора (Base choice testing): для этой стратегии мы должны определить наши базовые значения для каждого параметра. Это могут быть самые распространенные, самые маленькие / самые большие, самые простые или значения по умолчанию. После того, как мы сделали наш базовый выбор, мы должны изменять значение каждого параметра по одному, сохраняя при этом значения других параметров фиксированными при базовом выборе. Пусть a, 2 и Y будут нашим базовым выбором. Тогда кейсы будут:
| param1 | param2 | param3 |
| a | 1 | X |
| b | 2 | Y |
| c | 3 | Z |
| Test Case | param1 | param2 | param3 |
| 1 | a | 2 | Y |
| 2 | b | 2 | Y |
| 3 | c | 2 | Y |
| 4 | a | 1 | Y |
| 5 | a | 3 | Y |
| 6 | a | 2 | X |
| 7 | a | 2 | Z |
Доп. материал: Меньше, чем пара. Еще один способ сокращения количества тестов
Оно является техникой тестирования, которая использует ортогональные массивы для создания Test case. Это особенно полезно, когда тестируемая система имеет огромные входные данные. Например, когда необходимо проверить билет на поезд, необходимо проверить такие факторы, как - количество пассажиров, номер билета, номера мест и номера поездов. Один за другим проверка каждого фактора / ввода является громоздкой. Это более эффективно, когда инженер QA объединяет больше входных данных и проводит тестирование. В таких случаях мы можем использовать метод тестирования Orthogonal Array. Этот тип сопряжения или объединения входов и тестирования системы для экономии времени называется попарным тестированием (pairwise testing). Метод OATS используется для попарного тестирования. Сформулировать суть pairwise можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.В реальном мире у тестировщиков не будет свободного времени для выполнения всех возможных Test case, чтобы выявить дефекты, поскольку существуют другие процессы, такие как документация, предложения и обратная связь с заказчиком, которые необходимо учитывать на этапе тестирования. Следовательно, test managers хотели оптимизировать количество и качество Test case, чтобы обеспечить максимальное покрытие тестами с минимальными усилиями. Это усилие называется Test case Optimisation.
- Систематический и статистический способ тестирования парных взаимодействий
- Точки взаимодействия и интеграции являются основным источником дефектов.
- Выполните четко определенные, краткие Test case, которые могут выявить большинство ошибок.
- Ортогональный подход гарантирует попарное покрытие всех переменных.
Доп. материал:
Это метрика ПО, используемая для измерения сложности программы. Это количественная мера независимых путей в исходном коде программы. Независимый путь определяется как путь, имеющий хотя бы одно ребро, которое ранее не проходило ни в одном другом пути. Цикломатическая сложность может быть рассчитана относительно функций, модулей, методов или классов в программе. Эта метрика основана на представлении программы как control flow. Поток управления изображает программу в виде графа, который состоит из вершин и ребер. На графе вершины представляют обработку задачи, а ребра представляют поток управления между вершинами. Тестирование базового пути является одним из методов «белого ящика» и гарантирует выполнение хотя бы одного оператора во время тестирования. Он проверяет каждый линейно независимый путь в программе, что означает, что число тестовых примеров будет эквивалентно цикломатической сложности программы.
V(G) = E - N + 2 где E – количество ребер, N –количество вершин или V(G) = P + 1 где P - Количество предикатных узлов (узел, содержащий условие)
- Помогает разработчикам и тестировщикам определять независимые пути выполнения
- Разработчики могут быть уверены, что все пути были протестированы хотя бы раз
- Помогает нам больше сосредоточиться на открытых (uncovered) путях
- Улучшение покрытия кода
- Оценка рисков
- Использование этих метрик в начале цикла снижает риски
- Состояние (state, представленное в виде круга на диаграмме) – это состояние приложения, в котором оно ожидает одно или более событий. Состояние помнит входные данные, полученные до этого, и показывает, как приложение будет реагировать на полученные события. События могут вызывать смену состояния и/или инициировать действия.
- Переход (transition, представлено в виде стрелки на диаграмме) – это преобразование одного состояния в другое, происходящее по событию.
- Событие (event, представленное ярлыком над стрелкой) – это что-то, что заставляет приложение поменять свое состояние. События могут поступать извне приложения, через интерфейс самого приложения. Само приложение также может генерировать события (например, событие «истек таймер»). Когда происходит событие, приложение может поменять (или не поменять) состояние и выполнить (или не выполнить) действие. События могут иметь параметры (например, событие «Оплата» может иметь параметры «Наличные деньги», «Чек», «Приходная карта» или «Кредитная карта»).
- Действие (action, представлено после «/» в ярлыке над переходом) инициируется сменой состояния («напечатать билет», «показать на экране» и др.). Обычно действия создают что-то, что является выходными/возвращаемыми данными системы. Действия возникают при переходах, сами по себе состояния пассивны.
- Точка входа обозначается черным кружком.
- Точка выхода показывается на диаграмме в виде мишени.
Еще пример с банкоматом. После того, как мы визуализировали все переходы, мы просто выполняем определенные пути из диаграммы в качестве Test case:
Как создать хорошие сценарии (Сэм Канер):
- Напишите истории жизни для объектов в системе.
- Перечислите возможных пользователей, проанализируйте их интересы и цели.
- Подумайте об отрицательных пользователях: как они хотят злоупотреблять вашей системой?
- Перечислите «системные события». Как система справляется с ними?
- Перечислите «особые события». Какие приспособления система делает для них?
- Перечислите преимущества и создайте сквозные задачи, чтобы проверить их.
- Интервью пользователей об известных проблемах и сбоях старой системы.
- Работайте вместе с пользователями, чтобы увидеть, как они работают и что они делают.
- Читайте о том, что должны делать подобные системы.
- Изучите жалобы на предшественника этой системы или ее конкурентов.
- Создать фиктивный бизнес. Относитесь к нему как к реальному и обрабатывайте его данные.
- Попробуйте преобразовать реальные данные из конкурирующего или предшествующего приложения.
Пример: если пользователь вводит правильное имя пользователя и пароль, он будет перенаправлен на домашнюю страницу. Если какой-либо из вводимых данных неправильный, появится сообщение об ошибке.
| Условие | 1 | 2 | 3 | 4 |
| Имя пользователя (+/-) | - | + | - | + |
| Пароль (+/-) | - | - | + | + |
| Итог (E/H) | E | E | E | H |
- Случай 1 - имя пользователя и пароль были неверны. Пользователю показывается сообщение об ошибке.
- Случай 2 - Имя пользователя было правильным, но пароль был неправильным. Пользователю показывается сообщение об ошибке.
- Случай 3 - Имя пользователя было неверным, но пароль был правильным. Пользователю показывается сообщение об ошибке.
- Случай 4 - имя пользователя и пароль были правильными, и пользователь перешел на домашнюю страницу Преобразуя это в тестовый пример, мы можем создать 2 сценария:
- Введите правильное имя пользователя и правильный пароль и нажмите на кнопку входа, и ожидаемый результат будет пользователь должен перейти на домашнюю страницу
- И один из сценария ниже:
- Введите неправильное имя пользователя и неправильный пароль и нажмите на кнопку входа, и ожидаемый результат будет, пользователь должен получить сообщение об ошибке
- Введите правильное имя пользователя и неправильный пароль и нажмите на кнопку входа, и ожидаемый результат будет, пользователь должен получить сообщение об ошибке
- Введите неправильное имя пользователя и правильный пароль и нажмите на кнопку входа, и ожидаемый результат будет, пользователь должен получить сообщение об ошибке
| Monkey testing | Gorilla testing |
| Тестирование выполняется случайным образом без каких-либо заранее определенных Test case | Тоже |
| Тестирование выполняется на всей системе может иметь несколько Test case | Тестирование выполняется на нескольких отдельных модулях с небольшим количеством Test case. |
| Целью Monkey testing является проверка на сбой системы | Целью тестирования Gorilla является проверка правильности работы модуля. |
| Monkey testing | Ad-hoc testing |
| Тестирование выполняется случайным образом без каких-либо заранее определенных Test case | Тестирование выполняется без планирования и документации (контрольные примеры и SRS) |
| В Monkey testing тестировщики могут не знать, что за ПО и для чего оно предназначено. | В Ad-hoc testing тестировщик должен понять ПО перед выполнением тестирования |
| Целью Monkey testing является проверка на сбой системы | Целью специального тестирования является случайное разделение системы на части и проверка их функциональности. |
- Тупая обезьяна: тестировщики не имеют представления о системе и ее функциональных возможностях, а также не имеют никаких гарантий относительно достоверности Test case.
- Умная обезьяна: тестировщик имеет четкое представление о системе, ее назначении и функциональности. Тестировщик перемещается по системе и предоставляет действительные данные для выполнения тестирования.
- Выдающаяся обезьяна: тестировщики выполняют тестирование в соответствии с поведением пользователя и могут указать некоторые вероятности возникновения ошибок.
- Определение относящихся к тесту аспектов (аспектов, которые влияют на функциональность - так называемые классификации) и их соответствующих значений (называемых классами, это могут быть точные значения или классы эквивалентности).
- Объединение разных классов из всех классификаций в Test case.
- Output based verification (смотрим что возвращает)
- State based verification (смотрим состояние)
- Communication based verification (общение и зависимости)
- Взаимный просмотр:
- беглый просмотр — автор показывает свою работу коллегам, они в свою очередь дают свои рекомендации, высказывают свои вопросы и замечания;
- технический просмотр — выполняется группой специалистов;
- формальная инспекция — привлекается большое количество специалистов, представляет собой структурированный, систематизированный и документированный подход. Минус такого варианта — тратится много времени.
- Вопросы — если возникают вопросы, то можно спрашивать у представителей заказчика, более опытных коллег.
- Тест-кейсы и чек-листы — хорошее требование должно быть проверяемым, чтобы это определить можно использовать чек-листы или полноценные тест-кейсы. Если можно быстро придумать несколько пунктов чек-листа — это уже хороший знак.
- Исследование поведения системы — необходимо мысленно смоделировать процесс работы пользователя с системой, созданной по тестируемым требованиям, после этого определить неоднозначные варианты определения системы.
- Рисунки — графическое представление дает наглядное представление приложения, на рисунке проще увидеть, что какие-то элементы не стыкуются, где-то чего-то не хватает и т. д.
- Прототипирование — сделав наброски пользовательского интерфейса, легко оценить применение тех или иных пользовательских решений
- Эвристика «Время вышло!» мы останавливаем тестирование, когда заканчивается выделенное на него время.
- Эвристика пиньяты (The Piñata Heuristic). Мы прекращаем ломать программу, когда начинают выпадать конфеты – мы останавливаем тестирование, когда видим первую достаточно серьезную проблему.
- Эвристика «мертвой лошади». В программе слишком много ошибок, так что продолжение тестирования не имеет смысла. Мы знаем, что все изменится настолько, что сведет на нет результаты текущего тестирования.
- Эвристика «Задание выполнено» останавливаем тестирование, когда найдены ответы на все поставленные вопросы.
- Эвристика «Отмена задания» Наш клиент сказал нам: «пожалуйста, прекратите тестирование». Это может произойти по причине перерасхода бюджета, или вследствие отмены проекта, и по любой другой причине. Какова бы ни была причина, нам поручили остановить тестирование. (На самом деле эвристика «Время вышло!» может быть частным случаем более общей «Отмены задания», в том случае, если предпочтительнее, чтобы не мы сами, а заказчик принял решение о том, что время вышло.)
- Эвристика «Я зашел в тупик!» По какой бы то ни было причине мы останавливаемся, поскольку обнаруживаем некое препятствие. У нас нет информации, которая нам требуется (например, многие люди заявляют, что не могут тестировать без достаточного количества спецификаций). Имеется блокирующая ошибка, и таким образом мы не можем перейти в ту область продукта, которую необходимо протестировать, у нас нет необходимого оборудования или инструментария, у команды нет квалификации, требуемой для выполнения некоторых специальных тестов.
- Эвристика «освежающей паузы» Вместо прекращения тестирования мы приостанавливаем его на некоторое время. Мы можем остановить тестирование и сделать перерыв, когда мы устали, когда нам стало скучно или пропало вдохновение. Мы можем сделать паузу на то, чтобы выполнить некоторые исследования, разработать планы, поразмыслить над тем, что мы делали в прошлом и понять, что делать дальше. Идея заключается в том, что нам требуется определенный перерыв, после которого мы сможем вернуться к продукту со свежим взглядом или свежими мыслями. Также есть и другой вид паузы: мы можем остановить тестирование какой-либо функции, поскольку в настоящий момент другая имеет более высокий приоритет.
- Эвристика «Отсутствие продвижения» Что бы мы ни делали, мы получаем тот же самый результат. Это может происходить в случае, когда программа падает определенным способом или перестает отвечать, но также мы можем не продвигаться, когда программа в основном ведет себя стабильно: "выглядит хорошо!"
- Эвристика Привычного завершения. Мы останавливаем тестирование тогда, когда мы обычно останавливаем тестирование. Имеется протокол, задающий определенное количество идей для тестирования, или тест-кейсов, или циклов тестирования, или как вариант – имеется определенный объем работ по тестированию, который мы выполняем и после этого останавливаемся. Agile-команды, например, часто применяют такой подход: «когда выполнены все приемочные тесты, мы знаем, что продукт готов к поставке. Отличие от эвристики «Время вышло!» в том, что временные ограничения могут изменяться более гибко, чем некоторые другие.
- Больше нет интересных вопросов В этот момент мы решаем, что не осталось вопросов, ответы на которые были бы достаточно ценными, чтобы оправдать стоимость продолжения тестирования, и поэтому мы останавливаемся. Эта эвристика используется в основном как дополнение к другим эвристикам, помогая принять решение о том, есть ли какие-то вопросы или риски, которые отменяют действие этих эвристик (примеры таких вопросов я привожу после каждой эвристики). Кроме того, если одна эвристика советует нам прекратить тестирование, следует проверить, нет ли интересных вопросов или серьезных рисков в других областях, и если они есть, то мы скорее продолжим тестирование, чем остановимся.
- Эвристика уклонения/безразличия. Иногда людей не интересует дополнительная информация, либо они не хотят знать, что происходит в программе. Тестируемое приложение может быть первой версией, которую, как мы знаем, скоро заменят. Некоторые люди прекращают тестирование по причине лени, злого умысла или отсутствия мотивации. Иногда бизнес-критичность выпуска нового релиза настолько высока, что никакая мыслимая проблема не остановит выход программы, и поэтому никакие новые результаты тестирования не будут иметь значения.
Мнемоника – это набор правил и приемов, которые помогают эффективно запоминать необходимые сведения (информацию). Большинство экспертов с мировым именем в сфере тестирования настоятельно рекомендуют использовать проверенную схему SFDPOT, автором которой является Джеймс Бах. По их словам, это самый качественный и правильный инструмент для быстрой генерации тестовых идей и наработок. Итак, что такое SFDPOT? SFDPOT – Structures, Functions, Data, Platforms, Operations, Times:
- Structures – архитектура приложения (продукта), которая проверяется по частям. На этом этапе создаются тестовые идеи и шаги, неразрывно связанные со структурой веб-продукта;
- Function – производительность приложения (продукта). Проверка того, что может выполнять приложение (продукт). На этом этапе проводится функциональное тестирование ПО;
- Data – взаимодействие с данными. Проверка приложения на взаимодействие с данными. QA специалисты должны определить по какой логике продукт взаимодействует с данными, как проходит их получение, тип обработки и виды информации;
- Platform – экосистема, платформа. Выполнение проверки того, как именно приложение (продукт) потенциально взаимодействует с платформой, на которой оно создано и запущенно. Тестировщик должен определить, на каких именно платформах и внутри каких систем необходимо провести процедуру ручного и автоматизированного тестирования;
- Operations – проверка созданных сценариев для разработанного приложения. На этом этапе перед тестировщиками постает задача по выяснению потенциального круга будущих пользователей, которые будут взаимодействовать с создаваемым продуктом;
- Time – период времени, проверка того, как продукт ведет себя в зависимости от наступления или завершения каких-либо временных промежутков.
Что же касается CRUCSPIC STMP, то этот метод может рассматриваться как составная часть Operations внутри методики SFDPOT. Если вкратце сказать о функциональности CRUCSPIC STMP, то можно отметить, что это своего рода атрибуты системы. Наработки CRUCSPIC STMP позволяют выделить основные объекты тестирования, его целей, а также построить карту эффективности взаимодействия между собой.
