0: Коллеги, приветствую. Сегодня поговорим о том, что является фундаментом нашей профессии. Требования. Вы можете идеально знать теорию тестирования, владеть всеми техниками, тест дизайна и даже автоматизировать на плейрайт. Но как
1: Какой в этом, черт возьми, смысл, если вы не понимаете, что такое требования и как с ними работать? Потому что тестирование без требований это как стрелять с закрытыми глазами. Может, попадёшь, а может, не попадёшь. А может, пошёл ты в этом?
2: Уроке. Мы разберём, что такое требования и как с ними работать, как быть, когда у тебя на проекте есть аж целый аналитик, который пишет вам требования. Что делать, если аналитик отсутствует и требования, в том числе как
3: Разбирать те или иные требования, на что обращать внимание, какие техники использовать. Ну и самое главное, все это произойдёт на реальных примерах из моей практики, из моих рабочих кейсов, которые накопились за 10 лет в огромном количестве.
4: Поэтому, если вы готовы, погнали требования вообще, что это такое, ну, как будто бы все уже и так знают, что требования это то, что должна делать система при определённых обстоятельствах. По сути, здесь мы
5: Заключаем контракт между теми, кто хочет разработать по, и нами командой разработки, как оно будет реализовано. И вот без этих критериев практически невозможно реализовать качественный продукт, поэтому требования безумно важны и вообще даже
6: В базисе нашей профессии заложено то, что тестирование это вообще проверка соответствия ожидаемого результата к фактическому результату и, соответственно, без ожидаемого результата очень сложно понять, существует баг или нет, поэтому если нет
7: Требований нет, критерия, по которому можем это определить. И поэтому мы должны всегда знать, на что мы ориентируемся при проверке нашего по. И это супер базовая история. Поэтому смотрите видео до конца мы пройдёмся по
8: Всей теории и закрепим это на практике все узнаем, все рассмотрим. Поэтому поехали. Начнём с 1 примера. Вот который мне пришёл в голову, и он будет на основании того места, где я сейчас работаю, это яндекс лавка. Вот допустим,
9: У меня есть кнопка добавить в корзину, она добавляет товар за 0 5 секунды. Это хорошо или плохо? И вообще, как вам такой критерий? Хорошо или плохо? Вот если в требованиях написано, что не более 1 секунды, то это хорошо.
10: 100%. Если требование написано не более 200 миллисекунд, то тогда 0 5 секунды это стопроцентный баг. А если требований нет, тогда в таком случае на что ссылаться? Понимать как баг это или фича, неясно от этого.
11: Все споры и идут. Вот. Поэтому требования безумно важная история. Какие требования, соответственно, бывают. 1, это бизнес требования. Зачем это вообще нужно бизнесу, например, увеличить конверсию на 15%. Есть Функ.
12: Функциональные требования, что система должна уметь исходя из этих требований, то есть, например, пользователь может добавить товар в корзину функциональные требования, нефункциональные требования, как система должна работать. Например, страница загружается за менее чем 2 секунды.
13: Пользовательские требования, например, что хочет пользователь как покупатель. Я, например, хочу видеть историю заказов и всю информацию о моём заказе, если, соответственно, этого нет, не реализовано. Соответственно, это будет баг. И неважно зафиксировано. Кстати, это
14: Требованиях или нет, потому что требования могут быть как прямые, так и косвенные, прямые, те, которые записаны уже, а косвенные, либо исходящие из них, либо основанные на здравом смысле, опыте пользователей, законодательстве.
15: Той страны, где это реализовано, и множестве других факторов, о которых мы тоже поговорим. Но чуть чуть попозже давайте поговорим про идеальный мир, когда у нас есть аналитик, который есть на проекте, который требования пишет то, про что вот на всех курсах
16: Трубят аналитик, блин, есть, он вам все принесёт. Ну так вот, вы попали в такой идеальный мир, и у вас есть этот аналитик, и что он, собственно, делает? Он собирает требования у тех, кто хочет реализовать этот продукт. Дальше их документирует. Понятно.
17: Форме и, соответственно, поддерживает эту документацию. Соответственно, есть всегда, куда заглянуть и посмотреть, как должно работать по здесь. Соответственно, есть тз, которое хранится там в конфлюенсе Вики, где угодно. Юзер, сторис, в Джиров, трекере диаграммы различ.
18: Макеты в фигме тоже могут являться требованиями и api спецификации это, например, сваггер далее давайте рассмотрим пример опять-таки на том месте, где я работаю например, мы хотим как стейк холдеры.
19: Как заказчики добавить новую функцию, повторить заказ из истории заказов, как могут выглядеть требования от аналитика? Вот, допустим, у нас такая юзер стори с таким-то номером. И здесь как пользователь, я хочу повторить предыдущий заказ 1 кликом, чтобы экономить время на повтор.
20: Покупках, какие у нас есть критерии успешности на странице истории заказов. У каждого заказа есть кнопка повторить при клике на кнопку все товары и заказы добавляются в корзину. Если товар недоступен, показываем уведомления, товар временно отсутствует. Если товар изменил цену
21: Показываем актуальную цену. Максимальное время добавления товара в корзину 2 секунды. Есть макеты, есть спецификация по api, что это хорошее требование, если, соответственно, такое есть великолепно это
22: Вот прям ты крутой аналитик, у вас работает, который прям посидел, постарался. Что делает кьюэй, когда у нас есть такая спецификация, такие требования. 1 мы анализируем, что там пришло. Мы читаем требования. И 1, что мы ищем, это что нам не
23: Понятно. Неясно 2 есть ли то, что противоречит текущей системе или противоречит там внутри требования друг с другом? Есть ли то, что ещё не доописала, вопросы, которые можно задать, например, аналитику, что если в заказе было, например, 10?
24: Товаров, a5 из них, например, недоступны закончились. Показываем 5 уведомлений. И, например, 1 что происходит с промокодом, если, например, применялся промокод в предыдущем заказе и мы повторяем его, будет ли он снова применяться. Далее пользователь
25: Уже что-то добавил в корзину удалятся ли товары или к этим же товарам добавятся те товары, которые мы повторяем. Можно ли повторить частично выполненный заказ? Видите, можно опять-таки даже у такого неплохого требования найти различ.
26: Вопросы и нюансы, с помощью которых можно довыяснить то, как оно должно работать, причём эти вопросы, они рождаются очень легко, и, соответственно, их можно родить, прочитав непосредственно требования, и получаем результат.
27: Аналитик может обновить требования, добавить ответы на эти вопросы и, соответственно, разработчик. В дальнейшем, когда будет реализовывать этот продукт, не допустит некоторых ошибок. 2 написание тест кейсов на основе уточнённых требований, которые мы вот через вопросы уточнили, мы можем напи,
28: Писать определённые тест кейсы, которые будут покрывать этот функционал. И, соответственно, благодаря работе с аналитиком у нас будут чёткие критерии приёмки, которые мы знаем и знаем, как тестировать, что тестировать будет меньше переделок, потому что разработчик
29: Уже знает, что реализовывать и в каких границах это делать. Соответственно, багов уже на следующих этапах будет гораздо меньше вообще. Ну, типа, чем раньше ты нашёл баг, например, в требованиях через вопросы, тем он, соответственно, дешевле.
30: Если уже разработчик че то накодил, и ты там нашёл баг, это уже не совсем круто. Баги нужно находить ещё на этапе идеи. Блин, далее у тебя есть единый источник правды, все смотрят в 1 место и понимают, как должно работать по это, соответственно, круто. Ну и соответствен.
31: Прозрачно. Понятно, почему решение именно такое. Но это, блин, идеальный мир, когда у тебя есть аналитик. Видите, ну тут тоже есть нюансы, но есть и реальный мир, когда аналитика нет, например, как вот, например, сейчас у меня когда
32: Такое бывает. Это бывает в стартапах, когда ты только пришёл, компания молодая, им нужно быстро, быстро, быстро, быстро в продакшн. Маленькие команды. У них вообще нет бюджета на аналитика. Срочные какие-то фиксы, когда, например, гендерный праздник, завтра или там новый год. Завтра нужно что-то выкатит.
33: Какой аналитик вообще, куда вы, легаси, это legacy, когда ещё там в 2005 году сделали проект аналитика, тогда ещё не было, никто ничего не документировал. Ну и, соответственно, так и живут. Есть у меня 1 реальный пример. Когда-то я
34: Работал в небольшом стартапе по доставке еды. И там у нас пришёл небольшой фича запрос. Нужно было сделать маршрут курьера на карте, чтобы, соответственно, отслеживать его. И все бы ничего.
35: Но никаких требований нет, никакого аналитика, соответственно, тоже нет. И, соответственно, что делать в такой ситуации. И вот тут я хочу поделиться с вами 1 лайфхаком, который можно заиспользовать в таких ситуациях. Это такая техника, как
36: Метод 5 ви и 1 хау, что он из себя представляет. То есть вот либо что, что конкретно должно работать вот как мы берём нашу ситуацию сделать так, чтобы курьер видел маршрут, что конкретно
37: Должно работать. И как пример какой именно маршрут до клиента ли, оптимальный ли либо ещё какой-то, кто, кто будет использовать этот функционал курьеры, диспетчеры, пользователи, да, кто в конечном итоге
38: Где, в каком интерфейсе в мобильном приложении в telegram боте, на веб сайте, ещё где-то в запросе от стейкхолдера такого не было, просто нужен курьер маршрут и все тогда, когда?
39: Показывается сразу после назначения заказа. Либо, соответственно, у тебя маршрут рисуется вообще, может быть, до заказа. А может быть, когда курьер только выдвинулся, а может, а может, а может, нужно уточнить, зачем, какую проблему решаем? Курьеры теряются, они опаздывают, нет.
40: Прозрачности, что зачем это нужно и, соответственно, как это реализовать, как это должно работать например, мы можем интегрироваться с яндекс картами, с google картами. Есть ещё куча международных различных решений. 2GIS опять же тот же самый короче, как это все
41: Будет работать. И, соответственно, пройдясь по этим 5, v и 1 хау, можно, соответственно, до уточнить требования и получить гораздо более понятные, чёткие требования, по которым сможем реализовать этот функционал, и
42: Соответственно, мы можем получить, что курьер видит маршрут в мобильном приложении, маршрут строится текущей точки до адреса клиента, используются яндекс карты, маршрут обновляется при движении курьера, показываем примерное время в пути и при проблемах с gps показываем последнюю известную точку.
43: Все, вот какая большая разница между вот сделать так, чтобы было хорошо и вкусно до, соответственно, чётких критериев приёмки. Вот почувствуйте эту разницу в работе. Это, блин, безумно важно. Вот вы когда будете вот с такими проектами
44: Работать, если вы это не зафиксируете, ну, все плохо будет. Короче, ладно. 2 техника, которая может вам пригодиться, можно посмотреть на своих конкурентов. В любом случае эту фичу кто-то, да, когда-то разрабатывал. Навряд ли вы все такие.
45: Новаторы и скорее всего кто-то уже что-то здесь сделал если мы говорим про тот же самый маршрут курьера, можно посмотреть на еду на delivery club, на самокат, на кучу других сервисов, посмотреть как это реализовано и сделать точно так же и все принести зафиксировать.
46: Окнуть это об всех участников. То есть вот так вот в самокате мы, может, также хотим они такие, о, классно в самокате самое крутое решение, блин, делаем и все. Мы делаем точно также и не паримся. 3 техника, которая может помочь, это фиксация всего.
47: То, о чем вы договорились письменно, это даже не техника, это, блин, базовая база. Все, что я говорю, это обязательно должно быть зафиксировано текстом, если не зафиксировано вот устная договорённость, отсутствие договорённости. Вот прям запомните это золотое правило.
48: На словах договорились. Считай, не договорились. Пока это не зафиксировано, не записано. Считай, этого нет. Всегда все конкретно записывали и отправляем, например, в чат не в личку, в личках не общаемся. Отправляем в чат разработки за
49: Скидываем, если, соответственно, все окнули, реакцию, поставили, все хорошо делаем. Если никто даже не окнул молчание, знак согласия. Все, делаем ещё 1 способ выстроить требования и расписать их. Это исследовательская
50: Тестирование. Мы просто берём функционал, если вы уже накодили, а вас приходят и говорят, тестируй, а ты говоришь требования, а тебе говорят, какие требования? Ты просто начинаешь исследовательское тестирование и записываешь свои вопросы, свои темы, и после этого приходишь и говоришь вот это вот.
51: Так, вот это вот так вот это вот так и тебе говорят. Да, да, да, нет, нет. И все. Ты это фиксируешь письменно и от этого отталкиваешься, соответственно, без вот этих вот 4 техник безумно сложно. Плюс ещё есть бонусная.
52: Техника, про которую я даже говорил отдельно в докладе на sq эдес, это техника 3 омига. Когда ты собираешься с разработчиком, продуктом и тестировщиком, и вы на троих обсуждаете критерии, приёмки, обсуждаете, окаете в письменном виде и фикси.
53: В документ и, соответственно, на основании этого документа вы дальше и работаете. Поехали дальше. Теперь чек лист по работе с требованиями, когда есть аналитик и документация, то тут все достаточно хорошо. Здесь мы просто читаем требования до начала тестирования.
54: Выписываем все, что нам непонятно что вызывает вопросы. Дальше мы проверяем асепта критерия, полное тестирование. Убеждаемся, что макеты соответствуют описанию. Проверяем эйпиай контракты на соответствие требованиям и пишем наши тест кейсы ещё до начала раз.
55: Работки, потому что все уже есть зафиксировано и будет разрабатываться именно так. Все здесь достаточно понятно, но когда нет аналитика, можно использовать наши техники. 1 это вот задать, задать вопросы вот в этой технике 5, v, 1 how.
56: Зафиксировать все письменно, посмотреть на конкурентов, создать свою документацию, исследовательское тестирование, использовать и поиспользовать 3 амига. Ну и, соответственно, никогда не бояться быть занудой. Это спасёт не только продукт, как я здесь записал, но и ва
57: Лично, потому что потом придёт заказчик и скажет, что, серёга, ты виноват, блин, а ты на самом деле не виноват. Вы зафиксировали, устно поболтали и забыли. А это неправильно. Ладно, поехали дальше. У нас ещё есть такой документ. Так, так.
58: Такая банда, как asti кьюби, там фиксируются международные договорённости о том, что и как у нас про тестирование есть, короче, вся наша теория тестирования там у нас фиксируется и там она проверяется. Сертификаты ещё есть такие очень крутые, если есть возможност.
59: Время обязательно их залутает. Так вот, согласно этому международному стандарту, по тестированию программного обеспечения можно использовать вот такой чек, лист, который включает в себя полноту, однозначность, тестируемость, непротиворечивость и атом.
60: Заскриньте себе, пожалуйста, вот эту табличку. Исходя из полноты, описаны все входные данные, описаны все выходные данные, описано поведение при ошибках, описаны граничные случаи. Все должно быть однозначно. Нет слов быстро.
61: Удобно много, мало, все, никого. Вот это все очень, очень плохо. Должны быть конкретные условия. Все термины определены. Только 1 интерпретация. Никаких множественных интерпретаций. Этим очень сильно грешат. Различ.
62: Гуманитарные чувачки типа меня на самом деле дальше тестируемость есть ли измеримые критерии, можно ли написать на это тест кейсы? Понятно, когда требование выполнимо, непротиворечивость не конфликтует с другими требованиями, согласуется с бизнес правилам.
63: Согласуется с техническими ограничениями по атомарности описывает 1 функцию нельзя разбить на части, можно реализовать независимо вот это все вот эти вопросы и вот эти вот критерии зафиксируйте, заскриньте, запомните и применяйте безумно.
64: Важная история теперь немножко практического практического применения по анализу требований. Вот у нас есть исходное требование. Система должна позволять пользователям быстро искать товары и показывать релевантные результаты. Вот, допустим, я в лавке сижу
65: Разрабатываю. И мне вот такое требование приходит быстро искать товары и показывать релевантный результат по полноте. Смотрим, не описано по каким полям поиск результатов. А что если там ничего не найдено? А что если там как очень сложно, однозначно
66: Быстро. И релевантное, очень размытое понятие ни о чем не говорят. Насколько это тестируемо, как измерить быстроту это отклик же должен быть, наверное, какой-то, как проверить релевантность тоже по каким критериям атомарность, смешанный поиск отображ.
67: Результатов, короче, вот если вам приходит примерно вот такое вот требование, ну, блин, исходя из аттики, мы видим, что это фу и нужно это исправлять, как это можно исправить? Мы записываем, что это у нас вот такой вот
68: Айдишник нашего требования на поиск товара. У него приоритет есть определённый и есть связь с бизнес требованием по увеличению конверсии. Какие могут быть здесь функциональные требования. Пользователь может искать товары по названию и описанию. Поиск начинается после ввода.
69: 2 символов результаты отображаются в виде списка до 20 товаров на странице, если товаров не найдено, показывается сообщение по запросу ничего не найдено, результаты сортируются по релевантности, нефункциональные требования, время.
70: Отклика поиска менее пятиста миллисекунд для 95% запросов. Поддерживаемые символы кириллица, латиница, цифры, пробелы и есть определённые асепт критерии. Все уже. Вы посмотрите, насколько стало чётче.
71: И понимаемые требования. Вот по таким требованиям можно реализовать хороший продукт. По вот таким требованиям можно реализовать какашку. Понимаете, это практически применимая история. Поэтому обязательно запомните, для того, чтобы запомнить
72: Лучшим образом есть мнемоника, кто верит, кто не верит, попробуйте. Здесь мы берём смарт. Знаете, наверное, смарт цели. И здесь тоже смарт. Умные, умные, да, критерии хорошие требования, как и цели, должны быть смарт. То есть специфик. Конкрет.
73: Однозначно без быстро много удобно межер измеримые есть числовые критерии ачивал достижимые технически реализуемо релевант, релевант, релевантные связано с бизнес целью и time bound.
74: Ограниченная по времени есть sla, есть таймауты. В общем, если про мнемонику вы знаете, что она на вас хорошо работает, используйте. И, соответственно, есть у нас матрица трассировки требований. Очень классная история, на ней много. Не буду заострять внимание, потому что редко
75: Где используется, ну, блин, если где-то используется очень крутая история, где мы можем взять наши требования, наши тест кейсы и все это соединить в таблицу. Тем самым мы сможем визуализировать, какие требования у нас покрыты тестами, какие не покрыты при изменении требований.
76: Знаем, какие тесты нужно обновить, и можем оценить готовность к релизу. Безумно классная вещь. Это для зрелых продуктов, где, соответственно, такое можно реализовать. Не везде. Соглашусь. Ну что, реальный кейс, как критерии спасли проект, это
77: Кейс не мой, но мне его 1 из подписчиков принёс банковский проект, и, соответственно, там пользователю нужно переводить деньги между своими счетами. Банк, не скажу пользователя не скажу, но кейс очень наглядный. Вот смотрите.
78: Требования. Пользователь может переводить деньги между своими счетами. Вроде все понятно. Вот. Ну да, че тут непонятного, но, по сути, полнота. Не описаны лимиты. Какие суммы в день, в месяц, в год, в секунду полнота.
79: Не описана валюта, то есть в какой, в рублях, в долларах и со всеми это может происходить однозначности, свои счета. Это только в этом банке, в других банках. Может быть это какие-то кредитные счета или другие, блин, вообще непонятно тестируемость, нет критерия успеха. Как понять?
80: Что, что перевод успешен или неуспешен, и, соответственно, это все выливается в то, что здесь можно потерять кучу денег, а тем более приложение банковское, прикиньте, в Сбере, например, кто-то будет тестировать.
81: Такому требованию. А, ну это же все, это коллапс всей банковской системы и результат. После уточнения требований требования из 1 строчки разрослись на 2 страницы. Мы расписали не мы, а чуваки расписали лимиты разовый, дневной месячны.
82: Конвертацию валют комиссии, статусы, уведомления, то есть 30 минут проанализировали требования, задали вопросы по нашей технике и получили соответствующее классные классные требования, по которым разработка сможет реализовать этот продукт. Ка.
83: А вы качественно его протестировать и, соответственно, потом мне возвращать в доработку по множественным причин. Поговорим про красные флаги в требованиях. На что обращать внимание? О чем спрашивать. Например, если к вам приходят и требования, там написано быстро загру.
84: За сколько секунд задавайте вопрос конкретно удобный интерфейс? Какие критерии удобства? Много товаров? Это сколько? 1000, 100, 1000000 или - 2? Поддержка всех браузерах. Каких именно? Какие версии? Вы просто не
85: Представляете, сколько браузеров? Вот просто ради интереса вбейте в поиске, сколько бывает браузеров и сколько у них версий. И вот, ну я так в яндексе работаю. И периодически я смотрю статистику. И если ты будешь тестировать свой функционал на всех браузерах, у тебя не хватит никакого времени.
86: Жопа. Ну и, соответственно, если там, например, есть так далее, ну, это вообще, что такое, так далее. Ну извините, до свидания с такими требованиями. Отсутствие негативных сценариев. Пользователь вводит емейл и получает письмо, ну, нифига себе требования. А что, если емейл некорректный
87: Что если он уже зарегистрирован, а что, если письмо не дошло, вопросов появляется очень много, противоречие. Пользователь может отменить заказ в любой момент и требование. 2, после передачи курьеру заказ не может быть отменён. Это прям причём реальный пример. И здесь
88: Как, как здесь быть? Потому что 2 требования, и они противоречат друг другу. Нужно обязательно встречаться и говорить. Давайте либо крестик надеваем, либо трусы. Ну там че-нибудь 1 из 2 в обязательном порядке. Отсутствие ограниченных условий. Пользователь может добавить товар в Корзин.
89: Сколько товаров, какое минимальное? Какое максимальное? Какая максимальная сумма? Заказа? Минимальная сумма заказа, много вопросов. Поэтому, если есть аналитик, пожалуйста, держите его в узде, чтоб писал нормально, чтобы было и
90: Граничные условия описаны, и противоречия устранены, и негативные сценарии описаны, и есть все то, что не вызовет потом противоречий. Какие инструменты нам тут помогут. 1, это конфлюенс. Здесь мы расписываем все наши требования очень часто. Или Вики, например,
91: Notion здесь тоже можно использовать для различных требований джира ютрек ну то есть другие какие-то бактреии системы туда мы тоже описываем требования фигма обязательная штука для дизайнеров, потому что дизайн это тоже требование сваггер.
92: Для api и прочее. Для анализа требований могут нам пригодиться. Вот матрица трассировки, про которую я говорил, классно визуализирует, помогает. Также чеклисты различные и майма ы. Очень, очень помогающая история. Давайте поговорим про
93: Типичные ошибки, кей. При работе с требованиями. 1, самая основная, это я бы назвал её чтение мысли. Если вы любите читать мысли других людей, это ужасно. Вам в профессии кией делать нечего, потому
94: Что если ты думаешь, что это очевидно в голове заказчика, это может быть совершенно неочевидно. У них в голове может быть все что угодно, и это все, что угодно, обязательно нужно раскладывать на конкретные условия, если кьюэй не уточнил требования.
95: Потому что и так понятно, это может привести к огромным многомиллионным Багам и на самом деле вообще читать мысли других людей очень плохая практика, не делайте так даже в обычной жизни например требование добавить поиск k. Подумал ну обычный поиск разработчик сделает поиск по.
96: Званию, а заказчик хотел поиск по названию, описанию артикулу. Вот, блин, вроде очевидно, а вроде не очевидно. Зафиксировать это нужно в обязательном порядке. 2 требование должен писать аналитик, если вы приходите в команду и такой, а где
97: Требования сидите на жопе, Ровно ждёте требований, вы можете их никогда не дождаться, а дождаться лишь того, что вас уволят. И я, причём такие кейсы видел вполне себе аналитик, такое себе существо, которое может и быть, а может и не быть, а даже когда есть он.
98: Может, короче, если нет аналитика, попытайтесь быть аналитиком. Сами даже не так. Попробуйте организовать эту работу, например, через тренига. Собирайте всех и заставляйте всех тогда участвовать в проработке требований. Вы, блин, кей.
99: Вы супер важный человек на проекте и вы это можете сделать далее я спрошу позже, и это не баг, это не описано в требованиях. Короче, видите, что вам что-то непонятно. Задавайте вопрос, пишите в чат, фиксируйте письменно.
100: Без негатива просто уточняйте все неоднозначные и непонятные вещи, спрашивайте их сразу, потому что чем раньше уточните, чем раньше узнаете, тем быстрее сможете зафиксировать и зафиксить всю эту историю. Баг на этапе.
101: Требований это просто, ну вот зачеркнуть, удалить и написать заново, когда у вас разработчик уже написал код. Ну это, блин, прикиньте, снова написать снова ревью кода, снова сиайсиди, процесс выкатки. Дальше ваше тестирование возможно снова
102: Бак, короче, на этапе требований все валидируем и все будет хорошо. Ну что, подходим к концу, и здесь у меня для вас задание домашнее. Здесь будут приведены несколько требований. Здесь, например, у нас
103: У нас есть регистрация пользователя. Пользователь должен иметь возможность зарегистрироваться в системе при регистрации. Пользователь умеет, имеет, указывает емейл, пароль и имя. После успешной регистрации пользователь получает письмо с подтверждением. Это реальное упрощённое требование. Найдите в нём.
104: Минимум 5 вопросов, которые нужно задать аналитику, обязательно и напишите в комментариях. Вот вот возьмите все эти домашние задания и напишите в комментариях. Я их все равно все читаю, я вам, если что, подскажу. Вот это как, блин, реально практическое домашнее задание. Тем более, если вы изучаете сейча,
105: Тестирование прям не откладывайте на завтра. Вот прям сейчас идите по всем этим домашкам. Ссылка на конспект лекции, эти домашние задания в описании. Забирайте его бесплатно это все и проходите вот эти домашние задания, пишите в комментариях, и я, соответственно, на них на все
106: Отвечу вот здесь у нас всего 2, это ты создашь, попробуешь требования и, соответственно, проанализируешь текущее, что хочется сказать по итогу требования, фундамент, тестирование. Без них тестируем вслепую, если есть аналитику.
107: Но с ним тоже нужно работать. Нет, аналитика, ну ничего страшного. Частично становимся аналитиком всех своих сокомандников в это вовлекаем и работаем. Инструменты это задавание вопросов и фиксация этого всего письменно устные договорённости равно
108: Отсутствие договорённости читать мысли плохо. Не читай мысли и задавай вопросы, даже если они глупые, это важно. Книжки, которые можно почитать для того, чтобы больше базы узнать. Конечно, тут, в принципе уже
109: Есть более чем все для того, чтобы спокойно работать к инженером, но софтв реквайрментс, Карл вейгер, библия по требованиям юзер сторис оплает майк кон тестирование dotcom Роман Савин я его всегда реко.
110: Рекомендую там тоже про требования есть ну и обязательно подписывайтесь на мой telegram канал там про тестирование по изнутри и плюс чат взаимопомощи кией, там разбираем кейсы, различные ситуации помогаем со всеми вопросами обязательно подписывайтесь ну и помните хороший k.
111: Не тот, кто находит багги. Хороший кьюэй, тот, кто не даёт Багам появиться. Чем раньше найдём баг, тем он дешевле. Короче, помните про этом успехов в работе с требованиями. Если есть вопросы, тоже пишите в комментариях ответы на домашки, пишите в комментариях про
112: Верю, ну и удачи вам со всем этим.