Successfully reported this slideshow.

QA Fest 2017. Никита Галкин. Контрактное тестирование на примерах или Contract First

1

Share

1 of 36
1 of 36

QA Fest 2017. Никита Галкин. Контрактное тестирование на примерах или Contract First

1

Share

Description

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

мы рассмотрим такие виды спецификации как RAML и Swagger;
увидим как их использование упрощает ручного тестирования в Postman;
познакомимся с такими инструментами для автоматизации тестирования как Dredd и Abao;
разберем как поставить процесс контрактного тестирования


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

Transcript

  1. 1. Контрактное тестирование на примерах или Contract First 23 сентября, 2017
  2. 2. Никита Галкин Верю, что: ▰ Любая проблема должна решаться на нужно уровне ▰ Сложности не в технологиях, сложности в людях ▰ Проблемы надо обсуждать, идеи – продавать, а решения – демонстрировать 2
  3. 3. 3 Что такое проверка качества?
  4. 4. 4 Проверка соответствия требованиям
  5. 5. Что такое качество? 5 Атрибуты: ▰ переносимость; ▰ функциональность; ▰ эффективность; ▰ удобство использования (юзабилити); ▰ тестируемость; ▰ понятность; ▰ модифицируемость.
  6. 6. Об ожиданиях 6
  7. 7. 7 Проверка соответствия требованиям ОЖИДАНИЯМ
  8. 8. Основные идеи 8 ▰ Задача QA Engineer проверять ожидания ▰ Людям необходимо помогать договариваться ▰ Требования это синхронизированные ожидания ▰ Бизнес платит за реализацию своих ожиданий, за реализованную функциональность
  9. 9. 9 Виды тестов
  10. 10. Виды тестов 10 ▰ Linting – между разработчиками, что код понятен ▰ Unit – между разработчиками, что код не сломают ▰ Functional e2e – между бизнесом и разработчиками, что ПО работает как ожидается ▰ Performance – между бизнесом и разработчиками, что ПО обеспечение эффективно
  11. 11. 11 Personal story
  12. 12. Типичная ситуация 12 Мобильное приложение Новая фича не работает А может даже регрессия перестала работать Вопрос на кого отправлять баг? Mobile/Backend/Content?
  13. 13. Slack bot 13 Венгры
  14. 14. 14 Contract first
  15. 15. Что есть контракт 15 ▰ Между разработчиками из разных команд ▰ Человеко и машино читаемый ▰ Используется для тестирования и разработки, иначе устареет ▰ Является единственным источником правды о договорености ▰ Контракт это не документация, а скорее спецификация
  16. 16. 16 Контракт для REST API
  17. 17. О чем надо договориться для использования REST 17 ▰ Endpoints – где лежат сущности ▰ Methods – действия с сущностями ▰ Headers – метаданные ▰ Status Codes – варианты ответов ▰ Body shemas – форматы ответов и запросов
  18. 18. Текущие форматы 18 ▰ raml ▰ swagger ▰ WADL ▰ API BluePrint ▰ И прочие
  19. 19. 19 Контракт надо читать и писать, поэтому YAML!
  20. 20. Endpoints and methods 20 /pet: post: put: /pet/{petId}: get: post: delete:
  21. 21. Responses 21 /pet: post: responses: 201: description: Created 405: description: Invalid input
  22. 22. 22 Что вам даст наличие контракта
  23. 23. Использование контракта для тестирования 23 ▰ Одинаковые ожидания у всех членов команды ▰ Автогенерируемая документация ▰ Возможность загрузить сразу в Postman ▰ Создание mock для вашего REST API ▰ Автовалидация входных данных ▰ Упрощения тестирование для Backend ▰ И прочее...
  24. 24. 24 Использование контракта для тестирования
  25. 25. Использование контракта для тестирования 25 ▰ Тест кейс – endpoint + method + response ▰ Что проверяем: ▻ Код ответа ▻ Заголовки ▻ Формат body
  26. 26. Использование контракта для тестирования 26 ▰ Arrange – Подготовить данные для запроса ▰ Act – Выполнить запрос ▰ Assert – Проверить соответствие ▻ Код ответа ▻ Заголовки ▻ Формат body ▰ PostAct – Убрать за собой
  27. 27. 27 Изменение контракта не повод переписывать тесты!
  28. 28. Использование контракта для тестирования 28 ▰ Arrange – Подготовить данные для запроса ▰ Act – Выполнить запрос ▰ Assert – Проверить соответствие ▻ Код ответа ▻ Заголовки ▻ Формат body ▰ PostAct – Убрать за собой
  29. 29. 29 Хватить дублировать! Используем парсинг и хуки
  30. 30. Использование контракта для тестирования 30 ▰ Arrange – Подготовить данные для запроса ▰ Act – Выполнить запрос ▰ Assert – Проверить соответствие ▻ Код ответа ▻ Заголовки ▻ Формат body ▰ PostAct – Убрать за собой
  31. 31. Использование контракта для тестирования 31 ▰ Arrange – Подготовить данные для запроса – Before ▰ Act – Выполнить запрос – на основании контракта ▰ Assert – Проверить соответствие – на основании контракта ▰ PostAct – Убрать за собой – After
  32. 32. 32 Dredd для Swagger
  33. 33. Dredd 33 ▰ Поддерживаемые спецификации: ▻ Swagger ▻ Api BluePrint ▻ Что вы допилите в этот OpenSource проект ▰ Хуки на GO, PHP, Python, JavaScript ▰ Написан на Node.js
  34. 34. 34 Abao для RAML 0.8
  35. 35. Abao 35 ▰ Поддерживаемые спецификации: ▻ Raml 0.8 ▰ Хуки на JavaScript и CoffeeScript ▰ Написан на CoffeeScript
  36. 36. 36 СПАСИБО! УПРАВЛЯЙТЕ ОЖИДАНИЯМИ, ДОГОВАРИВАЙТЕСЬ И АВТОМАТИЗИРУЙТЕ! Вы можете найти меня на твиттере @galk_in Слайды доступны speakerdeck.com/galkin Или на моем сайте galk.in

Description

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

мы рассмотрим такие виды спецификации как RAML и Swagger;
увидим как их использование упрощает ручного тестирования в Postman;
познакомимся с такими инструментами для автоматизации тестирования как Dredd и Abao;
разберем как поставить процесс контрактного тестирования


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

Transcript

  1. 1. Контрактное тестирование на примерах или Contract First 23 сентября, 2017
  2. 2. Никита Галкин Верю, что: ▰ Любая проблема должна решаться на нужно уровне ▰ Сложности не в технологиях, сложности в людях ▰ Проблемы надо обсуждать, идеи – продавать, а решения – демонстрировать 2
  3. 3. 3 Что такое проверка качества?
  4. 4. 4 Проверка соответствия требованиям
  5. 5. Что такое качество? 5 Атрибуты: ▰ переносимость; ▰ функциональность; ▰ эффективность; ▰ удобство использования (юзабилити); ▰ тестируемость; ▰ понятность; ▰ модифицируемость.
  6. 6. Об ожиданиях 6
  7. 7. 7 Проверка соответствия требованиям ОЖИДАНИЯМ
  8. 8. Основные идеи 8 ▰ Задача QA Engineer проверять ожидания ▰ Людям необходимо помогать договариваться ▰ Требования это синхронизированные ожидания ▰ Бизнес платит за реализацию своих ожиданий, за реализованную функциональность
  9. 9. 9 Виды тестов
  10. 10. Виды тестов 10 ▰ Linting – между разработчиками, что код понятен ▰ Unit – между разработчиками, что код не сломают ▰ Functional e2e – между бизнесом и разработчиками, что ПО работает как ожидается ▰ Performance – между бизнесом и разработчиками, что ПО обеспечение эффективно
  11. 11. 11 Personal story
  12. 12. Типичная ситуация 12 Мобильное приложение Новая фича не работает А может даже регрессия перестала работать Вопрос на кого отправлять баг? Mobile/Backend/Content?
  13. 13. Slack bot 13 Венгры
  14. 14. 14 Contract first
  15. 15. Что есть контракт 15 ▰ Между разработчиками из разных команд ▰ Человеко и машино читаемый ▰ Используется для тестирования и разработки, иначе устареет ▰ Является единственным источником правды о договорености ▰ Контракт это не документация, а скорее спецификация
  16. 16. 16 Контракт для REST API
  17. 17. О чем надо договориться для использования REST 17 ▰ Endpoints – где лежат сущности ▰ Methods – действия с сущностями ▰ Headers – метаданные ▰ Status Codes – варианты ответов ▰ Body shemas – форматы ответов и запросов
  18. 18. Текущие форматы 18 ▰ raml ▰ swagger ▰ WADL ▰ API BluePrint ▰ И прочие
  19. 19. 19 Контракт надо читать и писать, поэтому YAML!
  20. 20. Endpoints and methods 20 /pet: post: put: /pet/{petId}: get: post: delete:
  21. 21. Responses 21 /pet: post: responses: 201: description: Created 405: description: Invalid input
  22. 22. 22 Что вам даст наличие контракта
  23. 23. Использование контракта для тестирования 23 ▰ Одинаковые ожидания у всех членов команды ▰ Автогенерируемая документация ▰ Возможность загрузить сразу в Postman ▰ Создание mock для вашего REST API ▰ Автовалидация входных данных ▰ Упрощения тестирование для Backend ▰ И прочее...
  24. 24. 24 Использование контракта для тестирования
  25. 25. Использование контракта для тестирования 25 ▰ Тест кейс – endpoint + method + response ▰ Что проверяем: ▻ Код ответа ▻ Заголовки ▻ Формат body
  26. 26. Использование контракта для тестирования 26 ▰ Arrange – Подготовить данные для запроса ▰ Act – Выполнить запрос ▰ Assert – Проверить соответствие ▻ Код ответа ▻ Заголовки ▻ Формат body ▰ PostAct – Убрать за собой
  27. 27. 27 Изменение контракта не повод переписывать тесты!
  28. 28. Использование контракта для тестирования 28 ▰ Arrange – Подготовить данные для запроса ▰ Act – Выполнить запрос ▰ Assert – Проверить соответствие ▻ Код ответа ▻ Заголовки ▻ Формат body ▰ PostAct – Убрать за собой
  29. 29. 29 Хватить дублировать! Используем парсинг и хуки
  30. 30. Использование контракта для тестирования 30 ▰ Arrange – Подготовить данные для запроса ▰ Act – Выполнить запрос ▰ Assert – Проверить соответствие ▻ Код ответа ▻ Заголовки ▻ Формат body ▰ PostAct – Убрать за собой
  31. 31. Использование контракта для тестирования 31 ▰ Arrange – Подготовить данные для запроса – Before ▰ Act – Выполнить запрос – на основании контракта ▰ Assert – Проверить соответствие – на основании контракта ▰ PostAct – Убрать за собой – After
  32. 32. 32 Dredd для Swagger
  33. 33. Dredd 33 ▰ Поддерживаемые спецификации: ▻ Swagger ▻ Api BluePrint ▻ Что вы допилите в этот OpenSource проект ▰ Хуки на GO, PHP, Python, JavaScript ▰ Написан на Node.js
  34. 34. 34 Abao для RAML 0.8
  35. 35. Abao 35 ▰ Поддерживаемые спецификации: ▻ Raml 0.8 ▰ Хуки на JavaScript и CoffeeScript ▰ Написан на CoffeeScript
  36. 36. 36 СПАСИБО! УПРАВЛЯЙТЕ ОЖИДАНИЯМИ, ДОГОВАРИВАЙТЕСЬ И АВТОМАТИЗИРУЙТЕ! Вы можете найти меня на твиттере @galk_in Слайды доступны speakerdeck.com/galkin Или на моем сайте galk.in

More Related Content

Slideshows for you

More from QAFest

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

×