Таймкоды: 00:00 - Intro 00:49 - Уровни требований. Виды требований 03:27 - Пути выявления требований 06:09 - Свойства требований, как их тестировать? 12:22 - Как упростить тестирование требований? 15:25 - Способы представления требований (use case, user story) 21:35 - Почему важно уметь тестировать требования? 22:10 - Outro
на одном из собеседований от меня хотели классификацию видов требований : Прямые и Косвенные. Может кому поможет эта информация при подготовке к собеседованиям. Артем молодец, все выпуски жду с нетерпением - все четко и понятно!
Как всегда лучший учитель , вот Белорусы я замечаю всё чаще и чаще, очень софт люди, прям душки. Даже митинговали вставая на скамейки в носках, и вешая пакетики для мусора. Канал про истории людей с Беларуси смотрю, там даже обычный заводчанин настолько грамотно общается, настолько мягко и спокойно , что вот думаешь мы бы были друзьями 100% , так же и с Артёмом хочется дружить и слушать вечно)
Откладывал просмотр и зря, очень важная тема. Но сложно представить как это на практике, если бы был разбор какие-то требований, как твой реальный кейс с работы, был бы шик и блеск.
Тоже подумала, что на практике было бы понятнее. Например разбор тестового задания: протестировать требования к полям ввода даты начала и окончания периода задолженности банку
Хоть прошло и много времени - никогда не поздно сказать спасибо, думаю). Очень ценно было найти вас в ютубе и благодаря вам всё идеально укладывается в голове. Даже Гит в вашем объяснении прошёл как по маслу. Если можно, хотела задать вопрос по этому видео: не очень поняла идею прототипирования, как пути выявления требований. Не очень понимаю, как связан прототип и анализ продукта конкурента, ведь прототип сам по себе это первоначальный образец. Буду очень благодарна, если поможете разобраться)
Реально спасибо за курс!!!! Очень круто. Может после него получу оффер тестировщиком в Айти. Если уж другим способом не получается. Хотя в любом случае знания тестировщика лишними не будут точно. Еще раз огромное спасибо за курс. Респектую.
Спасибо за структурированную и понятную информацию. Читала несколько статей и видио, на тему требований. Исходя из них, хотела спросить. В критериях к качеству требований, встречается ещё такой пункт как реализуемость, в рамках выделенных ресурсов. Тоесть требование возможно выполнить, за то время, финансы, человеческие ресурсы, которые имеются в проекте. Вопрос, исходя из твоего опыта, стоит ли указывать такой критерий на собеседовании, или это зависит от источника, и не обязательно упоминать об этом?
@@rusau Спасибо за ответ. Я тренируюсь по софт скилам, как преподнести замечание человеку, мнение которого уважаешь, чтобы не показаться грубым. Надеюсь получается😊
Хочу спросить только одно. Реально ли хватает полученных знаний из этих видео, чтоб устроиться на работу? Я знаю JS, HTML, CSS. Знаю некоторые другие вещи. Могу даже верстать, и делать разные прикалюхи на JS. Это просто мое хобби. В прослушанных видео, ничего запредельно сложного не уведел. Неужели за это могут взять на работу? Я в данный момент работаю на экскаваторе. До этого работал на грузовике. Деньги впринципе нормальные получаю, и на финансы не жалуюсь. Но реально жизнь на вахтах задолбала. Просто мне эти видео показались ну уж слишком простым. Все курсы предлогают миллион часов обучения, за миллион долларов денег. Пожалуйста дайте мне знать))))Просто если это так, так нахрена мне нужна жизнь в этом экскаваторе ?!)))))))
Привет. Для начинающего ручного тестировщика это необходимая база. Он не верстает и не пишет код, а должен понимать вообще что это, находить необходимые элементы, соотносить то, что наверстали другие, с тем, что нарисовали дизайнеры. Помимо этого у него куча других активностей, о которых я рассказываю на своём канале. А если ты хочешь во фронтэнд-разработку, то, конечно, это один процент от того, что тебе нужно знать.
И не стоит забывать, что конкуренция огромная и на одно место претендуют десятки специалистов. Так что лучше изучить рынок и разобраться в специальности, прежде чем что-то кардинально менять.
@@rusau Во фронтэнд собо не хочу. В тестровщики можно поробовать. Тема интересная. Я просто когда ради хохмы программировал и верстал, много что понял и в чем разобрался. Так что очень многое мне из этого понятно. Думаю может просто немного подтянуть знания в тестировании и попрактиковаться, и походить по собесам. Посмотреть что из этого выйдет.
А как технически выполняется тестирование требований? Допустим мне для составления тест кейсов прислали документ с требованиями к тому, как должны работать функции авторизации, регистрации и восстановления пароля, с подробным описанием того как должна вести себя система в тех или иных ситуациях. Я вижу, что в требованиях не описано много чего. Например, расписан сценарий восстановления пароля по почте, но не расписан сценарий восстановления по номеру телефона. Также много других упущений, противоречий, неточностей и тд. --- Я могу всё это подчеркнуть и на всё это указать прямо в этом же документе? Получается я должен отправить его назад в ожидании пояснений? Само тестирование в этом случае начинать пока нет смысла?
Приветствую 🖖 Спасибо за отличный контент. Вопрос следующий: Если мне приходит юзер Стори, в которой просто указано, что данный функционал, должен работать так же как и ранее. То есть в описании задачи никакой информации детальной нет, есть лишь саммери и все. Какими должны быть действия тестировщика поэтапно? Думаю, что такой вопрос будет интересен всем, так как его можно часто встретить на собеседовании. Спасибо!
Привет, пожалуйста. В целом, таких сторей по идее не должно быть. Любая сторька это либо новая фича, либо энхасмент/изменение уже реализованой. Если входных данных нет, то идём к PO с уточняющими вопросами или к аналитику, который эти требования писал. В любой непонятной ситуации надо уточнять.
@@rusau та вот был такой вопрос у меня. Намедни кстати. В итоге и сам узнал много нового. Но, как говорится, интервьюер хочет слышать конкретику. Я примерно так же ответил и мой ресурсный менеджер потом высказал своё возражение )) Ну это ж как обычно, частные случаи, но они, зачастую, очень влияют на общее впечатление ответа.
В общем если будет возможность с более детальным ответом, пошагово, буду признателен. А так же обязательно отвечу тот вариант, что мне был озвучен. Но все равно, спасибо за ответ и за контент. Настоятельно рекомендую всем знакомым, кто решил податься в куа)) в мое время таких каналов было очень мало, но все равно, апдейт по знаниям регулярно выполняю. Так как, все же, настаивают на сдаче ISTQB 🤷🏻♂️
Артём, добрый день! Подскажите, пожалуйста, в Вашем примере с велосипедом, который мы создали, но позже выяснилось, что неправильно, т.к. он для ребенка и должно быть 3 колеса, мы не можем сказать, что требования недостаточны (т.е не выполнено требование "завершённость")? т.к. одна из основных характеристик не указана.
Здравствуйте. Нигде не нашел примеров/шаблонов оформления тестирования требований и ТЗ. Могли бы поделиться? не понятно как это дело оформлять документально. Заранее спасибо!
Обычно просто комментарий к пользовательской истории с пунктами, которые нужно исправить. Далее перенаправить обратно задачу на специалиста, который ответственен за это. Какого-то общего шаблона нет.
Артём, а нет ли у тебя случаем контента на тему ролей в IT компаниях, кто за что отвечает, виды их коммуникаций и т.д.? Где-то читал что это тоже спрашивают на собеседованиях.
Привет! Подскажи, пожалуйста, *что за программа/сервис/сайт используется для рисования карты в ролике?* Очень крутая возможность скрывать ветки!!! Многие сервисы перепробовал, такую впервый раз вижу))
Артем , подскажи пожалуйста, где брать “требования”, если на проекте их нет. Пример: “Нужно протестить email”, прежде чем тестить, ведь надо понимать требования к нему. Я нашел много рукописных источников о валидации email, но должна ведь быть какая то унифицированная документация?! Буду благодарен за ответы. Всем добра) Артём, спасибо за твой труд!
Если требований нет, то как раз дело вступают неявные требования, которые ты перечислил. Плюс в любом случае на проекте есть разработчики или менеджеры, которые определяют, что надо делать. Надо общаться с командой и находить общий подход. Твои кейсы тоже станут своего рода требованиями
Требования есть всегда, так называемые неявные (в интернете много стаей про это). Можно изучить конкурентов, обратиться к разработчикам, использовать уже свой накопленный опыт и насмотренность. Для мобильных устройств есть гайдлайны, это по сути универсальные требования. Ваши написанные тест-кейсы тоже в будущем могут стать хранилищем требований.
Привет. Подскажи, нигде не могу найти такой ответ... Вот есть документация на страничку веб приложения, но нет самого приложения. Составляю я тест кейсы ( в виде тестовых идей). 200 штук например. Потом я получаю в руки готовую страничку приложения. И вот увидя веб приложение мне надо как-то изменить, дополнить эти тестовые идеи (так как я получил уже готовую страничку и мне приходят новые идеи тестирования). Так вот столько мароки и путаница возникает в этот момент...Изменяй, дополняй. Думаешь, что лучше бы сразу готовую страничку начать тестировать. И быстрее и меньше устаешь. ЧТо не так в этих рассуждениях?
Не так то, что это кажется простым решением, да и вроде бы веселее, но это только кажется. Надо уметь тесты дописывать/переписывать (иногда и убивать), и быстро, в едином потоке. Без планомерного системного подхода всегда будут глупейшие провтыки и баги буквально на ровном месте.
Вероятно, про уровни требований надо знать только то, что их можно разделить на два больших класса: * явные, * неявные. Отсюда появится привязка к верификации и валидации (тема, которую новички искренне считают ненужной шнягой, бо не понимают).
Таймкоды:
00:00 - Intro
00:49 - Уровни требований. Виды требований
03:27 - Пути выявления требований
06:09 - Свойства требований, как их тестировать?
12:22 - Как упростить тестирование требований?
15:25 - Способы представления требований (use case, user story)
21:35 - Почему важно уметь тестировать требования?
22:10 - Outro
а как называется прога где ты схемы в видео делаешь?
Спасибо за Ваш труд) 100 страниц из книги Куликова четко, понятно, интересно и за 20 минут! СПАСИБО)
Пожалуйста 😉
Куликов forever one love
было бы офигенно увидеть живой тест требований от автора)
Спасибо) Ваш канал- это "сокровище" для начинающего тестировщика)
Приятно слышать, спасибо!!
Поддерживаю! Спасибо 💙
Отрываю новое видео и сначал ставлю палец вверх, а потом слушаю.! Спасибо, Темыч за труд.
Пожалуйста ❤️ Правильная тактика)
Спасибо большое, что снимаете эти уроки. Благодаря именно им я учусь и понимаю всё в тестировании. Очень интересно и конкретно всё рассказываете!)
Спасибо и вам за обратную связь)
Спасибо за вашу помощь! Будьте здоровы и счастливы😊
Отличный урок! Благодарю за знания, невероятную атмосферу и содержание
Каждый урок что-то новое) Спасибо за работу.
Пожалуйста!
Артем, спасибо большое за канал! :) Очень структурированная информация и классная подача
Благодарю!
Отлично преподнесено. С меня подписка.Спасибо за труд и помощь в освоении материала. Артему -РЕСПЕКТ!!!
Благодарю!
Эту музыку в начале видео я узнаю из тысячи)) Не устану писать это - БЛАГОДАРЮ!!!
Спасибо, Ярослав)
Спасибо, учитель Артем! Очередной прекрасный урок.
Пожалуйста 😉
на одном из собеседований от меня хотели классификацию видов требований : Прямые и Косвенные. Может кому поможет эта информация при подготовке к собеседованиям. Артем молодец, все выпуски жду с нетерпением - все четко и понятно!
Пожалуйста!)
Спасибо!) Этот и правда сжатая и важная информация) подписка и лайк за труды!)
Пожалуйста!
Как всегда лучший учитель , вот Белорусы я замечаю всё чаще и чаще, очень софт люди, прям душки. Даже митинговали вставая на скамейки в носках, и вешая пакетики для мусора. Канал про истории людей с Беларуси смотрю, там даже обычный заводчанин настолько грамотно общается, настолько мягко и спокойно , что вот думаешь мы бы были друзьями 100% , так же и с Артёмом хочется дружить и слушать вечно)
Спасибо за добрые слова про беларусов)
Спасибо вам огромное за ваш труд и за то , что делитесь своими знаниями❤
Всегда пожалуйста!
Спасибо за урок!
Спасибо за Ваш труд
Требую требования к требованиям) пару раз нужно прогнать информацию, чтобы уложить в голову.
обожаю! спасибо Вам, все по полочкам!
Вот не успела досмотреть до этого ролика перед собеседованием и на вопросе про требования поплыла)))) Спасибо за канал!
Пожалуйста)
Дуже дякуємо за знання !
Спасибо, очень познавательно!
Супер спасибо
Спасибо за возможность обучения
Пожалуйста 😉
все по делу!
Откладывал просмотр и зря, очень важная тема. Но сложно представить как это на практике, если бы был разбор какие-то требований, как твой реальный кейс с работы, был бы шик и блеск.
Тоже подумала, что на практике было бы понятнее. Например разбор тестового задания: протестировать требования к полям ввода даты начала и окончания периода задолженности банку
Хоть прошло и много времени - никогда не поздно сказать спасибо, думаю). Очень ценно было найти вас в ютубе и благодаря вам всё идеально укладывается в голове. Даже Гит в вашем объяснении прошёл как по маслу. Если можно, хотела задать вопрос по этому видео: не очень поняла идею прототипирования, как пути выявления требований. Не очень понимаю, как связан прототип и анализ продукта конкурента, ведь прототип сам по себе это первоначальный образец. Буду очень благодарна, если поможете разобраться)
Супер! Спасибо. И подписка на телеграм канал)
Реально спасибо за курс!!!! Очень круто. Может после него получу оффер тестировщиком в Айти. Если уж другим способом не получается. Хотя в любом случае знания тестировщика лишними не будут точно. Еще раз огромное спасибо за курс. Респектую.
Пожалуйста! Надеюсь, что все получится)
привет, получил оффер?)
@@GrownAssMan17 нет. Я сейчас за си шарп взялся
@@АлександрТкаченко-п1ф, не пробовал даже? Просто сам уже скоро собираюсь начинать поиск первой работы и интересно, что да как.
Привет да пробовал. Меня сразу забородили
Поддержка 🤘так держать
Спасибо!
Спасибо
Thanks a bunch, pal)
мне все интерестно.
Мерси)
Спасибо за структурированную и понятную информацию. Читала несколько статей и видио, на тему требований. Исходя из них, хотела спросить. В критериях к качеству требований, встречается ещё такой пункт как реализуемость, в рамках выделенных ресурсов. Тоесть требование возможно выполнить, за то время, финансы, человеческие ресурсы, которые имеются в проекте.
Вопрос, исходя из твоего опыта, стоит ли указывать такой критерий на собеседовании, или это зависит от источника, и не обязательно упоминать об этом?
Пожалуйста, да, вполне можно) Я перечислил далеко не все свойства требований)
@@rusau Спасибо за ответ. Я тренируюсь по софт скилам, как преподнести замечание человеку, мнение которого уважаешь, чтобы не показаться грубым. Надеюсь получается😊
@@ВаляБучинська-п4ъ все хорошо 😉
@@rusau Спасибо!!! + к уверенности в себе😉
Хочу спросить только одно. Реально ли хватает полученных знаний из этих видео, чтоб устроиться на работу? Я знаю JS, HTML, CSS. Знаю некоторые другие вещи. Могу даже верстать, и делать разные прикалюхи на JS. Это просто мое хобби. В прослушанных видео, ничего запредельно сложного не уведел. Неужели за это могут взять на работу? Я в данный момент работаю на экскаваторе. До этого работал на грузовике. Деньги впринципе нормальные получаю, и на финансы не жалуюсь. Но реально жизнь на вахтах задолбала. Просто мне эти видео показались ну уж слишком простым. Все курсы предлогают миллион часов обучения, за миллион долларов денег. Пожалуйста дайте мне знать))))Просто если это так, так нахрена мне нужна жизнь в этом экскаваторе ?!)))))))
Привет. Для начинающего ручного тестировщика это необходимая база. Он не верстает и не пишет код, а должен понимать вообще что это, находить необходимые элементы, соотносить то, что наверстали другие, с тем, что нарисовали дизайнеры.
Помимо этого у него куча других активностей, о которых я рассказываю на своём канале.
А если ты хочешь во фронтэнд-разработку, то, конечно, это один процент от того, что тебе нужно знать.
И не стоит забывать, что конкуренция огромная и на одно место претендуют десятки специалистов. Так что лучше изучить рынок и разобраться в специальности, прежде чем что-то кардинально менять.
@@rusau Во фронтэнд собо не хочу. В тестровщики можно поробовать. Тема интересная. Я просто когда ради хохмы программировал и верстал, много что понял и в чем разобрался. Так что очень многое мне из этого понятно. Думаю может просто немного подтянуть знания в тестировании и попрактиковаться, и походить по собесам. Посмотреть что из этого выйдет.
Можно попробовать) Даже чисто для разведки
@@rusau тоже так думаю. К тому же поздней осенью и зимой, в моей сфере работы мало становится. Можно хоть обходиться.
А как технически выполняется тестирование требований? Допустим мне для составления тест кейсов прислали документ с требованиями к тому, как должны работать функции авторизации, регистрации и восстановления пароля, с подробным описанием того как должна вести себя система в тех или иных ситуациях. Я вижу, что в требованиях не описано много чего. Например, расписан сценарий восстановления пароля по почте, но не расписан сценарий восстановления по номеру телефона. Также много других упущений, противоречий, неточностей и тд. --- Я могу всё это подчеркнуть и на всё это указать прямо в этом же документе? Получается я должен отправить его назад в ожидании пояснений? Само тестирование в этом случае начинать пока нет смысла?
Приветствую 🖖 Спасибо за отличный контент. Вопрос следующий:
Если мне приходит юзер Стори, в которой просто указано, что данный функционал, должен работать так же как и ранее. То есть в описании задачи никакой информации детальной нет, есть лишь саммери и все. Какими должны быть действия тестировщика поэтапно?
Думаю, что такой вопрос будет интересен всем, так как его можно часто встретить на собеседовании. Спасибо!
Привет, пожалуйста.
В целом, таких сторей по идее не должно быть. Любая сторька это либо новая фича, либо энхасмент/изменение уже реализованой.
Если входных данных нет, то идём к PO с уточняющими вопросами или к аналитику, который эти требования писал.
В любой непонятной ситуации надо уточнять.
@@rusau та вот был такой вопрос у меня. Намедни кстати. В итоге и сам узнал много нового. Но, как говорится, интервьюер хочет слышать конкретику. Я примерно так же ответил и мой ресурсный менеджер потом высказал своё возражение )) Ну это ж как обычно, частные случаи, но они, зачастую, очень влияют на общее впечатление ответа.
В общем если будет возможность с более детальным ответом, пошагово, буду признателен. А так же обязательно отвечу тот вариант, что мне был озвучен. Но все равно, спасибо за ответ и за контент. Настоятельно рекомендую всем знакомым, кто решил податься в куа)) в мое время таких каналов было очень мало, но все равно, апдейт по знаниям регулярно выполняю. Так как, все же, настаивают на сдаче ISTQB 🤷🏻♂️
@@vladymyrst.6063 какой ответ в итоге надо бы дать, было бы интересно узнать
Артём, добрый день! Подскажите, пожалуйста, в Вашем примере с велосипедом, который мы создали, но позже выяснилось, что неправильно, т.к. он для ребенка и должно быть 3 колеса, мы не можем сказать, что требования недостаточны (т.е не выполнено требование "завершённость")? т.к. одна из основных характеристик не указана.
Да, можно отнести
Здравствуйте. Нигде не нашел примеров/шаблонов оформления тестирования требований и ТЗ. Могли бы поделиться? не понятно как это дело оформлять документально. Заранее спасибо!
Обычно просто комментарий к пользовательской истории с пунктами, которые нужно исправить. Далее перенаправить обратно задачу на специалиста, который ответственен за это. Какого-то общего шаблона нет.
@@rusau спасибо!
Артем, подскажи пожалуйста какую программу ты используешь для составления Mindmap ?
MindManager
Артем, а как же такие свойства как атомарность, выполнимость и обязательность? Мне кажется важные Свойства требований.
Есть такие. Про них тоже можно почитать
Артём, а нет ли у тебя случаем контента на тему ролей в IT компаниях, кто за что отвечает, виды их коммуникаций и т.д.? Где-то читал что это тоже спрашивают на собеседованиях.
Как вариант это видео th-cam.com/video/EvHNdpnBBWM/w-d-xo.html и урок 27
Подскажите, пожалуйста, как называется источник из istqb, syllabus?
Он самый. У меня есть видео про ISTQB на канале
как часто тебе приходилось тестировать требования за время своей работы?
Каждый день) Это обязательный этап после их написания. По крайней мере на моих местах работы)
Привет! Подскажи, пожалуйста, *что за программа/сервис/сайт используется для рисования карты в ролике?* Очень крутая возможность скрывать ветки!!! Многие сервисы перепробовал, такую впервый раз вижу))
mindmeister очень - тоже инструмент для создания интеллект-карт. Там как раз есть возможность скрывать ветки
Артем
, подскажи пожалуйста, где брать “требования”, если на проекте их нет. Пример: “Нужно протестить email”, прежде чем тестить, ведь надо понимать требования к нему. Я нашел много рукописных источников о валидации email, но должна ведь быть какая то унифицированная документация?! Буду благодарен за ответы.
Всем добра) Артём, спасибо за твой труд!
Если требований нет, то как раз дело вступают неявные требования, которые ты перечислил.
Плюс в любом случае на проекте есть разработчики или менеджеры, которые определяют, что надо делать. Надо общаться с командой и находить общий подход. Твои кейсы тоже станут своего рода требованиями
@@rusau Спасибо)
Подскажите, пожалуйста, как тестировать продукт без требований?
Требования есть всегда, так называемые неявные (в интернете много стаей про это). Можно изучить конкурентов, обратиться к разработчикам, использовать уже свой накопленный опыт и насмотренность. Для мобильных устройств есть гайдлайны, это по сути универсальные требования.
Ваши написанные тест-кейсы тоже в будущем могут стать хранилищем требований.
Привет. Подскажи, нигде не могу найти такой ответ...
Вот есть документация на страничку веб приложения, но нет самого приложения.
Составляю я тест кейсы ( в виде тестовых идей). 200 штук например. Потом я получаю в руки готовую страничку приложения. И вот увидя веб приложение мне надо как-то изменить, дополнить эти тестовые идеи (так как я получил уже готовую страничку и мне приходят новые идеи тестирования). Так вот столько мароки и путаница возникает в этот момент...Изменяй, дополняй. Думаешь, что лучше бы сразу готовую страничку начать тестировать. И быстрее и меньше устаешь.
ЧТо не так в этих рассуждениях?
Не так то, что это кажется простым решением, да и вроде бы веселее, но это только кажется. Надо уметь тесты дописывать/переписывать (иногда и убивать), и быстро, в едином потоке. Без планомерного системного подхода всегда будут глупейшие провтыки и баги буквально на ровном месте.
@@astenix Алексей мне вас рекомендовали пол года назад. У вас удивительно хороший материал и удивительно гадко надменное его представление.
@@wolfich4684 Да, вы правы, всё именно так.
Требования и ТЗ это одно и то же?
ТЗ может быть как техническое задание и быть требованиями, так и сокращением для тестового задания, которые присылают перед приглашением на интервью.
А где вы пишете свои mind-maps?!
MindManager
@@rusau спасибо 😉
👍🏽
Каковы дальнейшие планы?)
Закончить данный курс и начать новые по другим инструментам и/или вернуться к некоторым вопросам на более углубленном уровне) Планов много, идей тоже)
@@rusau огромное спасибо за твой труд!
@@user-ow1ji1mg3m пожалуйста)
Вероятно, про уровни требований надо знать только то, что их можно разделить на два больших класса:
* явные,
* неявные.
Отсюда появится привязка к верификации и валидации (тема, которую новички искренне считают ненужной шнягой, бо не понимают).
Столько просмотров и так мало лайков, жалко что ли 🤔
Мне одному послышалось "РАДИАТОР начинается с вешалки"?)))
Одному)
+
+++