QA Engineer
Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.
Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.
{error: "message","result":...} невозможно нормально тестировать и отлаживать200 ОК — ну, это такое себе развлечение.
Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы
Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.
Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.
Со временем вносить изменения в любой продукт становится сложнее, и растёт риск не только зарелизить новые фичи, но и сломать старые. Часто вместо того, чтобы руками проверять весь проект, этот процесс стараются автоматизировать. Если поговорить с людьми, которые занимаются тестированием интерфейсов, походить по конференциями, становится понятно, что в мире веб-тестирования правит Selenium, а в качестве организации кода подавляющее большинство используют Page Object.
Вот только мне, как программисту, этот паттерн и код, который я видел у разных команд, почему-то никогда не нравился — в голове звучали буквы SOLID. Но я уже был готов смириться с тем, что тестировщики пишут код, как им удобно, из-за отсутствия альтернатив, как где-то год назад, на Angular Connect, услышал я доклад, посвящённый тестированию Angular приложений c использованием Screenplay паттерна. Теперь хочу поделиться.
На прошлой неделе я потратил прилично времени удаляя мёртвый код из нашей кодовой базы. Я люблю удалять код. Как по мне, так мало вещей приносят такое же удовольствие, как наведение порядка в коде. Да я настолько люблю это делать, что меня вызывают недоумение инженеры, которые оставляют ненужный код в приложении. Но на выходных я услышал, как кто-то разговаривал об эксперименте Милгрэма «Подчинение авторитету» (на хабре также писали об этом — прим. переводчика) и я не смог не провести параллели между человеком, который бил током другое человеческое существо и инженером, который оставляет заведомо известные баги и плохой код.
«Компьютерная революция еще не случилась.
(The computer revolution hasnt happened yet)»
— Алан Кей
Интернет на данный момент сломан.Невозможная задача для проекта «Энгельбарт» — «перезагрузить матрицу», «пересобрать» всю область информационных технологий, интернета и компьютерного железа, учитывая все ошибки первой (нынешней) версии.
— Александр Лямин, Qrator. [источник]