БЕСПЛАТНЫЙ КУРС по основам тестирования ПО

Прочитал "БЕСПЛАТНЫЙ КУРС по основам тестирования ПО" 

Рекомендую этот курс для новичков, даже наверное сначала лучше его изучить, перед тем как читать книгу Станислава Куликова.

"БЕСПЛАТНЫЙ КУРС по основам тестирования ПО"  

Содержание курса:

Книга Станислава Куликова "Тестирование программного обеспечения Базовый курс"

Я таки осилил эту книгу.

Кратко озвучу своё мнение, а потом сделаю краткое содержание этой книги, т.к. не нашел оного.

Это вторая книга по тестированию, которую я прочитал.

Первая была Романа Савина - мой отзыв можно почитать здесь . И благо есть уже сокращение книги Р.Савина и плюс её в простоте языка, которым она написана, в изобилии примеров, в т.ч. наглядных, понятной структуры - в общем это хорошая книга для новичка. Чего не могу сказать о книге С.Куликова.

Прежде чем читать его книгу очень рекомендую заглянуть сюда. Здесь идёт общение автора с читателями и обсуждение книги. И разбирают довольно подробно вопрос: "А для кого эта книга написана?"

Моё личное мнение: для новичка тяжеловато она читается, скучно и даже нудно написана. Но есть там полезные вещи поэтому прочитать стоит. А здесь я постараюсь дать сокращенный вариант. Опять же сокращать буду исходя из своего понимания предмета. Скорее даже выдержки из книги.

Первая работа в IT

Я таки устроился на работу в крупную международную IT компанию. Правда на должность инженера тех поддержки (2-ая линия) в проект сопровождения. Но всё равно - это только первый шаг.

Работаю с августа 2021 г. 

Помимо непосредственных обязанностей саппорта, чем ещё занимаюсь:

1. Выполнение тест-кейсов в Zephyr (дымовое, позитивное, регресс)

2. Редактирование (актуализация) и составление тест-кейсов.

3. Пишу мануалы по бизнес-процессам своей должности.

4. Завожу баг-репорты. 

5. Участие в тестировании продукта.

6. Ревьюирование инструкций пользователей.

Всё это в Jira и Confluence. 

Выдержки из курса: "Введение в функциональное тестирование"

Качество – способность программы делать то, что ждет от неё пользователь.

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

Ошибка – действие человека, которое приводит к неправильному результату.

Дефект (fault) – возможная причина отказа. Изъян в компоненте или системе.

Верификация – проверка, что делается всё правильно.

Валидация – проверка, что делается что нужно.

Жизненный цикл ПО: 

• Концепция
• Описание требований
• Дизайн
• Реализация
• Тестирование
• Установка и Наладка
• Эксплуатация и поддержка

Методологии разработки программного обеспечения:

• Модель «водопад»
• V-образная модель
• Инкрементальная модель
• Спиральная модель
• Гибкая модель
• Итеративная

Планирование тестирования. Стадии тестирования

Закончил таки курс "Введение в функциональное тестирование". Довольно нудный получился курс лекций, который базируется на ISTQB.

Выдержки из последней лекции.

Планирование тестирования. Стадии тестирования

Стадии тестирования

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

Тест-дизайн

 В рамках изучения курса "Функциональное тестирование" подробно рассматривалась тема "Тест-дизайн". Довольно объемная тема оказалась.

 Хотя весь курс, как мне кажется, не дает понимания "ФТ", он скорее является обзорным по основам тестирования и какие-то моменты освещаются чуть подробнее. Плюс за основу взяты стандарты ISTQB.

Итак,

Тест дизайн - срез по курсу:

Тест-дизайн – этап тестирования, включающий в себя разработку тестирования (Test development): проектировка и создание тест-кейсов.

Методики обеспечения качества:

Статические – без запуска кода (анализ кода, требований).

Динамические – запуск ПО.

Далее рассматриваются техники обеспечения качества, которые поделены на две группы соответственно: статические и динамические

Дефект

Дефект (недочет, помеха) – изъян в компоненте или системе, может привести к отказу компонента или системы. Обнаруживается во время тестирования

Ошибка (просчет) – в последствии действия или бездействия человека.

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

Дефекты:
• функциональности
• эргономики модуля или бизнес-процесса
• документирования
• производительности
• локализации
• совместимости
• безопасности

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

Приоритет:
• блокирующая – дальнейшая работа над продуктом заблокирована, пока не будут исправлены ошибки.
• максимальная – связанные с главными бизнес-процессами или ошибки, которые понесут урон репутации компании.
• высокая – мешают разработке и пользованию продукта, но не являются критичными
• нормальная – не несут серьезных потерь для бизнеса
• низкая – исправляются в последнюю очередь

Атрибуты дефекта:
• краткое наименование
• дата
• автор
• ссылка на систему и версия (окружение)
• приоритет
• серьезность
• описание (предусловия, шаги, ожидаемы результат, фактический результат)
• состояние, статус

Требования

Бизнес требования (БТ)
Функциональные требования (ФТ)
Нефункциональные требования (НФТ)
Тестовые требования (ТТ)

Если я правильно понял то:

БТ - определяют суть продукта, для чего он, т.е. определяет цель его создания.

ФТ - соответственно определяет функции продукта, что он должен делать.

НФТ - определяет как он должен выполнять ФТ. + удобство, надежность, безопасность и пр. т.п.

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

Прошу писать критику и своё мнение в комментариях.

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

1. Необходимая часть тестового сценария – определение ожидаемого результата

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

2. Программист должен избегать тестирования собственных программ

 Следует избегать тестирования программы ее автором.

3. Вдумчиво изучайте результаты каждого теста

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

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

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

5. Определение, что программа делает то, что должна – лишь половина дела. Другая половина – проверка, что программа не делает того, чего не должна

 Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и ни делает ли она то, что не должна делать.

6. Избегайте исключения тестовых сценариев

 Не следует выбрасывать тесты, даже если программа уже не нужна.

7. Не планируйте тесты в предположении, что ошибки не будут найдены

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

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

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

9. Тестирование – исключительно творческая и интеллектуальная задача.

Второй тест: тестирование освежителя воздуха

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

Прошу писать критику в комментариях под постом.

Тестирование освежителя воздуха

Тест кейс G

Обобщил текущие знания

Обобщил текущие знания на основе источников, указанных в этом посте

Обеспечение качества (QA — Quality Assurance)

Контроль качества (QC — Quality Control)

Тестирование (Testing)

Цель тестировщика – проверить ПО на соответствие требованиям, находить критические ошибки.

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

Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).

Т может показать, что дефекты присутствуют, но не может доказать, что дефектов нет.

Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).

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

Принцип 3 — Раннее тестирование (Early testing).

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

Принцип 4 — Скопление дефектов (Defects clustering).

Большая часть дефектов находится в ограниченном количестве модулей.

Принцип 5 — Парадокс пестицида (Pesticide paradox).

Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.

Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.

Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Первый тест: тестирование зубочисток

Выкладываю ссылку на первый свой тест, который написал его ещё до прочтения книги Романа Савина. Основывался на просмотренном видео с курса тестировщика (Первый уровень) и статьях, которые прочитал к тому моменту. Выбрал простой бытовой предмет и расписал всё по этапам. Прошу писать критику в комментариях под постом.

Тестирование зубочисток

p.s.

Тест кейс Z 

Источники знаний

На данный момент прочитал книгу Романа Савина "Тестирование Дот Ком".

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

Позже представлю некий обобщенный срез знаний в виде статьи, а пока представлю несколько  основных источников информации:

1. Конечно Хабр. В частности замечательная, на мой взгляд статья для новичка в тестировании: Фундаментальная теория тестирования
2. При различных запросах поисковик частенько выдавал ссылку на Форум тестировщиков, где можно почерпнуть много полезной информации.
3. В процессе серфинга по сети наткнулся на интересный блог: Ольга Назина (Киселева), где объясняются темы простым языком с примерами.

Естественно в процессе изучения тестирования встречался с незнакомыми, непонятными мне терминами, и в поисках объяснений провёл много часов погружаясь в чтение различных статей.

Есть ещё один источник обучения: видео с курсов тестировщика, пока просмотрел первый уровень.

Отдельно прокомментирую книгу Романа Савина. Её много где рекомендуют, особенно для новичков. В книге много конкретики, примеров, понравилось что есть примеры оформления тест-кейсов и прочего. При этом стилистика подачи материала своеобразная, со вставками шуток юмора, местами видимо авторского. Меня это порой только сбивало с темпа и логики повествования. Перечитывать я её вряд ли буду, тем более что сейчас достаточно много материала есть в свободном доступе и есть из чего выбрать. Но нашел довольно хороший сокращенный вариант здесь: Выдержки из книги Романа Савина Тестирование DOT COM Сюда пожалуй можно периодически заглядывать, чтобы вспомнить суть предмета. 

Upd: К сожалению страничка с сокращенным содержанием книги Р.Савина пропала. Придется самому делать сокращенный вариант. Выложу отдельным постом. 

Приветствие и вступительное слово

Добрый день.

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

Здесь буду описывать свой текущий опыт, свои знания, процесс обучения.

Основная информация:

Родился 10 октября 1986, т.е. в 2021 году исполнится 35 лет.

Порядка 10 лет проработал в продажах: b2c, b2b. По большей части в сфере телекоммуникаций.

Подробнее об опыте работы на hh.ru: hh.ru/resume/dmitrybvita

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