Пост 1. Тема: "Тестирование ПО"
Для того, чтобы нам понять какое влияние имеет тестирование продукта, нам стоит узнать:
- Что такое Тестирование ПО?
- Что такое разработка ?
- Какое место занимает тестирование в разработке ?
Из ответов на эти банальные казалось бы вопросы, мы сможем сформировать полноценное мнение о том, что такое Тестирование в IT-сфере.
Давай начнем с азов и разберем вопрос, что такое тестирование ПО?
Самое банальное, что мы можем - это познакомиться с такой темой как "Фундаментальные основы тестирования".
Что же нам говорят эти основы:
Тестирование ПО - это процесс исследования и проверки на соответствие РЕАЛЬНОГО и ОЖИДАЕМОГО поведения программного продукта, на основе заданных требований и подготовленных тестовых сценариев.
От сюда мы можем понять, что тестирования - это процесс исследования и самая банальная аналогия, которая может прийти к нам это:
"Человек, который изучает новые для себя какие-то новые аспекты, профессии, мир, да что угодно на самом деле."
Даже сейчас, зайдя на эту статью можете считаться исследователем, но вы исследуете не ПО, а новые для себя знания и точку зрения, которая поможет вам в будущем стать профессионалом в своей сфере.
От сюда появляются вопросы:
1. Кто такой тестировщик ?
2. Какие могут быть реальное и ожидаемое поведение ПО ?
3. Что такое требования и тестовые сценарии ?
Давай ответим на эти вопросы и слегка углубимся в тему.
Кто такой тестировщик ?
Тестировщики разделяются на 2 вида: QA и QC.
Есть ответвления к примеру AQA - но это ответвление от QA.
QA - Quality Assurance Enginner - Инженер по обеспечению качества.
QC - Quality Control Engineer - Инженер по контролю качества.
Если подробнее, то:
QA - это специалист, ответственный за обеспечение качества продукта на протяжении всего жизненного цикла разработки.
Его главная задача - предотвратить появление багов и повысить качество и надежность разрабатываемого и/или выпущенного продукта.
QC - это специалист, ответственный за непосредственный контроль качества готового продукта путем выполнения тестов и выявления дефектов.
Его главная задача - предотвратить появления багов, повысить надежность и качество уже готового продукта.
В чем отличия двух разных, но при этом столь близких видов тестировщиков:
QA-инженер: Занимается обеспечением качества на всем жизненном цикле продукта.
QC-инженер: Занимается обеспечением качества готового продукта.
Вот мы и ответили на вопрос "Кто такой тестировщик ?"
Какие могут быть реальное и ожидаемое поведение ПО ?
Под "Реальным" и "Ожидаемом" поведении ПО подразумевается то, как ведет себя продукт.
Основная цель:
Реальный результат не должен отличаться от Ожидаемого, либо он может отличаться, но не сильно.
Реальное поведение - это поведение продукта или функции, которое исходит от реального взаимодействия с продуктом или функцией.
Проще объяснить на примере:
В калькуляторе ты считаешь 1+1 = 2 - это положительный пример.
В калькуляторе ты считаешь 1+1 = 3 - это отрицательный пример.
Можно взять чуть-чуть более сложный пример:
В маркетплейсе, ну допустим ЫЗОН - ты выбираешь фильтр "Носки", в окне поиска появляются генераторы, машины и т.п. шлак, который тебе не нужен.
Это так же полностью отрицательный пример, с которым ты можешь или даже уже сталкивался - это как раз БАГ, который нужно исправлять.
Ожидаемое поведение - это поведение продукта или функции, которое исходит от требований к продукту или функции.
Давай так же приведем пример:
Заказчик говорит: Я хочу, чтобы при нажатии на "Розовую" кнопку с надписью "Х", появлялось окно с надписью - "Поздравляем, ты нажмал на кнопку "Х", ты ничего не получишь, но мы спишем с тебя 300 рублей".
Из примера мы можем выделить такие вещи как:
- Дизайнерское решение
- Функцию
- Итог
Специалисты разработки и тестирования задают тонны вопросов, на которые получают не тонну ответов и от этого как-раз происходит создание требований и ожидаемых результатов.
Давай рассмотрим пример когда "Ожидаемый" и "Реальный" результаты рознятся:
Человек на сайте нажал кнопку "Х" - вышло окно с надписью "Поздравляем, ты нажмал на кнопку "Х", ты ничего не получишь, но мы спишем с тебя 300 рублей", но человеку приходит на карту 300 рублей вместо списания.
Итог:
Реальная функция отрабатывает не списание, а зачисление и уже это и есть баг, когда Ожидаемый результат разнится с реальным. Подобные примеры можно применять к огромному числу практик тестирования и они будут обоснованы достаточно, чтобы иметь хороший вес.
Что такое требования и тестовые сценарии ?
Требования к ПО - это различная важнейшая документация, которую формирует в первую очередь заказчик, она рассказывает о том, что вообще он хочет, что вообще должно быть реализовано и как это должно работать.
Так же вся эта мишура с требованиями, спецификациями и т.п. очень хорошо раскрывается в такой теме как "Работа с требованиями".
Зачем нужны требования, когда дядя Вася хочет реализовать что-то:
Хорошее понимание требований позволяет избежать множества проблем на всем цикле разработки и тестировании продукта.
Хорошие или же Корректно сформированные требования помогают:
- Снизить риски багов
- Ускорить процесс разработки и тестирования.
- Увеличить качество продукта.
- Обеспечить соответствие желаний и задумок
Исходя из того, что мы сейчас разобрали, можно сказать дяде Васе, что "Я не понимаю по Русски и иди пиши документы, я хочу понимать тебя как на твоем, так и на своем языке".
После разработки требований идут такие процессы как:
Анализ требований.
Валидация требований.
Трассировка требований.
Контроль требований.
На...я это вообще нужно ?
- Я хоть тут один, но отвечу на вопрос.
Анализ требований - это процесс, который позволяет вообще понять, что заказчик хочет, понять проблемы и риски.
Валидация требований - это процесс проверки требований на соответствие стандартам в разработке и хотелок заказчика.
Трассировка требований - это процесс сопоставления требований и тестовых сценариев, чтобы убедиться, что каждое требование покрыто соответствующим тестом.
Контроль требований - это процесс отслеживания хотелок на уже сформированные требования и их влияние на созданные тесты.
Вот мы разобрали, что же такое требования. Давай разберем, что же такое тестовые сценарии или же "Тестовая документация".
Тестовая документация - это набор инструментов, которые используются для формирования и отладки процесса тестирования.
Зачем это нужно:
- Организация процесса тестирования.
- Обеспечение полноты и точности тестирования.
- Поддержка прозрачности и контроля процесса.
- Улучшение коммуникации между командами/командой и заказчиком.
Тестовая документация состоит из такого набора документов:
1. Тест-План.
2. Тест-кейс.
3. Чек-Лист.
4. Баг-Репорт.
5. Отчет о тестировании.
6. Матрица покрытия.
7. Оценка рисков.
Вся эта документация разрабатывается в начале, процессе или при завершении тестирования продукта. Если все хорошо, то продукт выпускается, если не хорошо, то продукт дорабатывается, либо выбрасывается.
Ля... Поздравляю, ты ответил для себя на множество интересных и не очень вопросов. Давай подытожим:
- Тестирование ПО - это процесс исследования продукта на наличие багов.
- Специалист по тестированию ПО - это человек, который непосредственно занимается тестированием.
- Реальное и Ожидаемое поведение продукта - это основополагающие ориентиры для определения как работает продукт или функция
Хорошо или Плохо. - Требования к продукту - это набор документов, которые нужны для реализации всего продукта.
- Тестовая документация - это набор документов, которые нужны для тестирования всего продукта.
Вот мы и ответили на вопрос "Что такое тестирование ?"
Для неформальности, я специально накидывал тебе всякой инфы так, как я ее вижу, поверь мне, тебе было бы не интересно читать это все будь тут тупо тех инфа.
А если тебе реально хочется узнать если не все, то огромный пласт максимально полезной инфы по тестированию, то переходи на Boosty, там я предлагаю свою книженцию по тестированию. Она сейчас находится в разработке, а точнее разрабатываю 2 модуль, для практических навыков тестирования, а базу ты уже получишь :)
Так, я что-то отвлекся.
Что такое разработка ?
Так как мы тестировщики, пускай даже начинающие, дам тебе немного знаний, чтобы ответить тебе на этот вопрос, особо сильно углубляться в дебри я не буду.
Разработка ПО - это процесс, при котором всякие специалисты пишут код и в последствии функции, создают различные виды дизайна и развивают базу, на которой будет держаться весь проект.
Есть множество способов разработки продукта, самая банальная и лежащая на поверхности - это методология Waterfall - Каскадная модель - но ею не часто пользуются, она попросту устарела. Сейчас популярные это Agile модели.
Давай чуть-чуть разберем Agile-методологии.
Пс.. Методологии и Модели разработки = это одно и тоже, так что не путаемся.
Agile Model - это модель основанная на итеративной и инкрементальной моделях, которые в свою очередь предполагают частую обратную связь с заказчиком и внутри группы разработки.
Так, перед тем, как скажу как она работает слегка разберем, что такое Итеративная и Инкрементальная модели.
Итеративная модель - это подход к разработке, при котором продукт создается через повторяющиеся циклы (итерации).
Каждая итерация включает полный цикл разработки - от планирования до тестирования - с постепенным улучшением и расширением функциональности.
Инкрементальная модель - это подход к разработке, при котором продукт создается через последовательное добавление отдельных частей (инкрементов) - каждая часть предоставляет набор функций и интегрируется с ранее реализованными.
Agile модель вбирает в себя эти способы разработки. Надеюсь стало чуть более понятно.
Так же Agile сформировал для себя свой манифест и правила, которым и старается следовать. Полностью описывать его я не буду, но немного распишу:
Agile-манифест (Кратко)
Манифест включает в себя 4 цели и 12 принципов:
Цели:
1. Люди и взаимодейтсвие важнее процесса и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
Принципы:
1. Удовлетворение заказчика посредством скорого и непрерывного предоставления рабочего продукта.
2. Готовность принимать изменяющиеся требования, даже на поздних этапах разработки.
3. Регулярное предоставление рабочего продукта с периодичностью от нескольких недель до месяцев.
4. Ежедневное тесное сотрудничество бизнеса и разработчиков.
5. Построение проектов вокруг мотивированных людей, которым обеспечивают условия и доверяют.
6. Личное общение - самый эффективный способ передачи информации.
7. Работающий продукт - основной показатель прогресса.
8. Поддержка постоянного темпа работы, способствующего устойчивому развитию.
9. Внимание к техническому совершенству и качеству дизайна.
10. Простота - искусство максимального сокращения работы, не приносящей ценности.
11. Самоорганизующиеся команды создают лучшие архитектуры, требования и проекты.
12. Регулярные размышления команды, как стать эффективнее, с последующей корректировкой поведения.
В целом на этом и хватит разгонять тему. Давай подытожим:
Разработка ПО - это процесс создания/реализации продукта, где ожидания и требования заказчика проверяются в соответствии с различными спецификами разработки и разрабатывают продукт.
Давай уже ответим на последний для этой статьи вопрос:
Какое место занимает тестирование в разработке ?
Отвечая на этот вопрос, мы затрагиваем все, об чем сегодня было написано и даже больше. Тестирование - это огромнейший процесс, который охватывает не только разработку, но и этапы до него (Идея) и после (Выпуск, сопровождение и завершение эксплуатации продукта).
Но если мы берем именно узкий этап для всего цикла разработки, а именно непосредственную разработку, вот что делает тестирование:
- Обеспечивает качество.
Выявление багов до выхода продукта на рынок, тем самым обеспечивая качество и надежность. - Проверка соответствия требованиям.
Тесты поддерживают, что разработанный продукт соответствует заданным требованиям и спецификациям заказчика. - Уменьшение стоимости исправления ошибок
Обнаружение багов на ранних этапах разработки стоит куда дешевле, чем обнаружение и исправление багов уже после выхода продукта. - Поддержка непрерывной интеграции и реализации (CI/CD)
Автоматизированное тестирование является неотъемлемой частью современных практик разработки, таких как Agile и DevOps. - Повышение доверия пользователей.
Продукт, прошедший всестороннее тестирование, вызывает больше доверия у пользователей, так как обладает более высокой стабильностью и предсказуемостью поведения.
Без тестирования можно выпустить продукт, но качество этого продукта крайне условно.