О нас

Карьера

Команда

<h3>Ручной метод тестирования</h3> 1.Ручное тестирование — это тип тестирования программного обеспечения, при котором тестировщики вручную выполняют тестовые примеры без использования каких-либо инструментов автоматизации. Ручное тестирование является наиболее примитивным из всех видов тестирования и помогает найти ошибки в программной системе. 2.Любое новое приложение должно быть протестировано вручную, прежде чем его тестирование можно будет автоматизировать. Ручное тестирование требует больше усилий, но оно необходимо для проверки возможности автоматизации. 3.Ручное тестирование не требует знания каких-либо инструментов тестирования. Цели ручного тестирования 1.Ключевая концепция ручного тестирования — убедиться, что приложение не содержит ошибок и работает в соответствии с заданными функциональными требованиями. 2.Тестовые наборы или кейсы разрабатываются на этапе тестирования и должны иметь 100% тестовое покрытие. 3.Он также гарантирует, что обнаруженные дефекты исправлены разработчиками, а тестировщики выполнили повторное тестирование исправленных дефектов. 4.По сути, это тестирование проверяет качество системы и доставляет клиенту продукт без ошибок. Полезные ссылки:<a href="https://www.guru99.com/manual-testing.html" target="_blank">Manual testing article/eng</a><a href="https://www.softwaretestinghelp.com/manual-testing-tutorial-1/" target="_blank">Manual testing article/eng</a><a href="https://www.youtube.com/watch?v=AjkYTJklAa8" target="_blank">Manual testing video tutorial/eng</a><a href="https://www.youtube.com/watch?v=1lHCM2Br2eA" target="_blank">Manual testing video tutorial/rus</a>

Что такое ручное тестирование и как оно проводится?

Ручное тестирование

<h3>Что такое QE?</h3> Качество программного обеспечения - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. <h3>Что такое Software Testing?</h3> Это одна из техник контроля качества, включающая в себя активности по планированию тестовых действий, дизайну тестов, выполнению этих тестов и анализу полученных данных. <h3>Что такое QA?</h3> Самое широкое из всех понятий и представляет собой совокупность мероприятий, охватывающих абсолютно все этапы разработки, выпуска и эксплуатации программного обеспечения. Это активности на всех этапах жизненного цикла ПО, которые предпринимаются для обеспечения требуемого уровня качества выпускаемого продукта. <h3>Этапы обеспечения качества</h3> <ol><li>Проверить требования к продукту</li><li>Оценка рисков</li><li>Планирование идей улучшения качества продукции</li><li>Планирование тестирования</li><li>Анализ результатов тестирования</li></ol> <h3>Обеспечение качества VS Контроль качества</h3> Для понимания зависимости между понятиями Testing, Quality control, Quality Assurance привожу схему: <span style="font-size:9pt;font-family:Arial,sans-serif;color:#f1ff00;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh7-us.googleusercontent.com/51n_vj3gqxmGxvXiJ7UYBiRJKBvEwd9CvCNY4di2BpYhl1ZaXyZ3P8aQYzuwCaRhpk8Y7KQtgEth9Q6pWGpep0UR24ss2tzWuvIfBtx9xDhn6njZKAVrJjZB5ZKOMEYo9d95PQJbDONRDKG842Mu3Zk" width="624" height="375" style="margin-left:0px;margin-top:0px;"> Полезные ссылки: <a href="https://www.youtube.com/watch?v=goaZTAzsLMk" target="_blank" style="font-size: 14px;">Software testing /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=FS_TuKTsYOg" target="_blank" style="font-size: 14px;">QA engineering /video tutorial/arm</a><a href="https://www.guru99.com/all-about-quality-assurance.html" target="_blank" style="font-size: 14px;">Quality assurence /article/eng</a>

Что такое обеспечение качества и зачем оно нам?

Обеспечения качества

<h3>Что такое тестирование программного обеспечения?</h3> Тестирование программного обеспечения — это метод проверки соответствия фактического программного продукта ожидаемым требованиям и обеспечения отсутствия дефектов в программном продукте. Он включает в себя выполнение компонентов программного обеспечения/системы с использованием ручных или автоматизированных инструментов для оценки одного или нескольких интересующих свойств. Целью тестирования программного обеспечения является выявление ошибок, пробелов или отсутствующих требований в отличие от фактических требований. <h3>Почему так важно тестирование программного обеспечения?</h3> Тестирование программного обеспечения важно, потому что если в программном обеспечении есть какие-либо ошибки или ошибки, они могут быть обнаружены на раннем этапе и могут быть устранены до поставки программного продукта. Правильно протестированный программный продукт обеспечивает надежность, безопасность и высокую производительность, что в дальнейшем приводит к экономии времени, рентабельности и удовлетворенности клиентов. Тестирование важно, потому что ошибки в программном обеспечении могут быть дорогими или даже опасными. Ошибки в программном обеспечении потенциально могут привести к финансовым потерям и человеческим жертвам, и история полна таких примеров. В апреле 2015 года терминал Bloomberg в Лондоне вышел из строя из-за сбоя программного обеспечения, затронувшего более 300 000 трейдеров финансовых рынков. Это вынудило правительство отложить продажу долга на сумму 3 миллиарда фунтов стерлингов. Автомобили Nissan отозвали с рынка более 1 млн автомобилей из-за программного сбоя в сенсорных детекторах подушек безопасности. Сообщалось о двух несчастных случаях из-за этого программного сбоя. Starbucks была вынуждена закрыть около 60 процентов магазинов в США и Канаде из-за сбоя программного обеспечения в ее POS-системе. В какой-то момент магазин подал кофе бесплатно, поскольку не смог обработать транзакцию. Некоторые сторонние розничные продавцы Amazon столкнулись с тем, что цена на их продукцию снижена до 1 пенса из-за сбоя в программном обеспечении. Они остались с большими потерями. Уязвимость в Windows 10. Эта ошибка позволяет пользователям выйти из изолированной программной среды безопасности через брешь в системе win32k. В 2015 году истребитель F-35 стал жертвой программной ошибки, из-за которой он не смог правильно обнаруживать цели. Airbus A300 авиакомпании China Airlines разбился из-за ошибки в программном обеспечении 26 апреля 1994 года, в результате чего погибли 264 невинных человека. В 1985 году канадский аппарат лучевой терапии Therac-25 вышел из строя из-за ошибки в программном обеспечении и доставил пациентам смертельные дозы радиации, в результате чего 3 человека погибли и еще 3 получили серьезные ранения. В апреле 1999 года программная ошибка привела к провалу запуска военного спутника стоимостью 1,2 миллиарда долларов, что стало самой дорогостоящей аварией в истории. В мае 1996 года из-за программной ошибки на банковские счета 823 клиентов крупного банка США было зачислено 920 миллионов долларов США. <h3 style="text-align: justify;">Методы тестирования программного обеспечения</h3><h3 style="text-align: justify;"> </h3>Положительное тестирование. В этом типе тестирования путем ввода достоверных данных проверяется, работает ли приложение должным образом или нет. Например: Существует текстовое поле, которое принимает только числа до 99999, все остальные значения. не принимаются. Тестирование будет положительным, если мы примем в качестве входных значений 0-99999 чисел и проверьте, принимает ли система эти значения или нет. Отрицательное тестирование. В этом типе тестирования путем ввода неверных данных проверяется, делает ли приложение что-то запрещенное. Например: В текстовом поле предыдущего примера возьмем A-Z, a-z в качестве входных значений. символы, приложение должно либо не принять, либо выдать сообщение об ошибке. <h3>Техника положительного и отрицательного тестирования</h3> Анализ граничных значений. В этом случае проверяются только граничные значения. При этом, если введенные данные находятся в пределах граничных значений – это Положительное тестирование, а если вне – это Отрицательное тестирование. Например: Текстовое поле принимает только значения 0–10, все остальные числа недействительны. Будут проверены значения края -1, 0, 1 и 9, 10, 11. Эквивалентное разделение – в этом случае входные данные делятся на части, каждая часть должна быть проверена хотя бы один раз. действительные значения используются для положительного тестирования, недопустимые значения — для отрицательного тестирования. В предыдущем примере мы делим входные данные на 2 (или 3) части: например от -10 до 0 и от 0 до 10. Для проверки берем 5 (Положительное тестирование), -5 (Отрицательное тестирование). Полезные ссылки:<a href="https://www.youtube.com/watch?v=goaZTAzsLMk" target="_blank">Software testing /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=Xx1lRYj_NsY&amp;list=PLRs8EELOYKc7DYIQixlV1s4EH5SR3TdNB" target="_blank">Software testing /video tutorial/rus</a><a href="https://www.guru99.com/software-testing.html" target="_blank">Software testing /article/eng</a><a href="https://www.guru99.com/software-testing-introduction-importance.html" target="_blank">Software testing /article/eng</a>

Роль тестирования программного обеспечения в ИТ.

Тестирование программного обеспечения

<h3>7 принципов тестирования программного обеспечения</h3> 1. Тестирование показывает наличие дефектов 2. Полное тестирование невозможно 3. Раннее тестирование 4. Кластеризация дефектов 5. Парадокс пестицидов 6. Тестирование зависит от контекста 7. Отсутствие ошибок <h3>Тестирование показывает наличие дефектов</h3> Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет. <h3>Исчерпывающее тестирование невозможно</h3> Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО. <h3>Раннее тестирование</h3> Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения, и его усилия должны быть сконцентрированы на определенных целях. <h3>Скопление дефектов</h3> Разные модули системы могут содержать разное количество дефектов – то есть, плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей. <h3>Парадокс пестицида</h3> Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают. Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов. <h3>Тестирование зависит от контекста</h3> Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений, сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки. <h3>Заблуждение об отсутствии ошибок</h3> Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к релизу. Нахождение и исправление дефектов будут не важны, если система окажется неудобной в использовании, и не будет удовлетворять ожиданиям и потребностям пользователя. И еще несколько важных принципов: <ul><li>тестирование должно производиться независимыми специалистами;</li><li>привлекайте лучших профессионалов;</li><li>тестируйте как позитивные, так и негативные сценарии;</li><li>не допускайте изменений в программе в процессе тестирования;</li><li>указывайте ожидаемый результат выполнения тестов</li></ul> Полезные ссылки:<a href="https://www.youtube.com/watch?v=rFaWOw8bIMM" target="_blank">7 Principles of Software Testing /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=XDiVs2-Ggz4" target="_blank">Software Testing Principles /video tutorial/rus</a><a href="https://www.youtube.com/watch?v=YvbcTFlJMhc" target="_blank">Software Testing Principles /video tutorial/rus</a><a href="https://www.guru99.com/software-testing-seven-principles.html" target="_blank">7 Principles of Software Testing /article/eng</a><a href="https://www.softwaretestingmaterial.com/principles-of-software-testing-2/" target="_blank">7 Principles of Software Testing /article/eng</a>

7 принципов тестирования программного обеспечения

Что такое жизненный цикл разработки программного обеспечения?

SDLC

<h3>Что такое жизненный цикл разработки программного обеспечения?</h3> Жизненный цикл тестирования заключается в следующих этапах: <ol><li>Планирование и анализ требований</li><li>Уточнение критериев приемки</li><li>Уточнение стратегии тестирования</li><li>Разработка тестовой документации</li><li>Выполнение тест-кейсов и Фиксация найденных дефектов</li><li>Анализ результатов тестирования и Отчетность</li></ol> <h3>Планирование и анализ требований</h3> Фаза тестирования требований, также известная как анализ требований, в ходе которой группа тестирования изучает требования с точки зрения тестирования, чтобы определить проверяемые требования, а группа контроля качества может взаимодействовать с различными заинтересованными сторонами для детального понимания требований. Требования могут быть функциональными или нефункциональными. На этом этапе также выполняется технико-экономическое обоснование проекта тестирования. Действия на этапе тестирования требований Определить типы тестов, которые необходимо выполнить. Соберите подробную информацию о приоритетах и фокусе тестирования. Подготовьте матрицу отслеживания требований (RTM). Определите детали тестовой среды, в которой предполагается проводить тестирование. Анализ возможности автоматизации (при необходимости). Результаты этапа тестирования требований 1.РТМ 2.Технико-экономическое обоснование автоматизации. (если это применимо) <h3>Планирование тестирования</h3> Планирование тестирования в STLC — это этап, на котором старший менеджер по обеспечению качества определяет стратегию плана тестирования, а также усилия и смету затрат на проект. Кроме того, также определяются ресурсы, тестовая среда, ограничения тестирования и график тестирования. План тестирования готовится и утверждается на том же этапе. Деятельность по планированию тестирования Подготовка плана/стратегии тестирования для различных типов тестирования. Выбор тестового инструмента Оценка усилий по тестированию Планирование ресурсов и определение ролей и обязанностей. Требование к обучению Результаты планирования тестирования 1.План тестирования/документ стратегии. 2.Документ об оценке усилий. <h3>Разработка тестового примера</h3> Фаза разработки тестовых примеров включает в себя создание, проверку и доработку тестовых примеров и тестовых сценариев после того, как план тестирования готов. Первоначально тестовые данные идентифицируются, затем создаются и проверяются, а затем перерабатываются на основе предварительных условий. Затем команда контроля качества начинает процесс разработки тест-кейсов для отдельных модулей. Действия по разработке тестовых примеров Создание тест-кейсов, сценариев автоматизации (если применимо) Обзор и базовые тестовые сценарии и сценарии Создайте тестовые данные (если доступна тестовая среда) Результаты разработки тест-кейса Тестовые случаи/скрипты Данные испытаний <h3>Настройка тестовой среды</h3> Настройка тестовой среды определяет условия программного и аппаратного обеспечения, при которых тестируется рабочий продукт. Это один из важнейших аспектов процесса тестирования, который можно выполнять параллельно с этапом разработки тестового сценария. Группа тестирования не может участвовать в этой деятельности, если группа разработчиков предоставляет тестовую среду. Группа тестирования обязана провести проверку готовности (дымовое тестирование) данной среды. Действия по настройке тестовой среды Изучите необходимую архитектуру, настройку среды и подготовьте список требований к оборудованию и программному обеспечению для тестовой среды. Настройка тестовой среды и тестовые данные Выполните дымовое тестирование сборки Результаты настройки тестовой среды Готовая среда с настройкой тестовых данных Результаты испытаний на дым. <h3>Завершение испытательного цикла</h3> Действия по завершению тестового цикла Оцените критерии завершения цикла на основе времени, тестового покрытия, стоимости, программного обеспечения, критических бизнес-целей и качества. Подготовьте тестовые метрики на основе вышеуказанных параметров. Документируйте результаты обучения в рамках проекта Подготовить отчет о завершении теста Качественная и количественная отчетность о качестве рабочего продукта перед заказчиком. Анализ результатов тестирования для определения распределения дефектов по типам и серьезности. Результаты завершения испытательного цикла Отчет о завершении теста Тестовые метрики Полезные ссылки:<a href="https://www.youtube.com/watch?v=_3OhZrad8RM" target="_blank" style="font-size: 14px;">STLC /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=HylDB3bN6hQ" target="_blank" style="font-size: 14px;">STLC /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=An7HC1LolDM" target="_blank" style="font-size: 14px;">SDLC vs STLC /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=ZoOX8Q92zqc" target="_blank" style="font-size: 14px;">STLC /video tutorial/rus</a><a href="https://www.guru99.com/software-testing-life-cycle.html" target="_blank" style="font-size: 14px;">STLC /article/eng</a><a href="https://ru.education-wiki.com/5141467-sdlc-vs-stlc" target="_blank" style="font-size: 14px;">SDLC vs STLC /article/rus</a>

STLC

<h3>Верификация</h3> Верификация (Verification) — это статическая практика проверки документов, дизайна, архитектуры, кода, т.д. <ul><li>Верификация — это процесс включающий в себя проверку Plans, Requirement Specifications, Design Specifications, Code, Test Cases, Chek-Lists, etc.</li><li>Верификация всегда проходит без запуска кода.</li><li>Верификация использует методы — reviews, walkthroughs, inspections, etc.</li><li>Верификация отвечает на вопрос “Делаем ли мы продукт правильно?”</li><li>Верификация поможет определить, является ли программное обеспечение высокого качества, но оно не гарантирует, что система полезна. Проверка связана с тем, что система хорошо спроектирована и безошибочно.</li><li>Верификация происходит до Validation.</li></ul> <h3>Валидация</h3> Валидация (validation) – это процесс оценки конечного продукта, необходимо проверить, соответствует ли программное обеспечение ожиданиям и требованиям клиента. Это динамический механизм проверки и тестирования фактического продукта. <ul><li>Валидация всегда включает в себя запуск кода программы.</li><li>Валидация использует методы, такие как тестирование Black Box, тестирование White Box и нефункциональное тестирование.</li><li>Валидация отвечает на вопрос “Делаем ли мы правильный продукт?”</li><li>Валидация проверяет, соответствует ли программное обеспечение требованиям и ожиданиям клиента.</li><li>Валидация может найти ошибки, которые процесс Verification не может поймать.</li><li>Валидация происходит после Verification.</li></ul> На практике, отличия верификации и валидации имеют большое значение: заказчика интересует в большей степени валидация (удовлетворение собственных требований); исполнителя, в свою очередь, волнует не только соблюдение всех норм качества (верификация) при реализации продукта, а и соответствие всех особенностей продукта желаниям заказчика. <h3>Верификация vs Валидация</h3> <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Верификация </td>
o<td style="width: 50%; text-align: center;">Валидация </td></tr>
<tr>
o<td style="width: 50%;">По факту отвечает на вопрос, правильно ли создается и тестируется ПО и все ли требования учитываются при этом. </td>
o<td style="width: 50%;">Отвечает на вопрос, создается ли продукт правильно с точки зрения ожиданий клиента. </td></tr>
<tr>
o<td style="width: 50%;">В процессе верификации убеждаемся в том, что весь созданный функционал приложения работает корректно и логически верно. </td>
o<td style="width: 50%;">При процессе валидации убеждаемся в том, что продукт полностью соответствует поведению, которое от него ожидается и то, что клиент знает о наличии подобного функционала․ </td></tr>
<tr>
o<td style="width: 50%;">В структуру верификации входят такие компоненты, как сверка завалидированным требованиям, технической документации и корректное выполнения программного кода на любом этапе создания и тестирования ПО. </td>
o<td style="width: 50%;">Валидация, по своей сути, в большей степени включает в себя общую оценку ПО и может основываться исключительно на субъективном мнении касательно правильности работы приложения или его компонентов. </td></tr>
<tr>
o<td style="width: 50%;">Соответствует ли программное обеспечение спецификация проверена. </td>
o<td style="width: 50%;">Проверяет, соответствует ли программное обеспечение требованиям и ожиданиям заказчика. </td></tr>
<tr>
o<td style="width: 50%;">Он находит ошибки на ранних этапах цикла разработки. </td>
o<td style="width: 50%;">Он может находить ошибки, которые не может обнаружить процесс проверки. </td></tr>
<tr>
o<td style="width: 50%;">Целью является приложение и программное обеспечение. архитектура, спецификация, полный дизайн, высокий уровень, проектирование базы данных и т. д. </td>
o<td style="width: 50%;">Цель&nbsp;– реальный продукт. </td></tr>
<tr>
o<td style="width: 50%;">Команда контроля качества проводит проверку и следит за тем, чтобы программное обеспечение соответствовало требованиям. в документе СГД. </td>
o<td style="width: 50%;">С привлечением группы тестирования выполняется валидация программного кода. </td></tr><tr>
o<td style="width: 50%;">Это происходит до валидации. </td>
o<td style="width: 50%;">Это происходит после верификации. </td></tr></tbody></table> Полезные ссылки:<a href="https://www.guru99.com/verification-v-s-validation-in-a-software-testing.html" target="_blank" style="font-size: 14px;">Validation vs Verification /article/eng</a><a href="https://testmatick.com/ru/validatsiya-i-verifikatsiya-ponyatiya-shodstva-i-otlichiya/" target="_blank">Validation vs Verification /article/rus</a><a href="https://www.youtube.com/watch?v=qxitgylm1EU" target="_blank">Validation vs Verification /video tutorial/eng</a>

В чем разница между Верификацией и Валидацией?

Верификация и валидация

<h3>Модульное тестирование</h3> Модульное тестирование (Unit testing) – тестирование каждой атомарной функциональности приложения отдельно, в искусственно созданной среде. Именно потребность в создании искусственной рабочей среды для определенного модуля, требует от тестировщика знаний в автоматизации тестирования программного обеспечения, некоторых навыков программирования. Данная среда для некоторого юнита создается с помощью драйверов и заглушек. Объект тестирования выделен красным цветом. Драйвер – определенный модуль теста, который выполняют тестируемый нами элемент. Заглушка – часть программы, которая симулирует обмен данными с тестируемым компонентом, выполняет имитацию рабочей системы. Заглушки нужны для: Имитирования недостающих компонентов для работы данного элемента. Подачи или возвращения модулю определенного значения, возможность предоставить тестеру самому ввести нужное значение. Воссоздания определенных ситуаций (исключения или другие нестандартные условия работы элемента). Рассмотрим преимущества модульного тестирования. Прежде всего, нужно очертить рамки, в которых Юнит-тестирование оправданно. Во-первых, архитектура проекта должна быть спроектирована в соответствии с идеями ООП (четкое деление на классы, каждый из которых выполняет свою определенную функцию), что обеспечит систему грамотным делением на модули. Также, модульное тестирование должно быть менее затратным при поиске дефектов, чем другие виды тестов и должно снижать время отладки кода. Что же касается непосредственно преимуществ: Модульное тестирование мотивирует программистов писать код максимально оптимизированным, проводить рефакторинг (упрощение кода программы, не затрагивая ее функциональность), так как с помощью Юнит-тестирования можно легко проверить работоспособность рассматриваемого компонента. Необходимость отделения реализации от интерфейса (ввиду особенностей модульного тестирования), что позволяет минимизировать зависимости в системе. Документация Юнит-тестов может служить примером «живого документа» для каждого класса, тестируемого данным способом. Модульное тестирование помогает лучше понять роль каждого класса на фоне всей программной системы. Также, при «разработке через тестирование», которая активно используется в экстремальном программировании, модульное тестирования является одним из основных инструментов, позволяющий разрабатывать модули в соответствии с требованиями к данному модулю. Естественно, получив реальный опыт работы инженером качества, Вы сможете совсем по-другому охарактеризовать данный вид тестирования. А пока, надеюсь, данная статья поможет Вам подойти на шаг ближе к возможности получения реального опыта. Полезные ссылки:<a href="https://www.guru99.com/levels-of-testing.html" target="_blank" style="font-size: 14px;">Levels of testing /article/eng</a><a href="https://www.guru99.com/unit-testing-guide.html" target="_blank" style="font-size: 14px;">Unit testing /article/eng</a><a href="https://logrocon.ru/news/unit_testing" target="_blank" style="font-size: 14px;">Unit testing /article/rus</a><a href="https://www.youtube.com/watch?v=lj5nnGa_DIw" target="_blank" style="font-size: 14px;">Unit testing /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=0WtTd2fWaTE" target="_blank" style="font-size: 14px;">Unit testing /video tutorial/arm</a>

Что такое модульное тестирование и как оно проводится?

Модульное тестирование

<h3>Интеграционное тестирование</h3> Исходя из различий между модульным тестированием и системным тестированием, интеграционное тестирование является переходным этапом между представлением программы в виде отдельных модулей в вид полностью функциональной системы. Интеграционное тестирование – вид тестирования, при котором на соответствие требований проверяется интеграция модулей, их взаимодействие между собой, а также интеграция подсистем в одну общую систему. Для интеграционного тестирования используются компоненты, уже проверенные с помощью модульного тестирования, которые группируются в множества. Данные множества проверяются в соответствии с планом тестирования, составленным для них, а объединяются они через свои интерфейсы. Так как модули соединяются между собой с помощью предусмотренных реализацией интерфейсов и в процессе тестирования у нас нет потребности рассматривать внутреннюю структуру компонентов, можно утверждать, что интеграционное тестирование выполняется методом «черного ящика». Объект тестирования выделен красным цветом. Существует несколько подходов к интеграционному тестированию: <ul><li>Снизу вверх. Сначала собираются и тестируются модули самих нижних уровней, а затем по возрастанию к вершине иерархии. Данный подход требует готовности всех собираемых модулей на всех уровнях системы.</li><li>Сверху вниз. Данный подход предусматривает движение с высокоуровневых модулей, а затем направляется вниз. При этом используются заглушки для тех модулей, которые находятся ниже по уровню, но включение которых в тест еще не произошло.</li><li>Большой взрыв. Все модули всех уровней собираются воедино, а затем тестируется. Данный метод экономит время, но требует тщательной проработки тест кейсов.</li></ul> При автоматизации тестирования используется Система непрерывной интеграции. Принцип ее действия заключается в следующем: <ol><li>Система непрерывной интеграции производит мониторинг системы контроля версий.</li><li>При изменении исходных кодов в репозитории производится обновление локального хранилища.</li><li>Выполняются необходимые проверки и модульные тесты.</li><li>Исходные коды компилируются в готовые выполняемые модули.</li><li>Выполняются тесты интеграционного уровня.</li><li>Генерируется отчет о тестировании.</li></ol> Это позволяет тестировать систему сразу после внесения изменений, что существенно сокращает время обнаружения и исправления ошибок. Полезные ссылки:<a href="https://www.guru99.com/integration-testing.html" target="_blank">Integration testing /article/eng</a><a href="https://u-tor.com/topic/integration-testing" target="_blank">Integration testing /article/eng</a><a href="https://logrocon.ru/news/intgration_testing" target="_blank">Integration testing /article/rus</a><a href="https://www.youtube.com/watch?v=cQ39AwhjxH8" target="_blank">Testing levels /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=QYCaaNz8emY" target="_blank">Integration testing /video tutorial/eng</a>

Что такое интеграционное тестирование и как оно проводится?

Интеграционное тестирование

<h3>Системное тестирование</h3> Системное тестирование – это тестирование программного обеспечения выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям, как функциональным, так и не функциональным. Объект тестирования выделен красным цветом. Выполняя системное тестирование, можно обнаружить следующие типы дефектов: <ul><li>Неправильное использование системных ресурсов.</li><li>Непредусмотренные комбинации пользовательских данных.</li><li>Проблемы с совместимостью окружения.</li><li>Непредусмотренные сценарии использования.</li><li>Несоответствие с функциональными требованиями.</li><li>Плохое удобство использования.</li></ul> Системное тестирование выполняется методом «Черного ящика», т.к. проверяемое множество является «внешними» сущностями, которые не требуют взаимодействия с внутренним устройством программы. Также выполнять его рекомендуется в окружении, максимально приближенном к окружению конечного пользователя. Можно выделить 2 подхода к системному тестированию: <ol><li>На базе требований. Тестирование проводится в соответствии с функциональными или нефункциональными требованиями, для каждого из которых пишется testcase (тестовые прецеденты).</li><li>На базе случаев использования. Тестирование происходит в соответствии с вариантами использования продукта, на основе которых создаются usercases (пользовательские прецеденты). Для каждого из данных пользовательских прецедентов создаются свои тестовые прецеденты.</li></ol> Также к системному тестированию можно отнести альфа-тестирование и бета-тестирование, суть которых мы рассмотрим в следующих статьях. Полезные ссылки:<a href="https://www.guru99.com/system-testing.html" target="_blank">System testing /article/eng</a><a href="https://www.xenonstack.com/insights/what-is-system-testing" target="_blank">System testing /article/eng</a><a href="https://beqa.pro/blog/testing-levels/" target="_blank">Testing levels /article/rus</a><a href="https://www.youtube.com/watch?v=t-1Cw2e7PYc" target="_blank">System testing /video tutorial/rus</a>

Что такое системное тестирование и как оно проводится?

Системное тестирование

<h3>Приемочное тестирование</h3> Приемочное (acceptance) – вид тестирования, проводимый на этапе сдачи готового продукта (или готовой части продукта) заказчику. Целью приемочного тестирования является определение готовности продукта, что достигается путем прохода тестовых сценариев и случаев, которые построены на основе спецификации требований к разрабатываемому ПО. Результатом приемочного тестирования может стать: <ul><li>Отправка проекта на доработку.</li><li>Принятие его заказчиком, в качестве выполненной задачи.</li></ul> Это финальный этап тестирования продукта перед его релизом. При этом, он не является сверх тщательным, всеохватывающим и полным – тестируется, в основном, только основной функционал. Приемочное тестирование проводиться либо самим заказчиком, либо группой тестировщиков, представляющих интересы заказчика, либо тестировщиками компании-разработчика. Зависит от предпочтений компании-заказчика. <h3>Альфа-тестирование</h3> Альфа-тестирование (alpha testing) – это вид приемочного тестирования, которое обычно проводится на поздней стадии разработки продукта и включает имитацию реального использования продукта штатными разработчиками либо командой тестировщиков. Обычно альфа тестирование заключается в систематической проверке всех функций программы с использованием техник тестирования «белого ящика» и «черного ящика». Преимущества альфа-тестирования: <ul><li>Обеспечивает лучшее представление о надежности программного обеспечения на ранней стадии.</li><li>Помогает моделировать поведение пользователя и окружающую среду в режиме реального времени.</li><li>Обнаруживает много серьезных ошибок.</li><li>Дает возможность раннего обнаружения ошибок в отношении дизайна и функциональности.</li></ul> Недостатки альфа-тестирования: <ul><li>Функциональность не может быть проверена на всю глубину, поскольку программное обеспечение все еще находится на стадии разработки. Иногда разработчики и тестировщики недовольны результатами альфа-тестирования.</li></ul> <h3>Бета-тестирование</h3> Бета-тестирование (beta testing) – интенсивное использование почти готовой версии продукта с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю. Бета-тестирование представляет собой реально работающую версию программы с полным функционалом. И задача бета-тестов – оценить возможности и стабильность работы программы с точки зрения ее будущих пользователей. В отличие от альфа-тестирования, проводимого силами штатных разработчиков или тестировщиков, бета-тестирование предполагает привлечение добровольцев из числа обычных будущих пользователей продукта, которым доступна упомянутая предварительная версия продукта (так называемая бета-версия). Такими добровольцами (их называют бета-тестерами) часто движет любопытство к новому продукту – любопытство, ради удовлетворения которого они вполне согласны мириться с возможностью испытать последствия еще не найденных (а потому и не исправленных) ошибок. Кроме любопытства, мотивация может быть обусловлена желанием повлиять на процесс разработки и в итоге получать более удовлетворяющий их нужды продукт и многим другим. Очень хорошо, если это люди, которые уже имеют опыт работы с программами такого типа, а еще лучше – с предыдущей версией этой же программы. Обычно у компаний уже есть определенный круг лиц, с которыми они постоянно сотрудничают. Бета-тестирование может быть: <ul><li>Закрытым: Программа тестируется в небольшой группе пользователей по приглашениям.</li><li>Открытым: Этот вариант позволяет протестировать приложение в большей группе и получить большой объем обратной связи. Любой пользователь сможет присоединиться к открытому бета-тестированию и отправить личный отзыв.</li></ul> Открытое бета-тестирования, например, может использоваться как часть стратегии продвижения продукта на рынок (например, бесплатная раздача бета-версий позволяет привлечь широкое внимание потребителей к окончательной дорогостоящей версии продукта), а также для получения предварительных отзывов о нём от широкого круга будущих пользователей. Надо сказать, что разработчики не испытывают недостатка в желающих принять участие в такой работе. Такого рода сотрудничество приносит пользу обеим сторонам, ведь исправления проще сделать в процессе работы, а не когда она уже завершена, к тому же замечания и пожелания пользователей позволяют сделать программное обеспечение лучше и качественней. Преимущества бета-тестирования: <ul><li>Снижает риск выхода продукта из строя посредством валидации клиента.</li><li>Бета-тестирование позволяет компании тестировать инфраструктуру после запуска.</li><li>Повышает качество продукции благодаря обратной связи с клиентами.</li><li>Является экономичным методом сбора данных по сравнению с аналогичными методами.</li><li>Создает доброжелательность с клиентами и повышает удовлетворенность клиентов.</li></ul> Недостатки бета-тестирования: <ul><li>Управление тестированием – проблема. По сравнению с другими типами тестирования, которые обычно выполняются внутри компании в контролируемой среде, бета-тестирование выполняется в реальном мире, где у компании редко есть контроль.</li><li>Поиск правильных пользователей бета-версии и поддержание их участия может вызвать трудности.</li></ul> Полезные ссылки:<a href="https://www.guru99.com/user-acceptance-testing.html" target="_blank">User acceptance testing /article/eng</a><a href="https://www.istqb.org/certifications/acceptance-tester" target="_blank">Acceptance testing /article/eng</a><a href="https://www.calltouch.ru/blog/glossary/uat-testirovanie/" target="_blank">Acceptance testing /article/rus</a><a href="https://www.youtube.com/watch?v=JDD5EEJgpHU" target="_blank">Writing acceptance tests /video tutorial/eng</a><a href="https://www.youtube.com/watch?v=uhkREQbRl-k" target="_blank">Acceptance testing /video tutorial/rus</a>

Что такое приемочное тестирование и как оно проводится?

Приемочное тестирование

<h3>Метод белого ящика</h3> Тестирование белого ящика — это метод тестирования программного обеспечения, при котором внутренняя структура, дизайн и кодирование программного обеспечения проверяются для проверки потока ввода-вывода и улучшения дизайна, удобства использования и безопасности. При тестировании белого ящика код виден тестировщикам, поэтому его также называют тестированием прозрачного ящика, тестированием открытого ящика, тестированием прозрачного ящика, тестированием на основе кода и тестированием стеклянного ящика. Это одна из двух частей подхода Box Testing к тестированию программного обеспечения. Его аналог, тестирование Blackbox, предполагает тестирование с точки зрения внешнего или конечного пользователя. С другой стороны, тестирование белого ящика в разработке программного обеспечения основано на внутренней работе приложения и вращается вокруг внутреннего тестирования. Термин «WhiteBox» использовался из-за концепции прозрачной коробки. Прозрачное окно или название WhiteBox символизирует возможность видеть сквозь внешнюю оболочку программного обеспечения (или «коробку») его внутреннюю работу. Аналогичным образом, «черный ящик» в «Тестировании черного ящика» символизирует невозможность увидеть внутреннюю работу программного обеспечения, поэтому можно протестировать только опыт конечного пользователя. Полезные ссылки:<a href="https://www.guru99.com/white-box-testing.html" target="_blank">White-box testing article/eng</a><a href="https://www.mend.io/resources/blog/white-box-testing/" target="_blank">White-box testing article/eng</a><a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/testirovanie-belogo-iashchika" target="_blank">White-box testing article/rus</a><a href="https://www.youtube.com/watch?v=a-nn_lXf1uA" target="_blank">White-box testing video tutorial/eng</a><a href="https://www.youtube.com/watch?v=AqoMSfErDSE" target="_blank">White,Black and Gray box testing video tutorial/rus</a>

Что такое тестирование белого ящика и как его проводить?

Метод белого ящика

<h3>Метод черного ящика</h3>Тестирование
черного ящика — это метод тестирования программного обеспечения, при котором
функциональность программных приложений тестируется без знания внутренней
структуры кода, деталей реализации и внутренних путей. Тестирование черного
ящика в основном фокусируется на вводе и выводе программных приложений и
полностью основано на требованиях и спецификациях программного обеспечения. Он также известен как поведенческое
тестирование.<img src="https://lh5.googleusercontent.com/BF1GkBhK3QsDQYJn0s_ajSvJ13kZxF4xQktFWfy46Vanm_6k_lfvSHU7nApNI6QKX3uQgc6HJG81i1hZKOo3CS9EwfFcx7wpyuh25g9YnLEZkidv9fVdrj-NK28WIp53evMMXQkHRgymiiTRlQVLfWo" width="624" height="152" style="margin-left:0px;margin-top:0px;">Вышеупомянутый черный ящик может представлять собой любую программную систему, которую вы хотите протестировать. Например, операционная система, такая как Windows, веб-сайт, такой как Google, база данных, такая как Oracle, или даже ваше собственное приложение. В рамках «Тестирования черного ящика» вы можете протестировать эти приложения, просто сосредоточившись на входных и выходных данных, не зная реализации их внутреннего кода. Полезные ссылки:<a href="https://www.guru99.com/black-box-testing.html" target="_blank">Black-box testing article/eng</a><a href="https://www.imperva.com/learn/application-security/black-box-testing/" target="_blank">Black-box testing article/eng</a><a href="https://quality-lab.ru/blog/key-principles-of-black-box-testing/" target="_blank">Black-box testing article/rus</a><a href="https://www.youtube.com/watch?v=O7j3tBXO23M" target="_blank">Black-box vs White-box testing video tutorial/eng</a><a href="https://www.youtube.com/watch?v=joTjpiohrQw" target="_blank">Black-box testing video tutorial/rus</a>

Что такое тестирование черного ящика и как его проводить?

Метод черного ящика

<h3>Метод серого ящика</h3> Тестирование методом серого ящика – метод тестирования программного обеспечения, который предполагает, комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично. Предполагается, например, доступ к внутренней структуре и алгоритмам работы ПО для написания максимально эффективных тест-кейсов, но само тестирование проводится с помощью техники черного ящика, то есть, с позиции пользователя. Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет. <img src="https://lh6.googleusercontent.com/GQqrgFt4THJtgs22YO9VjqpNZgHjCWv6bqNSSOOHGtrO7nZ-L4p_LsRyFLY1UqS64VTm8wEDRttErPdjISjPVOpm-VI8ZzvgnnQLzHXWqcnp8E3Z11QGEG3t0fqDjoymuZh0-40mfjp8B3MqCRQw3RY" width="624" height="217" style="margin-left:0px;margin-top:0px;">Пример: Тестировщик изучает код программы с тем, чтобы лучше понимать принципы ее работы и изучить возможные пути ее выполнения. Такое знание поможет написать тест-кейс, который наверняка будет проверять определенную функциональность. Техника серого ящика применима на разных уровнях тестирования – от модульного до системного, но главным образом применяется на интеграционном уровне для проверки взаимодействия разных модулей программы. Полезные ссылки:<a href="https://www.guru99.com/grey-box-testing.html" target="_blank">Gray-box testing article/eng</a><a href="https://www.mend.io/resources/blog/gray-box-testing/" target="_blank">Gray-box testing article/eng</a><a href="https://ru.education-wiki.com/7781700-gray-box-testing" target="_blank">Gray-box testing article/rus</a><a href="https://www.youtube.com/watch?v=x-tNXvvz_KA" target="_blank">Gray-box testing video tutorial/rus</a><a href="https://www.youtube.com/watch?v=VD5tOODUOzs" target="_blank">Gray-box testing video tutorial/eng</a>

Что такое тестирование серого ящика и как оно проводится?

Метод серого ящика

<h3>Визуальный метод</h3> Такие визуальные детали, как шрифты, цвета, выравнивание и изображения, нужны не просто для удобства использования сайта, но и для выражения характерных черт бренда, например, дружелюбия, надёжности или инновационности. Многие команды сначала определяют характерные черты, затем дизайнеры и акционеры выбирают подходящие визуальные детали. Такой подход предполагает, что мнение дизайнеров и акционеров точно предскажет отклик пользователей. Это хороший ход, но нет гарантии, что то, что дизайнеру кажется «дружелюбием», будет тем же для пользователя. Компания может многое получить от эффективного брендинга, поэтому визуальную эстетику и её влияние на пользователей нужно оценивать тщательно, основываясь на данных исследований. <h3 style="text-align: justify;">Как тестировать восприятие визуального дизайна</h3> Как и в любом другом UX-исследовании, наберите участников из вашей целевой аудитории. Им необязательно иметь специальные знания в области дизайна — людям не нужна профессиональная подготовка, чтобы понять, что им что-то нравится. Согласно исследованию Гитте Линдегаард и её коллег, пользователям достаточно десяти секунд, чтобы оценить дизайн. Но если дизайн кому-то нравится, это ещё не значит, что он правильно передаёт черты бренда. Ни вы, ни члены команды, ни руководящий состав не являетесь пользователем продукта. Недостаточно просто спрашивать пользователей, нравится им дизайн или нет. Нужен более структурированный подход, который можно разделить на две основные части: <ul><li>Знакомство с визуальным стимулом: покажите участникам исследования дизайн. Это может быть картинка, прототип, живой интерактивный сайт или приложение.</li><li>Оценка реакции пользователя на этот стимул: измерьте реакции на дизайн с помощью открытых или строго контролируемых вопросов.</li></ul> Полезные ссылки:<a href="https://www.guru99.com/gui-testing.html" target="_blank">GUI testing article/eng</a><a href="https://www.browserstack.com/guide/visual-testing-beginners-guide" target="_blank">Visual testing article/eng</a><a href="https://www.youtube.com/watch?v=crbwyGlcXm0" target="_blank">Visual testing video tutorial/rus</a>

Что такое визуальное тестирование и как оно проводится?

Визуальный метод

<h3>Ad-Hoc метод</h3> Свободное тестирование (ad-hoc testing) – это вид тестирования, который выполняется без подготовки к тестированию продукта, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Оно не требует никакой документации, планирования, процессов, которых следует придерживаться при выполнении тестирования. Такой способ тестирования в большинстве случаев дает большее количество заведенных отчётов об ошибке. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основной функциональной части продукта и выполняет как позитивные, так и негативные варианты возможных сценариев. Чаще всего такое тестирование выполняется, когда владелец продукта не обладает конкретными целями, проектной документацией и ранее поставленными задачами. При этом тестировщик полагается на свое общее представление о продукте, сравнение с похожими продуктами, собственный опыт. Однако при тестировании ad-hoc имеет смысл владеть общей информацией о продукте, особенно если проект очень сложный и большой. Поэтому нужно хорошее представление о целях проекта, его назначении и основных функциях и возможностях. А дальше уже можно приступать к ad-hoc тестированию. Виды свободного тестирования (ad-hoc testing): Buddy testing – процесс, когда 2 человека, как правило разработчик и тестировщик, работают параллельно и находят дефекты в одном и том же модуле тестируемого продукта. Такой вид тестирования помогает тестировщику выполнять необходимые проверки, а разработчику исправлять множество дефектов на ранних этапах.Pair testing – процесс, когда 2 тестировщика проверяют один модуль и помогают друг другу. К примеру, один может искать дефекты, а второй их документировать. Таким образом, у одного тестера будет функция, скажем так, обнаружителя, у другого – описателя.Monkey testing – произвольное тестирование продукта с целью как можно быстрее, используя различные вариации входных данных, нарушить работу программы или вызвать ее остановку (простыми словами – сломать). Различия между Buddy testing и Pair testing:Buddy testing (Совместное тестирование) – это сочетание модульного тестирования и системного тестирования между разработчиком и тестировщиком.Pair testing (Парное тестирование) – выполняется только тестировщиками с разным уровнем знаний и опыта (такое сочетание поможет поделиться взглядами и идеями). Основные преимущества ad-hoc testing:нет необходимости тратить время на подготовку документации;самые важные дефекты зачастую обнаруживаются на ранних этапах;часто применяется, когда берут нового сотрудника. С помощью этого метода, человек усваивает за 3 дня то, что, разбираясь с тестовыми случаями, разбирал бы неделю – это называется форсированное обучение новых сотрудников;возможность найти трудновоспроизводимые и трудноуловимые дефекты, которые невозможно было бы найти, используя стандартные сценарии проверок. Пример свободного тестирования (Ad-hoc testing): Ad-hoc тестирование мы часто используем в нашей жизни, возьмем, к примеру, обычный поход в супермаркет. После входа в супермаркет сразу на входе вы можете найти корзину/тележку для продуктов, но если её не окажется в привычном вам месте – это можно будет считать багом. При выборе молока обратите внимание на срок годности и, если молоко окажется просроченным, опять же это будет баг. Так же и с другими продуктами. И, если в конечном итоге, при оплате покупок на кассе, бутылка вина, на которой был ценник 100, окажется ценой в 200, это также будет багом. Если нам нужно провести ad-hoc тестирование интернет-магазина, то этот краткий список может помочь с тем, что нужно проверить: все возможности сайта доступны без регистрации;корректность отображения анимаций и картинок;все возможности сайта доступны после регистрации;процесс регистрации;процесс добавления/удаления из корзины;процесс оплаты покупок;удобство в пользовании для новичков, простота, подсказки, помощь. Также стоит отметить, что ad-hoc тестирование часто является любимым видом тестирования для тестировщиков, где можно проявить все свои знания и выполнить самые труднопредсказуемые сценарии, то есть предоставляется возможность чистой импровизации. Способы повышения эффективности Ad-hoc тестирования Приготовление. Проанализировать дефекты в похожих приложениях, таким образом повысив вероятность обнаружения подобных дефектов в тестируемом приложении.Формирование черновика. Это не должен быть детальный план тестирования, а наброски, с чего начать и какие проблемы поискать.Тестирование сессиями. Тестировать различный функционал продукта по очереди, т.е. не всё сразу. Это помогает лучше сфокусироваться и понять проблемы.Уделять внимание целевым областям. В первую очередь проверить те области, которые не покрыты тест-дизайном и тестовой документацией.Использование разных вспомогательных программ. Некоторые дефекты можно обнаружить, используя дебаггеры, профайлеры и мониторинги. Знание таких утилит помогает в тестировании.Записывать результаты тестирования. Записи того, какие баги были найдены, в каких частях приложения их больше и т.п. Это может помочь как разработчикам, так и тестировщикам последующих версий приложения. Также можно записать то, что не работало, т.к. аналитикам может быть полезно увидеть, что работало хорошо. Исследовательское тестирование (Exploratory testing) ad-hoc testing) Свободное тестирование (ad-hoc testing) – это вид тестирования, который выполняется без подготовки к тестированию продукта, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Оно не требует никакой документации, планирования, процессов, которых следует придерживаться при выполнении тестирования. Такой способ тестирования в большинстве случаев дает большее количество заведенных отчётов об ошибке. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основной функциональной части продукта и выполняет как позитивные, так и негативные варианты возможных сценариев. Если каждый следующий тест, который выполняет тестировщик, выбирается по результатам предыдущего теста, это означает, что мы используем исследовательское тестирование. Главное, что нужно помнить об исследовательском тестировании, это то, что само по себе оно не является методикой тестирования. Это, скорее, подход, который можно применить к любому виду тестирования. Еще один важный момент заключается в том, что исследовательское тестирование – это не только выполнение тестов. Тестировщики могут применять исследовательский подход и при разработке новых тестов в начале итерации, и при анализе уже завершенных тестов. Также, исследовательское тестирование не должно выполняться небрежно, в спешке и без подготовки. Исследовательский подход может требовать очень тщательной и длительной подготовки к определенным тестам, а накопленные за многие годы знания и умения тестировщика, применяющего данный подход, – это часто невидимая, но важная форма подготовки. Исследовательское тестирование может проводиться вручную, а может осуществляться с широким применением средств автоматизации, т.е. любых вспомогательных инструментов тестирования. Когда следует применять исследовательское тестирование? Самые распространенные случаи: когда нужно обеспечить быструю обратную связь для нового продукта или новой функциональности продукта;когда нужно быстро ознакомиться с продуктом;когда уже были проведены основные виды тестирования и время позволяет разнообразить методы тестирования;когда нужно найти дефект, локализованный в определенном модуле в кратчайшие сроки;когда проверяется работа другого специалиста по тестированию;когда нужно изучить состояние конкретного риска для принятия решения о необходимости покрытия конкретной области тестами. Полезные ссылки:<a href="https://www.guru99.com/adhoc-testing.html" target="_blank" style="font-size: 14px;">Ad-hoc testing article/eng</a><a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/spetsialnoe-testirovanie" target="_blank">Ad-hoc testing article/rus</a><a href="https://www.youtube.com/watch?v=Nk_bC9WmuC4" target="_blank">Ad-hoc testing video tutorial/eng</a>

Что такое метод Ad Hoc тестирования и как он проводится?

Ad-Hoc метод

Что такое автоматизированное тестирование и как оно проводится?

Автоматизированное тестирование

<h3>Ручное тестирование VS Автоматическое тестирование</h3> <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Ручное тестирование </td>
o<td style="width: 50%; text-align: center;">Автоматическое тестирование </td></tr>
<tr style="text-align: center;">
o<td style="width: 50%; text-align: left;">Ручное тестирование требует вмешательства человека для выполнения теста. </td>
o<td style="width: 50%; text-align: left;">Автоматическое&nbsp;тестирование — это использование инструментов для выполнения тестовых примеров․ </td></tr>
<tr style="text-align: left;">
o<td style="width: 50%;">Ручное тестирование потребует квалифицированной рабочей силы, долго и потребует больших затрат. </td>
o<td style="width: 50%;">Автоматическое тестирование экономит время, затраты и рабочую силу. После записи проще запустить набор автоматизированных тестов. </td></tr>
<tr>
o<td style="width: 50%;">Любой тип приложения можно протестировать вручную, некоторые типы тестирования, такие как специальное тестирование и тестирование на обезьянах, больше подходят для выполнения вручную. </td>
o<td style="width: 50%;">Автоматическое тестирование рекомендуется только для стабильных систем и чаще всего используется для регрессионного тестирования. </td></tr>
<tr>
o<td style="width: 50%;">Ручное тестирование может стать повторяющимся и скучным. </td>
o<td style="width: 50%;">Скучную часть выполнения одних и тех же тестовых случаев снова и снова выполняет программное обеспечение для автоматизации тестирования. </td></tr></tbody></table> Полезные ссылки:<a href="https://www.guru99.com/difference-automated-vs-manual-testing.html" target="_blank">Manual testing vs Automation testing article/eng</a><a href="https://auriga.ru/" target="_blank">Manual testing vs Automation testing article/rus</a><a href="https://www.youtube.com/watch?v=SEzPFlnI7mY" target="_blank">Manual testing vs Automation testing video tutorial/eng</a>

В чем разница между ручным и автоматизированным тестированием?

Ручное VS Автоматическое тестирование

<h3>Что проверяет функциональное тестирование?</h3> Это основной вид тестирования направленный на проверку всех требований. Функциональное тестирование- это вид тестирования, при котором выявляется некорректная /неправильная работа функционала программы. Проверка функций и характеристик разрабатываемого ПО. Этот вид тестирования занимает 90% времени отведённого на тестирование. Функциональное тестирование предполагает проверку функциональных требований: логики и бизнес-правил приложения или системы. Полноценное системное/функциональное тестирование является самым трудоёмким процессом и может занимать до 80% всего бюджета проекта по тестированию.(Ф.Брукс) Тестирование функциональности может проводиться в двух аспектах: <ol><li>требования</li><li>бизнес-процессы</li></ol> Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев. В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии. Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал. Тестирование в перспективе «бизнес-процессы» использует знание бизнес- процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии, как правило, основываются на случаях использования системы. Пример функциональных тестов: <ul><li>Переход по разделам форума.</li><li>Поиск по сайту.</li><li>Подписка на рассылку - письма с информацией приходят.</li></ul> Этапы функционального тестирования Ниже приводится пошаговый процесс проведения функционального тестирования: <ol><li>Понять функциональные требования</li><li>Идентифицировать тестовые входные данные или тестовые данные на основе требований</li><li>Вычислить ожидаемые результаты с выбранными входными значениями теста</li><li>Выполнить тестовые примеры</li><li>Сравните фактические и рассчитанные ожидаемые результаты</li></ol> Виды функционального тестирования 1. Unit testing 2. Integration testing 3. Interface testing. 4. System testing 5. Regression testing 6. Smoke testing 7. Sanity testing 8. Acceptance testing Unit testing 1. При использовании этого типа функционального тестирования во время модульного тестирования тестируется наименьшая функциональная и тестируемая единица кода. 2.В основном выполняется разработчиками, поскольку это метод тестирования «белого ящика». 3. Выполняется на самых ранних этапах разработки, что помогает выявить дефекты на начальных этапах разработки. Это помогает сэкономить на более высоких затратах на исправление дефектов на более поздних этапах STLC. Integration testing 1. Два или более протестированных компонента программного обеспечения объединяются вместе и тестируются для подтверждения ожидаемого взаимодействия между ними. 2. Между устройствами происходит обмен командами, данными, вызовами БД, вызовами API, обработкой микросервисов, и во время этой интеграции не наблюдается никакого неожиданного поведения. Interface testing 1. Часть интеграционного тестирования; проверяется корректность обмена данными, передачи данных, сообщений, вызовов и команд между двумя интегрированными компонентами. 2. Связь между базой данных, веб-сервисами, API или любым внешним компонентом и приложением проверяется во время тестирования интерфейса. 3. Во время передачи данных или команд не должно быть никаких ошибок или несоответствий формата. Если возникла такая проблема, ее необходимо исправить. 4. Тестирование интерфейса — это тестирование связи между различными интерфейсами, а интеграционное тестирование — это тестирование интегрированной группы модулей как единого целого. System testing 1.Все компоненты системы объединяются и система тестируется на соответствие и корректность техническим требованиям (Функциональным или Системным). 2. Это метод тестирования «черного ящика», который проверяет интегрированную систему. 3. Оно выполняется перед приемочным тестированием пользователя (UAT) в STLC (жизненный цикл тестирования программного обеспечения). 4. Тестирование системы проводится практически в реальной среде и в соответствии с реальным использованием. Regression testing 1. После некоторых улучшений или исправлений кода разработчиками становится очень важно запустить набор регрессионных тестов. Регрессия запускается, чтобы гарантировать, что эти изменения кода не помешали существующим рабочим функциям или что в код не внесен какой-либо новый дефект. 2. Сценарии регрессионного тестирования представляют собой подмножество существующих функциональных тестов, которые охватывают основные функции системы. 3. Случаи регрессии необходимо обновлять, добавлять и удалять в соответствии с изменениями приложения. 4. Случаи регрессионного тестирования являются лучшими кандидатами для автоматического тестирования, поскольку они выполняются часто и требуют времени для выполнения. Smoke testing 1.После разработки, когда выпускается новая сборка, в приложении проводится Smoke testing, чтобы убедиться в работе всех сквозных основных функций. 2. Smoke testing обычно проводится для сборок, созданных на начальном этапе разработки приложения, которые еще не стабильны. 3. Если во время тестирования какая-либо основная функциональность не работает должным образом, данная конкретная сборка отклоняется. Разработчикам необходимо исправить ошибки и создать новую сборку для дальнейшего тестирования. 4. После успешного Smoke testing приложение готово к следующему уровню тестирования. Sanity testing 1. Sanity testing выбираются из набора регрессионных тестов, охватывающих основные функции приложения. 2. Sanity testing проводится на новой сборке, созданной разработчиками для относительно стабильного приложения. 3. Когда приложение успешно проходит Sanity testing, оно готово к следующему уровню тестирования. 4. Легко спутать Smoke testing и Sanity testing. Чтобы протестировать исходное приложение после новой сборки, выполняется Smoke testing. После многих выпусков, как только приложение становится стабильным, для одного и того же приложения проводится Sanity testing. Acceptance testing 1. В ходе приемочного тестирования проверяется приемка приложения конечным пользователем. Цель этого тестирования — убедиться, что разработанная система соответствует всем требованиям, которые были согласованы при создании бизнес-требований. 2. Выполняется сразу после тестирования системы и перед окончательным выпуском приложения в реальном мире. 3. Приемочное тестирование становится критерием, позволяющим пользователю принять или отклонить систему. 4. Это метод тестирования «черного ящика», поскольку нас интересует только готовность приложения к рынку и реальным пользователям. Полезные ссылки:<a href="https://www.guru99.com/functional-testing.html" target="_blank">Functional testing article/eng</a><a href="https://www.applause.com/blog/functional-testing-types-examples" target="_blank">Functional testing types article/eng</a><a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/funktsionalnoe-testirovanie-2" target="_blank">Functional testing article/rus</a><a href="https://www.youtube.com/watch?v=IGnZHgjU42Y" target="_blank">Functional testing video tutorial/eng</a><a href="https://www.youtube.com/watch?v=B1-1BqAr1f4" target="_blank">Functional testing video tutorial/rus</a>

Что такое функциональное тестирование?

Функциональное тестирование

Что такое нефункциональное тестирование?

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

<h3>Тестирование обслуживания</h3> Тестирование обслуживания проводится на уже развернутом программном обеспечении. Развернутое программное обеспечение необходимо усовершенствовать, изменить или перенести на другое оборудование. Тестирование, проводимое во время этого цикла усовершенствования, изменения и миграции, называется тестированием обслуживания. Полезные ссылки:<a href="https://www.softwaretestingmaterial.com/maintenance-testing/" target="_blank">Maintenance testing article/eng</a><a href="https://www.youtube.com/watch?v=7B69Z35BvD4" target="_blank">Maintenance testing video tutorial/eng</a>

Что такое тестирование обслуживания и как оно проводится?

Тестирование обслуживания

<h3>Что такое Defect?</h3> Разница между фактическими и ожидаемыми результатами называется дефектом. Если разработчик обнаруживает проблему и исправляет ее самостоятельно на этапе разработки, это называется дефектом. <h3>Что такое Error?</h3> Если тестировщики обнаруживают несоответствие в приложении / системе на этапе тестирования, они называют это ошибкой. Как я упоминал ранее, существует противоречие в использовании Bug and Defect. Многие говорят, что ошибка - это неофициальное название дефекта. <h3>Что такое Bug?</h3> Мы не можем скомпилировать или запустить программу из-за ошибки кода в программе. Если разработчик не может успешно скомпилировать или запустить программу, они называют это ошибкой. <h3>Что такое Failure?</h3> После того, как продукт развернут и клиенты обнаруживают какие-либо проблемы, они называют продукт неисправным. После выпуска, если конечный пользователь обнаруживает проблему, эта конкретная проблема называется ошибкой. Полезные ссылки:<a href="https://www.360logica.com/blog/difference-between-defect-error-bug-failure-and-fault/" target="_blank">Difference between Defect, Error,Bug, and Failure article/eng</a><a href="https://www.youtube.com/watch?v=53braDId-RQ" target="_blank">Defect, Error,Bug, and Failure video tutorial/eng</a>

В чем разница между этими терминами:Defect, Error, Bug, Failure?

Defect, Error, Bug, Failure

<h3>Жизненный цикл ошибки</h3> Итак, мы нашли баг. Может даже блокер. Что же с ним может случится, на всём его нелегком жизненном пути? (Названия этапов жизни дефектов могут быть разными в разных баг-трекинг системах, но суть их одна). 1.Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.2.Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека который должен её проанализировать (обычно Project Manager). В зависимости от решения менеджера проекта, баг может быть:3.Отложен (Deferred). Исправление этого бага не несет ценности на данном этапе разработки или по другим, отсрочивающим его исправление причинам.4.Отклонен (Rejected). По разным причинам дефект может и не считаться дефектом или считаться неактуальным дефектом, что вынуждает отклонить его.5.Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему, то статус такой ошибки меняется на «дубликат».6.Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика который должен исправить ошибку.<img src="https://lh4.googleusercontent.com/UgOiYKxjOhr-1mg_t-JlCdb03bEqfEBHV9TlE-_HdfQa65MPMaZihbuoBMaLRB9x7Vk3_f3TZSOPLmdSSNNnAqVOjaCsXuX9f98NL4yzIxR0jxBJ7ToYhDFZ0IYgRn-CHUEGRN8MlXTMmOExyeH1-1g" width="624" height="464" style="margin-left:0px;margin-top:0px;">Когда наличие дефекта неопровержимо, его путь может привести к следующим статусам: Исправлен (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект. В зависимости от того, исправил ли разработчик дефект, дефект может быть: 1.Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект, или все-таки разработчик безответственный. Если бага больше нет, он получает данный статус.2.Повторно открыт (Reopened). Если опасения тестировщика оправданы и баг в новом билде не исправлен – он все так же потребует исправления, поэтому заново открывается.3.Закрытый (Closed). В результате определенного количества циклов баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым. Это и есть основные этапы жизненного цикла дефекта. Уверен, если Вы будете использовать данную градацию жизни несносных багов, – вероятность того, что Вы успешно ответите на вопрос о “жизненном цикле багов” на собеседовании очень велика. Полезные ссылки:<a href="https://www.guru99.com/defect-life-cycle.html" target="_blank">Defect/Bug life cycle article/eng</a><a href="https://www.youtube.com/watch?v=EZGDyFPHFMw" target="_blank">Bug life cycle video tutorial/eng</a><a href="https://www.youtube.com/watch?v=ndwA0ywELvg" target="_blank">Bug life cycle video tutorial/rus</a>

Что такое жизненный цикл ошибки?

Жизненный цикл ошибки

<h3>Серьезность дефекта</h3> Серьезность определяется как степень влияния дефекта на разработку или работу тестируемого приложения компонента. Более высокий эффект на функциональность системы приведет к более высокой степени серьезности ошибки. Инженер по обеспечению качества обычно определяет степень серьезности дефекта. <h3>Уровни серьезности</h3> В тестировании программного обеспечения серьезность дефекта можно разделить на четыре класса 1.Критическое : этот дефект указывает на полное завершение процесса, дальше ничего не может продолжаться2.Крупный: Это очень серьезный дефект, который разрушает систему. Тем не менее, некоторые части системы остаются функциональными3.Средняя : вызывает нежелательное поведение, но система все еще функционирует.4.Низкий : это не приведет к серьезному отказу системы <h3>Приоритет дефекта</h3> Приоритет определяется как порядок, в котором дефект должен быть исправлен. Чем выше приоритет, тем скорее дефект должен быть устранен. Дефектам, которые оставляют программную систему непригодной для использования, предоставляется более высокий приоритет по сравнению с дефектами, которые приводят к сбою небольшой функциональности программного обеспечения. <h3>Уровни приоритета</h3> Приоритет дефекта можно разделить на три класса 1.Низкий: дефект является раздражающим фактором, но ремонт может быть выполнен после устранения более серьезного дефекта.2.Средний: при нормальном ходе развития деятельности дефект должен быть устранен. Может подождать, пока не будет создана новая версия3.Высокий: дефект должен быть устранен как можно скорее, так как он серьезно влияет на систему и не может быть использован, пока не будет устранен <h3>Примеры</h3> Давайте посмотрим на пример низкой серьезности и высокого приоритета и наоборот 1.Очень низкая серьезность с высоким приоритетом: ошибка логотипа для любого веб-сайта отгрузки может иметь низкую серьезность, поскольку не влияет на функциональность веб-сайта, но может иметь высокий приоритет, поскольку вы не хотите, чтобы дальнейшая отгрузка продолжалась с неправильным логотипом.2.Очень высокая серьезность с низким приоритетом. Аналогичным образом, для веб-сайта, выполняющего рейсы, дефект функциональности бронирования может быть очень серьезным, но может иметь низкий приоритет, так как его можно запланировать выпустить в следующем цикле. <blockquote>Полезные ссылки:</blockquote><blockquote><a href="https://www.guru99.com/defect-severity-in-software-testing.html" target="_blank">Defect severity and priority article/eng</a></blockquote><blockquote><a href="https://www.performance-lab.ru/blog/sereznost" target="_blank">Defect severity and priority article/rus</a></blockquote><blockquote><a href="https://www.youtube.com/watch?v=HW_tnUnUav8" target="_blank">Defect severity and priority video tutorial/eng</a></blockquote><blockquote><a href="https://www.youtube.com/watch?v=ZyiV9fmUzjk" target="_blank">Defect severity and priority video tutorial/rus</a></blockquote>

Что такое серьезность ошибки и приоритет ошибки?

Серьезность и приоритет дефекта

<h3>Отчет о дефектах</h3> документ, идентифицирующий и описывающий дефект, обнаруженный тестировщиком. Цель отчета о дефекте — как можно более четко сформулировать проблему, чтобы разработчики могли легко воспроизвести дефект и исправить его. Шаблон отчета о дефектах В большинстве компаний используется инструмент сообщения о дефектах, и элементы отчета могут различаться. Однако в целом отчет о дефекте может состоять из следующих элементов. При сообщении об ошибке разработчику ваш отчет об ошибке должен содержать следующую информацию. 1.Defect_ID — уникальный идентификационный номер дефекта. 2.Описание дефекта — подробное описание Дефекта, включая информацию о модуле, в котором был обнаружен Дефект. 3.Версия — версия приложения, в которой обнаружен дефект. 4.Шаги — подробные инструкции со скриншотами, с помощью которых разработчик может воспроизвести дефекты. 5.Дата поднятия — дата, когда дефект был обнаружен. 6.Ссылка - где вы предоставляете ссылку на подобные документы. требования, дизайн, архитектура или, возможно, даже скриншоты ошибки, которые помогут понять дефект. 7.Обнаружено — имя/идентификатор тестировщика, выявившего дефект. 8.Статус — Статус дефекта, об этом позже. 9.Исправлено — имя/идентификатор разработчика, исправившего проблему. 10.Дата закрытия — дата закрытия дефекта. 11.Серьезность, которая описывает влияние дефекта на приложение. 12.Приоритет, связанный со срочностью устранения дефекта. Приоритет серьезности может быть высоким/средним/низким в зависимости от срочности воздействия, при которой дефект должен быть исправлен соответственно. Эффективное сообщение о дефектах 1.Оно должно быть конкретным и ясным. 2.В деталях. 3.Писать следует объективно, опираясь на факты и избегая эмоций. 4.Прежде чем открыть ошибку, вы должны быть уверены, что это ошибка. 5.Обязательно просмотрите его после того, как закончите. 6.Шаги по поиску ошибок должны быть сведены к минимуму. Полезные ссылки:<a href="https://bugherd.com/blog/bug-reporting/" target="_blank">Bug report article/eng</a><a href="https://www.youtube.com/watch?v=Axm-F0pH8cg" target="_blank">Bug report video tutorial/rus</a><a href="https://www.youtube.com/watch?v=dns4zBqfpEM" target="_blank">Bug report video tutorial/eng</a><a href="https://www.youtube.com/watch?v=g8FJ_Zja9P0" target="_blank">Bug, Bug report video tutorial/arm</a>

Что такое отчет о дефектах и из чего он состоит?

Отчет о дефектах

<h3>Тест кейс</h3> ТЕСТОВЫЙ СЛУЧАЙ — это набор условий или переменных, при которых тестировщик определит, удовлетворяет ли тестируемая система требованиям или работает правильно. Процесс разработки тестовых примеров также может помочь обнаружить проблемы в требованиях или дизайне приложения. <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 20.839%; text-align: center;">Поле тестового примера </td>
o<td style="width: 78.9581%; text-align: center;">Описание </td></tr>
<tr>
o<td>Идентификатор тестового случая </td>
o<td>Каждый тестовый пример должен быть представлен уникальным идентификатором. Чтобы указать типы тестов, следуйте некоторому соглашению, например «TC_UI_1», обозначающему «Тестовый пример пользовательского интерфейса № 1» </td></tr>
<tr>
o<td>Приоритет теста: </td>
o<td>Это полезно при выполнении теста Низкий Середина Высокий </td></tr>
<tr>
o<td>Название модуля: </td>
o<td>Определите имя тестируемого основного модуля или субмодуля </td></tr>
<tr>
o<td>Тест Разработан: </td>
o<td>Имя тестировщика </td></tr>
<tr>
o<td>Дата проведения испытания: </td>
o<td>Дата разработки теста </td></tr>
<tr>
o<td>Тест выполнил: </td>
o<td>Кто выполнял тест-тестер </td></tr>
<tr>
o<td>Дата проведения теста: </td>
o<td>Дата, когда необходимо выполнить тест </td></tr>
<tr>
o<td>Имя или название теста: </td>
o<td>Название тестового примера </td></tr>
<tr>
o<td>Описание/резюме теста: </td>
o<td>Кратко определите суть или цель теста </td></tr><tr>
o<td>Предварительное условие: </td>
o<td>Любое требование, которое необходимо выполнить перед выполнением этого тестового примера. Чтобы выполнить этот тестовый пример, перечислите все предварительные условия </td></tr><tr>
o<td>Зависимости: </td>
o<td>Определить любые зависимости от требований к тестированию или других тестовых примеров </td></tr><tr>
o<td>Этапы тестирования: </td>
o<td>Подробно опишите все этапы теста и напишите в том порядке, в котором их необходимо выполнить. При написании шагов тестирования убедитесь, что вы предоставляете как можно больше деталей </td></tr><tr>
o<td>Тестовые данные: </td>
o<td>Использование тестовых данных в качестве входных данных для тестового примера. Предоставляйте различные наборы данных с точными значениями, которые будут использоваться в качестве входных данных </td></tr><tr>
o<td>Ожидаемые результаты: </td>
o<td>Укажите ожидаемый результат, включая ошибку или сообщение, которое должно появиться на экране </td></tr><tr>
o<td>Пост-условие: </td>
o<td>Каким будет состояние системы после запуска тестового примера </td></tr><tr>
o<td>Фактический результат: </td>
o<td>После выполнения теста должен быть заполнен фактический результат теста </td></tr><tr>
o<td>Статус (не пройден/пройден): </td>
o<td>Отметьте это поле как неудавшееся, если фактический результат не соответствует предполагаемому </td></tr><tr>
o<td>Примечания: </td>
o<td>Если есть какие-то особые условия, оставленные в поле выше </td></tr></tbody></table>
 Тестовый пример против тестового сценария 1.Тестовый случай&nbsp;— это набор действий, выполняемых для проверки определенных функций или функций, тогда как тестовый сценарий — это любая функциональность, которая может быть протестирована. 2.Тестовый случай&nbsp;в основном создается на основе тестовых сценариев, а тестовые сценарии — на основе тестовых артефактов, таких как BRS и SRS. 3.Тестовый случай&nbsp;помогает провести исчерпывающее тестирование приложения, тогда как тестовый сценарий помогает гибко протестировать комплексную функциональность. 4.Тестовые случаи&nbsp;ориентированы на то, что и как тестировать, тогда как тестовый сценарий больше ориентирован на то, что тестировать. 5.Тестовые случаи — это действия низкого уровня, тогда как тестовые сценарии — это действия высокого уровня. 6.Тестовый случай&nbsp;требует больше ресурсов и времени для выполнения теста, тогда как тестовый сценарий требует меньше ресурсов и времени для выполнения теста. 7.Тестовый случай&nbsp;включает этапы тестирования, данные и ожидаемые результаты тестирования, тогда как тестовый сценарий включает сквозную функциональность, подлежащую тестированию. Вот существенные различия между тестовым сценарием и тестовым примером. <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Тестовый сценарий </td>
o<td style="width: 50%; text-align: center;">Тестовые случаи</td></tr>
<tr>
o<td style="width: 50%;">Сценарий тестирования содержит документацию высокого уровня, описывающую сквозную функциональность, подлежащую тестированию. </td>
o<td style="width: 50%;">Тестовые примеры содержат определенные этапы тестирования, данные и ожидаемые результаты для тестирования всех функций приложения. </td></tr>
<tr>
o<td style="width: 50%;">Он больше фокусируется на том, «что тестировать», чем на том, «как тестировать». </td>
o<td style="width: 50%;">Полный акцент на «что тестировать» и «как тестировать». </td></tr>
<tr>
o<td style="width: 50%;">Сценарии тестирования однострочные. Таким образом, всегда существует вероятность неясностей во время тестирования․ </td>
o<td style="width: 50%;">В тестовых примерах определены шаг, предварительные условия, ожидаемый результат и т. д. Поэтому в этом процессе нет никакой двусмысленности. </td></tr>
<tr>
o<td style="width: 50%;">Сценарии тестирования создаются на основе тестовых артефактов, таких как BRS, SRS и т. д. </td>
o<td style="width: 50%;">Тестовый пример в основном основан на тестовых сценариях. Несколько тестовых случаев могут быть получены из одного тестового сценария․ </td></tr>
<tr>
o<td style="width: 50%;">Это помогает гибко протестировать сквозную функциональность․ </td>
o<td style="width: 50%;">Это помогает провести исчерпывающее тестирование приложения․ </td></tr><tr>
o<td style="width: 50%;">Тестовые сценарии — это действия высокого уровня. </td>
o<td style="width: 50%;">Тестовые случаи — это действия низкого уровня. </td></tr><tr>
o<td style="width: 50%;">Для создания и тестирования с использованием сценариев требуется сравнительно меньше времени и ресурсов. </td>
o<td style="width: 50%;">Требуется больше ресурсов для документирования и выполнения тестовых случаев. </td></tr></tbody></table> Полезные ссылки:<a href="https://www.guru99.com/test-case.html" target="_blank">Test case article/eng</a><a href="https://www.parasoft.com/blog/how-to-write-test-cases-for-software-examples-tutorial/" target="_blank">Test case article/eng</a><a href="https://www.youtube.com/watch?v=e0cHqx5cRPo" target="_blank">Test case video tutorial/rus</a><a href="https://www.youtube.com/watch?v=g0PrXoWKM2Y" target="_blank">Test case video tutorial/eng</a><a href="https://www.youtube.com/watch?v=Hq7dt5zVxL0" target="_blank">Test case, Test plan video tutorial/arm</a>

Тест кейс

<h3>Тестовый скрипт</h3> ТЕСТОВЫЙ СЦЕНАРИЙ - это набор инструкций (написанных с использованием языка сценариев / программирования), который выполняется в тестируемой системе для проверки того, что система работает должным образом. Сценарии тестирования используются в автоматизированном тестировании. Иногда набор инструкций (написанных на человеческом языке), используемых при ручном тестировании, также называется тестовым сценарием, но лучшим термином для этого будет тестовый пример. Некоторые языки сценариев, используемые в автоматическом тестировании: <ul><li>JavaScript</li><li>Perl</li><li>Python</li><li>Ruby</li><li>Tcl</li><li>Unix Shell Script</li><li>VBScript</li></ul> Полезные ссылки:<a href="https://www.guru99.com/test-script.html" target="_blank">Test script article/eng</a><a href="https://www.youtube.com/watch?v=txQZm6l4MbM" target="_blank">Test script video tutorial/eng</a>

Что такое тестовый скрипт?

Тестовый скрипт

<h3>Тест-план</h3> Тест-план (Test plan) – это документ, который описывает весь объем работ по тестированию, начиная с описания объекта тестирования, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Тест-план предназначен для: <ul><li>урегулирования процессов тестирования;</li><li>приоритизации задач;</li><li>планирования ресурсов;</li><li>учета программного обеспечения и человеческих ресурсов.</li></ul> Как правило, тест-план составляется QA-лидом команды тестировщиков. Но он может неоднократно редактироваться и самими тестировщиками. Качественный тест-план, по меньшей мере, должен состоять из нижеперечисленных пунктов: 1. Что необходимо протестировать? В этом пункте необходимо подробно описать объект тестирования. Это может быть описание системы, приложения, оборудования. Если объектом тестирования является приложение, то следует перечислить все его функциональные блоки. Также необходимо указать на каком оборудовании, в каких браузерах будет выполняться тестирование. 2. Как будет проводиться тестирование? В этом пункте необходимо подробно описать стратегию тестирования. Необходимо перечислить виды тестирования и их применение по отношению к объекту тестирования. 3. Когда будет проводиться тестирование? На данном этапе описывается последовательность проведения работ: подготовка (Test preparation), тестирование (Testing), анализ результатов (Test result analysis) в разрезе запланированных фаз разработки. Обязательно должны быть указаны даты или критерии перехода от одной фазы к следующей. 4. Критерии начала тестирования В зависимости от конкретного проекта, критерии начала тестирования могут быть различны. Примеры некоторых возможных вариантов начала тестирования перечислены ниже: <ul><li>готовность тестовой платформы (тестового стенда);</li><li>законченность разработки требуемого функционала;</li><li>наличие всей необходимой документации.</li></ul> 5. Критерии окончания тестирования: <ul><li>требования к количеству открытых багов выполнены;</li><li>выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF);</li><li>выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB);</li><li>все тесты успешно пройдены;</li><li>закрыты все баги с высокой и средней критичностью.</li></ul> Если при составлении тест-плана вы ответите на все эти вопросы, то получите хороший черновой вариант документа по планированию тестирования. После этого его нужно доработать, опираясь на пункты указанные ниже, и тест-план будет почти готов: <ul><li>окружение тестируемой системы (описание программно-аппаратных средств);</li><li>необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.);</li><li>риски и пути их разрешения.</li></ul> В зависимости от конкретизации описываемых задач, тест-планы делятся на определенные виды: <ol><li>Мастер тест-план (Master plan или Master test plan) – включает высокоуровневую (High Level) информацию, которая в процессе тестирования не часто меняется и требования к которой не часто пересматриваются.</li><li>Тест-план (Test plan) или детальный тест-план – является гибким документом. В него вносят изменения, которые отражают реальное положение дел на проекте. Также он содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ и т.д.</li><li>План приемочных испытаний (Product acceptance plan) – это документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.).</li></ol> Ключевое отличие мастер тест-плана в том, что он более статичный. Обычно на проекте используют один мастер тест-план и несколько детальных тест-планов, которые описывают отдельные модули одного приложения. Чтобы увеличить ценность тест-плана, участники проектной группы должны время от времени рецензировать и утверждать его. Это делается либо по договоренности внутри коллектива, либо по «процедуре утверждения». Ниже приведен список участников проектной группы, которые уполномочены утвердить тест-план: <ul><li>ведущий тестировщик;</li><li>тест менеджер (менеджер по качеству);</li><li>руководитель разработки;</li><li>менеджер проекта.</li></ul> Все вышеперечисленные участники проекта проводят рецензию, а также вносят свои комментарии и предложения, которые сделают тест-план более полным и качественным. Классический детальный тест-план занимает от нескольких страниц до нескольких десятков страниц. Но при этом, его общая структура всегда сохраняется. Как правило, тест-план имеет следующую структуру: 1-я страница: <ul><li>шапка (логотип и адрес компании)</li><li>название тест-плана</li><li>версия тест-плана</li><li>год</li></ul> 2-я страница: <ul><li>история документа, которая представляет собой таблицу изменений. Эта таблица содержит столбцы: дата, версия, описание, автор.</li></ul> 3-я страница: <ul><li>содержание тест-плана.</li></ul> 4-я страница и далее: <ul><li>введение</li><li>виды тестирования</li><li>операционные системы, браузеры</li><li>функционал приложения</li><li>критерии начала тестирования</li><li>критерии выхода из тестирования</li><li>характеристики оборудования</li></ul> Предпоследняя страница: <ul><li>сколько человеко-часов планируется на различных этапах (дата начала и окончания), например</li><li>на тест-дизайн</li><li>на выполнение тестов</li><li>на анализ тестирования</li><li>на отчеты</li></ul> Последняя страница: <ul><li>выводы и рекомендации</li></ul> Полезные ссылки:<a href="https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html" target="_blank">Test plan article/eng</a><a href="https://www.youtube.com/watch?v=S2_AJP9Oeg0" target="_blank">Test plan video tutorial/eng</a><a href="https://www.youtube.com/watch?v=KH7oPMlAaSM" target="_blank">Test plan video tutorial/rus</a><a href="https://www.youtube.com/watch?v=Hq7dt5zVxL0" target="_blank">Test plan, Test case video tutorial/arm</a>

Что такое план тестирования?

Тест-план

<h3>Как работает Agile?</h3> Гибкая модель (Agile model) - совокупность подходов к разработке ПО, по сути является “правильным мировозрением”, то как мы должны мыслить, какие должны быть ценности, чтобы правильно построить процессы. Работа основывается на Agile манифесте: <ol><li>Люди и взаимодействие важнее процессов и инструментов</li><li>Работающий продукт важнее исчерпывающей документации</li><li>Сотрудничество с заказчиком важнее согласования условий контракта</li><li>Готовность к изменениям важнее следования первоначальному плану</li></ol> Работа строиться на итерациях после каждой итерации версия продукта инкрементируется (приростает и улучшается). Преимущества: <ul><li>Максимальное вовлечение заказчика в проект</li><li>Требования хорошо описаны</li><li>Тестирование тесно связано с разработкой</li><li>Минимум документации</li></ul> Недостатки: <ul><li>Сложность реализовать на крупных проектах.</li></ul> <h3>Пользовательские истории и оценки</h3> <ul><li>Пользовательские истории - это особенности, которые наши клиенты могут однажды захотеть увидеть в своем программном обеспечении.</li><li>Они написаны на учетных карточках, чтобы поощрять личное общение.</li><li>Обычно они работают не более пары дней, и они составляют основу наших Agile-планов.</li><li>Мы получаем их, сидя с нашими клиентами и задавая множество вопросов.</li></ul> <h3>Итерации</h3> Итерации - это основной строительный блок гибкой разработки. Каждая итерация представляет собой стандартный временной интервал с фиксированной продолжительностью, в котором Agile-команды предоставляют дополнительную ценность в виде работающего, протестированного программного обеспечения и систем. Рекомендуемая продолжительность периода - две недели. Однако приемлемо от одной до четырех недель, в зависимости от бизнес-контекста. Итерации обеспечивают регулярный предсказуемый ритм для команд для увеличения ценности, а также для улучшения ранее разработанных. Эти короткие периоды времени помогают команде, владельцам продуктов, менеджерам продуктов и другим заинтересованным сторонам регулярно проверять и оценивать технические и бизнес-гипотезы в работающей системе. Каждая итерация закрепляет точку интеграции, «событие извлечения», которое объединяет различные аспекты системы - функциональность, качество, согласованность и пригодность для использования - по всем вкладам команд. Поскольку кратчайшее устойчивое время выполнения заказа является важной целью разработки Lean-Agile, Agile-команды выполняют полный цикл планирования-выполнения-проверки-корректировки (PDCA) как можно быстрее. Цикл обучения PDCA (показанный на рисунке 1) представляет собой следующие итерационные события: План - Планирование итерации - это этап плана Do - итерационное выполнение - это шаг do Проверка - Обзор итерации - это этап проверки Adjust - Iteration Retrospective - шаг настройки <h3>Планирование и рефакторинг</h3> Master Story - наш список дел в гибком проекте Team Velocity - скорость, с которой мы превращаем пользовательские истории в работающее программное обеспечение. Планирование - итерации = общие усилия / расчетная скорость работы команды Рефакторинг - по мере того, как мы добавляем в систему больше функций, нам нужен способ поддерживать наш дизайн и поддерживать порядок в нашем доме. Полезные ссылки:<a href="https://www.infoworld.com/article/3237508/what-is-agile-methodology-modern-software-development-explained.html" target="_blank">Agile methodology article/eng</a><a href="https://scrumtrek.ru/blog/agile-scrum/4029/metodologiya-agile/" target="_blank">Agile methodology article/rus</a><a href="https://www.youtube.com/watch?v=WjwEh15M5Rw" target="_blank">Agile methodology video tutorial/eng</a><a href="https://www.youtube.com/watch?v=TPrj-AMJ4Ds" target="_blank">Agile methodology video tutorial/rus</a>

Какова роль гибкой модели в обеспечении качества?

Agile модель

<h3>Agile VS Waterfall</h3> Вот основные отличия 10 между методологией Agile и Waterfall: <ol><li style="margin-left: 10px;">Водопад структурированный методология разработки программного обеспечения и часто это может быть довольно жестким, в то время как методология Agile известна своей гибкостью.</li><li style="margin-left: 10px;">Процесс разработки программного обеспечения делится на разные этапы в модели «Водопад», а методология Agile разделяет жизненный цикл разработки проекта на спринты.</li><li style="margin-left: 10px;">Согласно модели Waterfall, мы должны завершить разработку программного обеспечения как один проект. Затем мы разделим это на разные фазы. Каждая фаза происходит только один раз во время проекта. Напротив, мы можем рассматривать методологию Agile как совокупность множества различных небольших проектов. Проекты, которые представляют собой не что иное, как итерацию различных этапов, нацеленных на улучшение общего качества программного обеспечения с учетом отзывов пользователей или команды QA.</li><li style="margin-left: 10px;">Все этапы разработки проекта, такие как проектирование, разработка, тестирование и т. Д., Завершаются в модели Waterfall один раз, а в рамках методологии Agile мы используем итеративный подход к разработке. Следовательно, планирование, разработка, прототипирование и другие этапы разработки программного обеспечения могут происходить более одного раза в течение гибкого проекта.</li><li style="margin-left: 10px;">Если вы хотите использовать модель Водопада для разработки программного обеспечения, вам необходимо очистить все заранее большого города, знать. После начала разработки проекта нет возможности изменять требования. Методология Agile довольно гибкая и позволяет вносить изменения в требования даже после завершения первоначального планирования.</li><li style="margin-left: 10px;">Хотя методология Waterfall является внутренним процессом и не требует участия пользователей, подход Agile по разработке программного обеспечения фокусируется на удовлетворении пользователей и, следовательно, на участии пользователей на этапе разработки.</li><li style="margin-left: 10px;">Одно из основных различий между методологиями разработки Agile и Waterfall - их собственный подход к качеству и тестированию. В модели Waterfall этап «тестирования» следует за этапом «сборки», но в методе Agile мы обычно проводим тестирование одновременно с программированием или, по крайней мере, во время той же итерации, что и программирование.</li><li style="margin-left: 10px;">Мы можем рассматривать модель «Водопад» как строгий последовательный процесс, но методология Agile - это очень совместный процесс разработки программного обеспечения, который ведет к улучшению командной работы и более быстрому решению проблем.</li><li style="margin-left: 10px;">Модель Waterfall требует проектного мышления и фокусируется исключительно на завершении разработки проекта. Agile представила продукт мышления, целью которого является обеспечение того, чтобы разработанный продукт отвечал требованиям пользователей и адаптировался, если потребности пользователей меняются.</li><li style="margin-left: 10px;">Модель Waterfall лучше всего подходит для проектов с четко определенными требованиями, в которых мы не ожидаем никаких изменений. Гибкая разработка поддерживает процесс, в котором мы ожидаем, что требования будут меняться и развиваться. Итак, если мы планируем разрабатывать программное обеспечение, которое нам необходимо регулярно пересматривать и не отставать от технологического ландшафта и требований пользователей, Agile - лучший подход.</li></ol> Преимущества методологии водопада: <ul><li>Это одна из самых простых в управлении моделей. В силу своего характера каждая фаза имеет определенные результаты и процесс оценки.</li><li>Он хорошо работает для небольших проектов, где требования легко понять.</li><li>Быстрая доставка проекта.</li><li>Процесс разработки и результаты работы хорошо документированы.</li><li>Легко адаптируемый метод для разных команд на фазу.</li><li>Специалистам в конкретных областях лучше.</li><li>Эта методология управления проектами полезна для управления зависимостями.</li></ul> Преимущества Agile Model: <ul><li>Это целенаправленный клиентский процесс. Таким образом, обеспечивается постоянное участие пользователя на каждом этапе.</li><li>Гибкие команды очень мотивированы и самоорганизованы, поэтому, вероятно, это принесет лучшие результаты в проектах развития.</li><li>Метод разработки Agile обеспечивает сохранение качества разработки.</li><li>Процесс полностью основан на продвижении идей. Вот почему пользователь и команда точно знают, что было выполнено, а что нет. Это снижает риски в процессе разработки.</li></ul> Ограничения методологии водопада: <ul><li>Это не идеальная модель для большого проекта.</li><li>Если сначала требования не ясны, это менее эффективный метод.</li><li>Очень трудно вносить изменения в замкнутые фазы.</li><li>Процесс тестирования начинается сразу после завершения разработки. Следовательно, высока вероятность ошибок, которые мы обнаружим позже в процессе разработки. Это делает их ремонт дорогостоящим.</li></ul> Ограничения Agile Model: <ul><li>Это не очень полезный метод для небольших проектов развития.</li><li>Это требует, чтобы эксперт принимал важные решения в ходе совещания.</li><li>Затраты на внедрение Agile-метода не ниже других методологий развития.</li><li>Проект может быть сорван, если владельцу продукта не ясно, какого результата он хочет.</li></ul> Полезные ссылки:<a href="https://project-management.com/agile-vs-waterfall/" target="_blank">Agile vs Waterfall article/eng</a><a href="https://worksection.com/blog/waterfall-vs-agile.html" target="_blank">Agile vs Waterfall article/rus</a><a href="https://www.youtube.com/watch?v=rvTejAg_fbY" target="_blank">Agile vs Waterfall video tutorial/eng</a>

В чем разница между моделями Agile и Waterfall?

Agile VS Waterfall

<h3>Методология Scrum</h3> Скрам (Scrum) — фреймворк, гибкой методологии (Agile), который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью. Вся работа разбивается на итерации, которые называются Спринт (Sprint). Каждый Спринт длиться от 2х до 4х недель. Скрам определяет три роли: <ol><li style="margin-left: 10px;">Product Owner - представляет интересы бизнеса, общается непосредственно с заказчиком, выясняет что необходимо и передает эту информацию. представляет клиента, а также создает, поддерживает и приоритезирует набор задач продукта. Он не руководитель команды.</li><li style="margin-left: 10px;">Scrum Master – решает конфликтные вопросы, помогает проводить встречи, обучает Scrum, Agile. Обеспечивает выполнение и соблюдение практик и правил Скрам, а также устраняет любые нарушения, проблемы с ресурсами или другие препятствия, которые могут помешать команде следовать практикам и правилам. Этот человек не руководитель команды, а тренер.</li><li style="margin-left: 10px;">Команда: разработчики, тестировщики, бизнес-аналитики.Разрабатывает и тестирует продукт. Команда самоорганизована: нет руководителя команды, поэтому команда сама принимает решения. Команда также является кросс-функциональной.</li></ol> <h3>Артефакты скрама:</h3> Product Backlog – это список в котором все задачи для реализации готового продукта. В начале каждого спринта команда соберется на Spring Planing, в нем Product Owner приносит список задач (Product Backlog), которые он бы хотел реализовать. DevTeam присваивает задачам уровни сложности и забирает столько задач в Sprint Backlog, сколько она готова реализовать за Sprint. Sprint Backlog – задачи, которые мы реализуем на конкретном спринте. Daily Scrum - Внутри каждого спринта проходят ежедневные 15 минутные собрания. На этой встрече (Daily Scrum) каждый отвечает на три вопроса: Что я сделал? Что я буду делать сегодня? Что мне мешает сделать то-то? (какой блокер?) Инкремент - это результат законченного спринта, т.е та версия продукта над которой работали в течение спринта. Разработанный продукт за время спринта. В последний день спринта проводится: Demo (или Review ) участвуют также ProductOwner и люди из бизнеса, рассказывается что и как классно сделали. Ретроспектива: Что помогало достигать цели спринта, что мешало достигать цели спринта. Какие можем сделать выводы? Не переходим на личности, не ищем виноватых - ищем пути улучшения нашей работы. Например мне, как тестировщику не хватает такого-то устройства. Скрам (Scrum) характеризуется инкрементально-итерационным подходом, в процессе спринта разрабатывается минимально готовая версия, которая показывается Product Owner. Скрам является: <ul><li>компактным</li><li>простым для понимания</li><li>трудным для совершенного овладения</li></ul> Полезные ссылки:<a href="https://www.atlassian.com/agile/scrum" target="_blank">Scrum methodology article/eng</a><a href="https://www.atlassian.com/ru/agile/scrum" target="_blank">Scrum methodology article/rus</a><a href="https://www.youtube.com/watch?v=8dGdIcyDk1w" target="_blank">Scrum methodology video tutorial/eng</a><a href="https://www.youtube.com/watch?v=mockcEwNBbs" target="_blank">Scrum methodology video tutorial/rus</a>

Скрам как методология Agile-модели.

Методология Scrum

<h3>Цель Kanban</h3> Только одна ― получать готовый качественный продукт вовремя. Давайте разбираться, как этого добиться. Kanban начинается с визуализации, чтобы процессы были на виду у команды. Для этого используют специальную доску и набор карточек или стикеров. <h3>Доски Kanban</h3> Доска ― это обязательный элемент для гибкой методологии. Она есть в Scrum, есть и в Kanban. Каждый член команды получает к ней доступ в любое время и видит, на каком этапе находится задача. Доска подойдёт и реальная, и виртуальная: можно использовать простую пробковую или программы вроде Trello. Kanban-доска подстраивается под любой процесс и применяется в любой области. Например, чтобы составить список дел.<img src="https://drive.google.com/open?id=1bF8Iv4u9u-5TkN2Bydl2YSQAsPOqljbl&amp;usp=drive_copy" alt="" width="300px"><span style="font-size:9pt;font-family:Arial,sans-serif;color:#f1ff00;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh7-us.googleusercontent.com/PRHK2pkCblvd-IzL0jJMdBZPLzPpeUOkplv7UkcYdkwVeFWTvAmCW41MDOlbqVFuPffzQGFDXFiyCuV6o5S7XqqO83FB78XPRuHSVOM-0nVVkUFFurxJ3ElaZXXaAXREAREjoOIAnMUIGJzJe_kL4bA" width="624" height="368" style="margin-left:0px;margin-top:0px;"> <h3>Как устроен Kanban в проектах</h3> У каждого проекта есть план процесса работ. Сначала мы его анализируем и разделяем доску на столбцы, которые отражают этапы.Имена столбцов меняются в зависимости от проекта, но важно сохранять их последовательность ― это ключевая ценность Kanban, которую называют потоком.Kanban-карточки ― это задачи, которые движутся по потоку и перетекают в другие столбцы в зависимости от их состояния. На карточке или стикере пишут название задачи и прикрепляют в начало доски. C помощью kanban-доски легко вести несколько проектов одновременно, используя карточки разных цветов: один цвет ― один проект.На доске отражаются все процессы. Команда их анализирует и устраняет слабые места. В Kanban это называется управлением потоком. Команда в Kanban ― единый механизм. Если кто-то не справляется, то страдает общее дело. Работу планируют на доске, поэтому каждый может увидеть свой вклад и ценность для проекта. В Kanban смешались принципы agile-методологий и lean-мышления. Здесь нет жёстких правил, но есть принципы, на которые можно опираться. <h3>Как помогает визуализация</h3> Визуализация помогает видеть картину целиком и корректировать отдельные её части, понимая, как изменения затронут весь проект. Получить результат точно в срок возможно, если контролировать нагрузку команды. Определите количество задач: сколько команда реально способна решать в установленные сроки. Например, в «Проектировании» одновременно ― не больше двух задач, а на «Тестировании» ― только одна. Всё в зависимости от возможностей команды. <img src="https://drive.google.com/open?id=12AiY4XrCf319BR_t1jDSUaZXxsrlqEb2&amp;usp=drive_copy" alt="" width="300px">Полезные ссылки:<a href="https://www.atlassian.com/agile/kanban" target="_blank">Kanban methodology article/eng</a><a href="https://upr.ru/article/metodologiya-kanban-sekrety-effektivnogo-ispolzovaniya/" target="_blank">Kanban methodology article/rus</a><a href="https://www.youtube.com/watch?v=1_Zti9v5ugA" target="_blank">Kanban methodology video tutorial/rus</a><a href="https://www.youtube.com/watch?v=iVaFVa7HYj4" target="_blank">Kanban methodology video tutorial/eng</a>

Канбан как методология Agile-модели.

Методология Канбан

<h3>Scrum VS Kanban</h3> <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Scrum</td>
o<td style="width: 50%; text-align: center;">Kanban</td></tr>
<tr>
o<td style="width: 50%;">Скрам делает
акцент на планировании.
Он начинается с
планирования спринта и заканчивается ретроспективой спринта.
Проводится
множество встреч, которые помогают гарантировать, что команда соответствует
следующим шагам, приоритетам и урокам предыдущих спринтов. </td>
o<td style="width: 50%;">Канбан открыт для
внесения изменений на ходу. Это означает, что здесь меньше жесткости и все
может часто меняться. </td></tr>
<tr>
o<td style="width: 50%;">Он
рекомендует собирать измерения времени, сделанные во время спринтов. </td>
o<td style="width: 50%;">Канбан
рекомендует использовать графики, чтобы получить обзор прогресса команды с
течением времени. </td></tr>
<tr>
o<td style="width: 50%;">Скрам больше не
требует от команд обязательств. Вместо этого речь идет о целях и прогнозах
спринта. </td>
o<td style="width: 50%;">Канбан опирается
на временные рамки и прогнозы. </td></tr>
<tr>
o<td style="width: 50%;">Здесь упор
делается на планирование, поэтому оценка играет очень важную роль в Scrum. </td>
o<td style="width: 50%;">Канбан не имеет
обязательных требований к оценке. </td></tr>
<tr>
o<td style="width: 50%;">У каждого
человека есть своя роль и обязанности. </td>
o<td style="width: 50%;">Никаких
установленных ролей, поэтому гибкость в плане индивидуальных обязанностей. </td></tr>
<tr>
o<td style="width: 50%;">Итерации/спринты
имеют фиксированную продолжительность. Продолжительность
варьируется от 2 недель до 1 месяца. </td>
o<td style="width: 50%;">Канбан не основан
на продолжительности. Эта вещь измеряется относительно времени цикла. </td></tr>
<tr>
o<td style="width: 50%;">Команды должны
выполнить определенный объем работы. </td>
o<td style="width: 50%;">Обязательства не
обязательны, для команд это необязательно. </td></tr>
<tr>
o<td style="width: 50%;">В этом методе
важны межфункциональные команды, поскольку они могут справиться с любыми
сбоями, которые могут стать узким местом в разработке программного обеспечения. </td>
o<td style="width: 50%;">Важно иметь
специализированную команду. </td></tr><tr>
o<td style="width: 50%;">Невозможно
добавлять элементы в текущие итерации. </td>
o<td style="width: 50%;">Новые элементы
можно легко добавить, если имеется дополнительная емкость. </td></tr><tr>
o<td style="width: 50%;">Журнал спринта
принадлежит только одной команде. </td>
o<td style="width: 50%;">Несколько команд
могут совместно использовать доску Канбан. </td></tr><tr>
o<td style="width: 50%;">Результаты
определяются спринтами, набор работ которых должен быть завершен и готов к
рассмотрению. </td>
o<td style="width: 50%;">Продукты и
процессы поставляются непрерывно и по мере необходимости. Таким образом,
процесс тестирования и проверки происходит одновременно. </td></tr><tr>
o<td style="width: 50%;">Метод разработки
программного обеспечения Scrum фокусируется на отставании. </td>
o<td style="width: 50%;">Метод Канбан
полностью фокусируется на панели управления процессом. </td></tr><tr>
o<td style="width: 50%;">Каждый член
команды играет определенную роль в Scrum-мастере, который определяет сроки, владелец продукта устанавливает цели и
задачи, а члены команды проводят работу по разработке. </td>
o<td style="width: 50%;">Для команды не
существует заранее определенных ролей. Однако менеджер проекта все еще может
быть; команда поощряется к сотрудничеству и совместной работе. </td></tr><tr>
o<td style="width: 50%;">Лучше всего
подходит для проектов с меняющимися приоритетами. </td>
o<td style="width: 50%;">Идеально подходит
для команд со стабильными приоритетами, которые вряд ли изменятся со временем. </td></tr><tr>
o<td style="width: 50%;">Измеряет
производительность, используя скорость во время спринтов. </td>
o<td style="width: 50%;">Измеряет
производство, используя время цикла или точное время, необходимое для
завершения одной полной части проекта. </td></tr><tr>
o<td style="width: 50%;">Scrum требует
полного перехода от традиционной модели к модели Agile Scrum, которая позволит реализовать проект. </td>
o<td style="width: 50%;">Канбан не
допускает кардинальных изменений в проекте. </td></tr><tr>
o<td style="width: 50%;">Это идеальный
метод для проектов с сильно различающимися приоритетами. </td>
o<td style="width: 50%;">Лучше всего
подходит для команд со стабильными приоритетами. </td></tr><tr>
o<td style="width: 50%;">В Scrum вся команда сосредоточена на
сотрудничестве и выполнении задачи, чтобы обеспечить качественную работу по
разработке. </td>
o<td style="width: 50%;">Команды работают
над достижением целей и сокращением времени на завершение всего процесса. Таким
образом, сокращение временного цикла здесь является главным показателем успеха. </td></tr><tr>
o<td style="width: 50%;">Акцент Scrum на своих расписаниях; новые элементы не
могут быть добавлены в текущие итерации. </td>
o<td style="width: 50%;">Канбан по своей
природе более итеративен, поскольку не имеет конкретных временных рамок. Таким
образом, новые элементы могут постоянно добавляться всякий раз, когда
появляется дополнительная емкость. </td></tr></tbody></table>
 Полезные ссылки:<a href="https://www.guru99.com/scrum-vs-kanban.html" target="_blank">Scrum vs Kanban article/eng</a><a href="https://asana.com/ru/resources/waterfall-agile-kanban-scrum" target="_blank">Scrum vs Kanban article/rus</a><a href="https://www.youtube.com/watch?v=GLFuzBiy18o" target="_blank">Scrum vs Kanban video tutorial/eng</a>

В чем разница между методологиями Scrum и Kanban?

Scrum Vs Kanban

<h3>Терминология</h3> WWW (Word Wide Web) - глобальное информационное пространство, к которому имеют доступ пользователи по всему миру. Включает в себя сайты, материалы которых основаны на гипертекстовой разметке. Основное навигационное средство на сайтах - это гиперссылки, которые перенаправляют пользователя на нужные ему материалы. URI Uniform Resource Identifier (унифицированный идентификатор ресурса)– имя и адрес ресурса в сети, включает в себя URL и URN URL Uniform Resource Locator (унифицированный определитель местонахождения ресурса)– адрес ресурса в сети, определяет местонахождение и способ обращения к нему URN Unifrorm Resource Name (унифицированное имя ресурса)– имя ресурса в сети, определяет только название ресурса, но не говорит как к нему подключиться Web Browser – специальная программа, предназначенная для просмотра веб-сайтов. Происходит это с помощью http запросов к серверу и получения от него данных, которые обрабатываются по специальным утвержденным стандартам и таким образом формируется веб-страница. Web Server -это компьютер, на котором работают веб-сайты. Это компьютерная программа, которая распределяет веб-страницы по мере их запроса. Основная задача веб-сервера - хранить, обрабатывать и доставлять веб-страницы пользователям. Это взаимодействие осуществляется с использованием протокола передачи гипертекста. (HTTP). Web Page – это логическая единица интернета, однозначно определяемая адресом (URL). Можно сказать, что веб состоит из сайтов, а сайты, в свою очередь - из страниц. Веб-страницы (web-pages) пишутся на языке HTML. Вообще говоря, веб-страница может состоять из нескольких частей (фреймов), каждый из которых является отдельной страницей со своим собственным адресом. Также веб-страница может включать картинки, скрипты и др. Web Site – это совокупность гипертекстовой информации (программных, информационных, медийных средств), которая логически связана между собой, имеет оформление отдельной Интернет-страницы и полностью доступна в сети. Сегодняшнее определение вебсайта можно трактовать и как лицо компании, показатель ее успешности, и как своеобразный «офис» с большим количеством отделов. Клиентская сторона видна пользователю, а серверная - нет. <h3>Протоколы</h3> Ниже представлены 4 основных протокола: <ol><li>IP (Internet Protocol)</li><li>FTP (File Transfer Protocol)</li><li>HTTP (Hypertext Transfer Protocol)</li><li>HTTPS (Hypertext Transfer Protocol Secure)</li></ol> Cash - Область временного хранения в памяти или на диске, содержащая самые последние загруженные веб-страницы. При переходе с веб-страницы на веб-страницу кэширование этих страниц в памяти позволяет быстро вернуться на страницу без необходимости повторно загружать ее из Интернета. Cookie - это текстовые файлы с небольшими фрагментами данных, такими как имя пользователя и пароль, которые используются для идентификации вашего компьютера, когда вы используете компьютерную сеть. Конкретные файлы cookie, известные как файлы cookie HTTP, используются для идентификации конкретных пользователей и улучшения вашего опыта просмотра веб-страниц. Аутентификация — процедура проверки подлинности, например проверка подлинности пользователя путем сравнения введённого им пароля с паролем, сохраненным в базе данных. Авторизация — предоставление определённому лицу или группе лиц прав на выполнение определенных действий. Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты: <ul><li>GET — получение ресурса</li><li>POST — создание ресурса</li><li>PUT — обновление ресурса</li><li>DELETE — удаление ресурса</li></ul> Полезные ссылки:<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP" target="_blank">HTTP Basics article/eng</a><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods" target="_blank">HTTP methods article/rus</a><a href="https://www.youtube.com/watch?v=eesqK59rhGA" target="_blank">HTTP and WEB video tutorial/eng</a><a href="https://www.youtube.com/watch?v=9aycvfzH8UA" target="_blank">HTTP video tutorial/rus</a><a href="https://www.youtube.com/watch?v=FsE0W7_l3uo" target="_blank">HTTP response video tutorial/arm</a>

Какую роль играют WEB-технологии в обеспечении качества?

Роль веб-технологий в QA

<h3>Обычные выражения</h3> Терминология ^_ — указывает на строку, начинающуюся с _. _$ — указывает строку, оканчивающуюся на _. abc* - abc / |c|&gt;=0 abc+ - abc / |c|&gt;=1 азбука? - abc / |c|={0,1} abc{2} - abc / |c|=2 abc{2,5} - abc / 2&lt;=|c|&lt;=5 d - указывает числа по одному (d)+ - указывает числовой сегмент между двумя числами w - указывает буквы одну за другой (w)+ – обозначает буквенный отрезок между двумя буквами, т.е. словами (D)+ — указывает нечисловую часть между двумя числами. с - космос [0-9] — задает числа в диапазоне [0-9] по одному. [0-9]+ — указывает несколько чисел [0-9]+ [a-z] +[0-9]+ -цифра, буква, цифра [^_] — указывает все, кроме пробела [_] – отмечает только _s • - указывает один символ Пример: (/d [a,z] + /d (,) /s [0,6]+) .$ <img src="https://lh4.googleusercontent.com/O5bWLkMcrUEwsqT2cy5oWr4R01dMpmVNrl4x60H3NEV5dj6kj0tW4sWGy7WNULq2cOA2N993YgbCuraUDhzAWyHS0t46zKCpeoQnTXFFTWFzQX0QytZSlgWSmmk2lg161ZvQFYUlrFr_R1ooDtyTh1M7YDfok4R3jjxPTLV2Q7oz4AUq81jVYMz6kcxbTDNzT3guy9Lw"> Полезные ссылки:<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions" target="_blank" style="font-size: 14px;">Regular expressions article/eng</a><a href="https://developer.mozilla.org/ru/docs/Web/JavaScript/Guide/Regular_Expressions" target="_blank">Regular expressions article/rus</a><a href="https://www.youtube.com/watch?v=sa-TUpSx1JA" target="_blank">Regular expressions video tutorial/eng</a><a href="https://www.youtube.com/watch?v=_pLpx6btq6U" target="_blank">Regular expressions video tutorial/rus</a>

Что такое регулярные выражения и почему мы используем их при тестировании программного обеспечения?

Регулярные выражения

Что такое Linux и какие у него есть команды?

Linux

<h3>Установка, настройка, создание репозитория</h3> К примеру, Вам потребовалось передавать созданную Вами информацию (с Вашего домашнего компьютера или рабочего) на сервер (например, Хранилище GitHub). Чтобы каждый участник вашей команды или, например преподаватель, мог получить доступ к вашим файлам. В данном случае, Вам необходимо определиться, какую папку или файл Вы хотите синхронизировать с сервером, т.е создать локальное хранилище (репозиторий). Будем рассматривать на примере работы с IDEA и управления из консоли. Данный пример специально никак не завязан на используемом ПО, поэтому Вы сможете повторить данный пример, для конкретной Вашей ситуации. Пошагово выполняем: <ol><li style="text-align: justify;">Создать собственный репозиторий на GIT HUB. Это и будет нашим серверным хранилищем, работать с которым и получать доступ к нему сможет любой участник. Создать свой бесплатный репозиторий на GITHUB</li><li style="text-align: justify;">Установить сам GIT, для этого перейдите по ссылке и загрузите актуальную на сегодня версию: СКАЧАТЬ GIT Бесплатно</li><li style="text-align: justify;">В появившемся окне консоли GIT на вашем компьютере (или консоли cmd) необходимо ввести с клавиатуры следующие команды (каждая команда завершается нажатием клавиши Enter):</li></ol> git - данная команда выводит список доступных команд, а для нас сейчас просто служит подтверждением, что пункт 2 сделан правильно и GIT работает git config --global user.name "Ivan Ivanov" - указать ваше имя. git config --global user.email IvanIvanov@example.com - указать ваш адрес электронной почты. cd: C:/Users/Ivanov/IdeaProjects/Project1 - этой командой вы переходите в нужную Вам папку, которую на следующем шаге будете делать локальным хранилищем (т.е это ваша рабочая папка, в которой будут храниться все изменения проекта) git init - Создать репозиторий в текущей директории git add . - данная команда индексирует (проверяет и запоминает) все файлы (точка в конце команды), которые в последущем будут подвержены коммиту (по сути сохранены). git commit -m "Commit Text" - сохранение изменений в локальную папку. Всё, локальный репозиторий создан, теперь нам нужно связать локальный и удаленнный (GITHUB созданный в пункте 1) репозитории. Для этого нам необходимо ввести следующие команды:git remote add origin https://github.com/GithubUser/RepositiryName.git - где, https://github.com/GithubUser/RepositiryName.git адрес созданного Вами репозитория на GitHub, можно скопировать прямо из браузера с добавлением .git git push -u origin master Поздравляю, Вы связали удаленный и локальный репозитории. Чтобы отправить файлы в удаленный репозиторий выполните команду: git push - после нажатия Enter, в первый раз вас попросят ввести имя пользователя GitHub и пароль. Теперь Вы можете видеть на сайте GitHub произведенные изменения. Обратите внимание, что после того, как вы произвели изменения с файлами, в нашем примере это сохранили проект в IDEA, Вам необходимо выполнить следующие команды:git add . - данная команда индексирует (проверяет и запоминает) все файлы (точка в конце команды), которые в последущем будут подвержены коммиту (по сути сохранены). git commit -m "Commit Text" - сохранение изменений в локальную папку. Для передачи в удаленный репозиторий выполнить еще и эту команду: git push Для того, чтобы, наоборот, получить информацию из удаленного репозитория в локальный репозиторий выполните команду: git pul Полезные ссылки:<a href="https://www.atlassian.com/git/tutorials/what-is-git" target="_blank">Git article/eng</a><a href="https://www.atlassian.com/git" target="_blank">Git article/eng</a><a href="https://www.youtube.com/watch?v=SWYqp7iY_Tc" target="_blank">GitHub video tutorial/eng</a><a href="https://www.youtube.com/watch?v=CRlGDDprdOQ" target="_blank">Git video tutorial/eng</a>

Git как система контроля версий.

Ручное тестирование

КОМПАНИЯ

СЕРВИСЫ