Отлично, благодарю 👍 Я опытный айтишник с 15ти летним стажем в области транспорта газа и внедрения SCADA систем. У меня 6 лет перерыва в практике и я хочу вернуться в сферу для дистанционного заработка - живу в Эквадоре! Для меня это всё более чем понятно и вопрос только в терминологии инструментах. Скоро, чувствую, буду в теме - осталось купить компьютер - в этом состояла основная трудность. Ещё раз благодарю за информацию 🤝
Тест-кейс (это конечно не все, я думаю что если все буду писать, ютуб не разрешить опубликовать такой длинный коментарий) Ошибки: 1. Напротив 2-го шага нет ожидаемого результата. Ожидаемый результат : “в поле ввода появится 1+” 2. В названии проверки не однозначно указано, каких именно кнопок. Т.к. на верхних кнопках калькулятора находятся не числа, а знаки %, корень, возведение в степень и дробь. (Весь тест-кейс некорректен и требует переработки) 3. предусловие Б и В, нужно сделать шагами 4. В данном тест-кейсе, много опечаток и грамматических ошибок. В шаге 3 “Нажать кнопку разделить” ожидаемый результат: “в поле ввода появится -22,11÷”. 5. Не хватает шага вычитание между 1 и 2 шагом. Как должно выглядеть: шаги: ожидаемый результат: 1 Ввести число 123 при помощи клавиатуры В поле ввода отображается 123 2 Нажать кнопку “-” В поле ввода отображается 123- 3 Ввести число 120 при помощи клавиатуры В поле ввода отображается 120 4 Нажать кнопку “=” В поле ввода отображается 3 Вопросы на собесе: 1. В чем отличие между тест-кейсом и чек листом? Тест-кейс - это набор последовательных действий на проверку какого-либо функционала программы с прописанными шагами и ожидаемым результатом. Чеклист - это идеи того, что можно проверить в продукте и не факт, что эти идеи попадут в тест-кейсы для проверки. В тест-кейсах описывается каждый шаг подробно, а вот в чеклистах кратко. 2. Отличие высокоуровневых и низкоуровневых тест-кейсов? Высокоуровневый тест-кейс он краток и не всегда понятен джуну, в то время как в низкоуровневом тест-кейсе полностью прописаны каждые шаги, что куда и как. Из высокоуровневого тест-кейса всегда можно сделать низкоуровневый. С низкоуровневым легче работать. 3. Отличие Test suite от test case? Тест сюьт это набор тест кейсов, которые отвечают за множество целей, в то время как тест-кейс отвечает за 1 цель 4. Обязательные атрибуты тест-кейса? В обязательные атрибуты входят: номер, предусловие, шаги, ожидаемый результат, статус, комментарии 5. Чем тест-кейс отличается от баг-репорта? Баг-репорт - это артефакт тестирование, который информирует разработчика об ошибки. Это отчет Тест-кейс - это артефакт тестирования, который направлен на проверку какого-либо функционала. Это ТЗ
Леша, ты умный парень и я уверен многово добьешься. В плане обучения много трудно понимаемых определений(объясняешь по простому и по сложному, но в результате все очень сложно и не совсем понятно). Определения должны быть короткими. И очень мало примеров из практики. Теория хорошо запоминается когда ты сразу приводишь пример из жизни. Хотя извлёк из твоих лекций много полезного. Спасибо!
Алексей, спасибо! Вы очень понятно, доступно объясняете материал! Попала под сокращение в феврале и уже год не работаю тестировщиком, многое позабылось.. Повторяю по вашим видео теорию в том числе.
1) Я бы добавил в предусловия либо пост-условия "обнуление". Иначе в поле ввода уже может быть что-то, что исказит тест. 2) Для операций я бы прописал поведение калькулятора, иначе не понять были ли нажата кнопка операции или нет. 3) Проверка ввода с клавиатуры 4) ЛКМ мне кажется писать излишне. 5) В названии не указано, что мы проверяем правильность операций )) просто сложение и вычитание. 6) Не хватает негативных кейсов и обработки исключений, хотя возможно они ниже 8) Опечаток много в словах. 9) Возможно я бы вынес все значения в таблицу с данными. Это если прям быстро не особо думая :)
Дз 1. Отличие чек листа от тест кейса: 1. Чек лист содержит идеи проверок,а не пошаговое руководство, как т.кейс 2.чек лист проще обормляется и может нагляднее из-за этого выглядит, особенно если он представлен схемой. 3. Чек л. Легко, быстро изменить, при необходимости (добавить, убавить, исправить пункты проверок) Когда нужно выбрать чек лист/тест кейса? 1. Если специалист достаточно опытен, чтобы не тратить время на создание по шаговой инструкции 2. И наоборот если нужно создать точную инструкцию по разным причинам (не опытен специалист, или нужна точно проверить фенкцию). Тогда тест кейс 3. Если разночтения идей проверок идут на пользу, так как расширяют потенциалтные пользовательские пути, то чек лист 4. Если нужны конкретные тестовые данные, тогда тест кейс Дз 2 Идеи тестов для калькулятора 1. Возведение степени в степень 2. Попробовать ввод данных вместо цифр буквы или символы (тере, слеш и прочее) 3. Проверить порядок и правильность выполнения вычислений при сочетании разных действий (пример: сложение и умножение. Или минус и степень)
Тест-кейс - инструмент тестировщика для непосредственного тестирования ПО, Баг репорт - это занесение в базу дефекта, обнаруженного при прохождении тест-кейса (тест-комплекта) с последующей его передачей разработчику
Я думаю, что главное отличие тест-кейса от баг репорта заключается в том, что в баг репорте даётся конкретное описание, что пошло не так или не работает, а не просто ставится статус FAILED как в тест-кейсе. Так же в баг репорте даётся оценка уровня бага: не критичный, критичный, блокирующий.
Тест-кейс от баг-репорта отличается тем, что тест-кейс - это артефакт, целью которого является проверка определённой идеи, определённого пути. И в результате может быть не выявлено дефектов. Баг-репорт же составляется когда баг выявлен и его необходимо исправить)
И ещё: номер 11. Если мы будем вводить подряд все цифры , то в поле ввода будет сначала 1, потом 12, потом 123... То есть, ожидаемый результат не совсем такой, как указано.
Здравствуйте! Ошибки, которые я нашла: 1) номер 3. Мне кажется, Предусловия Б и В нужно сделать шагами. 2) в номерах 4, 6, 7, 9, 10, 12, 14 в некоторых шагах не написано , каким образом ввести числа - с клавиатуры или с помощью ЛКМ 3) номер 5. Проверяем вычитание, но не хватает шагов - собственно, нажатие на минус и на равно. 4) номер 8. Посмотреть на кнопки циферблата. Какого циферблата? Что это за циферблат, где он? 5) номер 12. Предусловие: в поле ввода пусто. А если нет? Что делать в этом случае? 6) номер 13. Предусловие: калькулятор в режиме Инженерный. А если нет? В ожидаемом результате : открывается обычный режим калькулятора, (здесь сомневаюсь) нужно ли здесь более подробное описание, как определить , что это обычный режим ( где это написано), или это уже нарушение правила Упрощай ? 7) номер 15. То, что написано в шагах , скорее похоже на идею, но не на подробные шаги .
И еще вопрос относительно "1 кейс - 1 цель": если мы применяем попарное тестирование и сразу в одном тесте учитываем несколько параметров, то получается, что мы несколько целей проверяем, разве не так?
Подскажите, пожалуйста, по следующему моменту. Когда дают тестовое задание составить тест-кейс для проверки какой-то странички, то насколько исчерпывающий список ожидают? Потому что я в ступор впадаю, если честно, когда задумываюсь о том, сколько всего можно проверить - неужели все-все-все это нужно описывать для простого тестового задания, да еще и в подробном виде тест-кейсов? Или большинство нанимателей устроит пример нескольких позитивных и негативных ТК с упоминанием, что можно еще сделать так-то и так-то? И еще вопрос, связанный с тестовыми данными: если проверять, например, форму покупки товара, то ок написать в шагах какого-нибудь Ивана Петрова с конкретным адресом доставки в Москве и т.д. или нужно как-то так заворачивать мысль, чтобы можно было любых Маш и Сереж с соседних улиц туда подставить? Не представляю, как сделать это лаконично, понятно и универсально одновременно...
Ну, тест кейс это описание совокупности шагов, условий и параметров, необходимых для проверки тестируемой функции, а баг репорт-отчет о найденных багах/ошибках
Алексей, подскажите, считается ли нормальной практикой организовать процесс тестирования без использования тестовой документации, а именно чек-листов и тест-кейсов? Возможно ли, тестировать только методом исследовательского тестирования, опираясь на какую-то базу знаний о продукте? Насколько страдает качество продукта в выборе такого подхода? Сталкивались ли вы с такой ситуацией на реальном проекте?
Не сталкивался. Потому что это нельзя считать полноценным тестированием. Это скорее зародышь. Исследовательское тестирование может быть как часть большего процесса. Если остановиться только на нем, то не будет нормального качества . Можно попробовать начать с этого и внедрять остальные технологии тестирования. Но это только в самом карйнем случае
Дз Ошибки в тест кейсе: 1. В тест кейсе #5 пропущен шаг: назвать кнопку -. Это надо было додумать по логике. Правило полноты не соблюдено 2. В т.к. #10 в одном кейсе, 2, не 1 цель. : Первое, сбросили данные об операции, а второе стоило в отдельный тест вывести, там где проверили, что 2 =2 без дополнительных действий 3. #11, принцип полноты нарушен, так как если соблюдать шаги подряд ввести 1, потом 2, то должно отображаться 12, а не 2, тут либо не хватает шага стереть данные, либо автор т.к. опечатался и нарушил принцип однозначности заодно 4. #15 нет детальных шагов для выполнения. Не все находится в одном месте, не понятно где искать virtual box, чтобы его запустить. И как внутри него открыть калькулятор
К сожалению, или к счастью, но опечатков очень много. Это считается за ошибками? (На всякий случай пропишу, в №4 "Отображается" и "число"; №10 " калькулятор " и в названии проверки "о проведённых операциях" ). В №5 в ОР после 2 шага отобразилось неверное число. Либо Баг , либо ошибка тестировщика. В №8 ,мне кажется(хочу у вас уточнить), в шагах указано "посмотреть ..." может более грамотно будет написать "проверить параметры кнопок" или "кнопки одного размера/параметра"?. И, в каждой проверке на стадии сложения/деления ОР не прописан, так и должно быть или это как раз ошибка в тк?
А по атрибутам тест-кейса я бы добавил ещё помимо ожидаемого результата фактический результат ибо статус не всегда даёт полное понимание того как повёл себя тестируемый продукт мне кажется. Как считаете, Алексей?
Вы скорее всего перепутали тест-кейс с баг репортом, когда тест-кейс пишется ещё никакого фактического результата нету, но вот в баг репорте это обязательный пункт
14:50 а разве Вы не говорили 2 минуты назад, что нужно упрощать шаги? "Нажать ЛКМ на цифру 3" - как раз пример того, как писать не стоит. Думаю, 99,99% людей понимают, какую кнопку мыши нажимать. А так похоже на то, как я своих престарелых родителей обучаю пользованию компьютером))
@@Sirina-o1 тут еще другой момент. Кейсы нужно создавать так, чтобы при каких-то незначительных изменениях не приходилось менять другие. Например, в программе сделают все наоборот - для действия нужно нажимать ПКМ, а не ЛКМ. В таком случае все кейсы, где говорится "нажмите ЛКМ" придется менять, а их могут быть сотни. В таком случае указание "нажмите на цифру 3" является примером оптимизации.
А зачем тест кейсу фактический результат? Его могут проходить огромное количество раз. Каждый раз будешь писать новый фактический результат? А зачем тогда нужен баг репорт, если все эти атрибуты можно писать в тест кейсах?
Там дублирование действия, в предусловием было что складываете 2+2=4, а потом просто повторно нажимаете =, и действие дублируется, и внутри выполняется к результату 4, снова 2 и равно 6. Увидела в комментариях идею, что это стоило прописать в шагах, а не предусловии, как вариант ошибки) мне показалось разумное предложение)
Вы выполняете прекрасную миссию просвещать будущих коллег своим "титаническим" трудом. Если здесь комментирующие исправляют Ваши или других ошибки, значит это кому-нибудь нужно и укрепит память о грамматике русского языка. Спасибо Вам.Вы добрый человек!
Отлично, благодарю 👍
Я опытный айтишник с 15ти летним стажем в области транспорта газа и внедрения SCADA систем. У меня 6 лет перерыва в практике и я хочу вернуться в сферу для дистанционного заработка - живу в Эквадоре! Для меня это всё более чем понятно и вопрос только в терминологии инструментах. Скоро, чувствую, буду в теме - осталось купить компьютер - в этом состояла основная трудность.
Ещё раз благодарю за информацию 🤝
купили?\
Тест-кейс (это конечно не все, я думаю что если все буду писать, ютуб не разрешить опубликовать такой длинный коментарий)
Ошибки:
1. Напротив 2-го шага нет ожидаемого результата. Ожидаемый результат : “в поле ввода появится 1+”
2. В названии проверки не однозначно указано, каких именно кнопок. Т.к. на верхних кнопках калькулятора находятся не числа, а знаки %, корень, возведение в степень и дробь. (Весь тест-кейс некорректен и требует переработки)
3. предусловие Б и В, нужно сделать шагами
4. В данном тест-кейсе, много опечаток и грамматических ошибок. В шаге 3 “Нажать кнопку разделить” ожидаемый результат: “в поле ввода появится -22,11÷”.
5. Не хватает шага вычитание между 1 и 2 шагом. Как должно выглядеть:
шаги: ожидаемый результат:
1 Ввести число 123 при помощи клавиатуры В поле ввода отображается 123
2 Нажать кнопку “-” В поле ввода отображается 123-
3 Ввести число 120 при помощи клавиатуры В поле ввода отображается 120
4 Нажать кнопку “=” В поле ввода отображается 3
Вопросы на собесе:
1. В чем отличие между тест-кейсом и чек листом?
Тест-кейс - это набор последовательных действий на проверку какого-либо функционала программы с прописанными шагами и ожидаемым результатом. Чеклист - это идеи того, что можно проверить в продукте и не факт, что эти идеи попадут в тест-кейсы для проверки. В тест-кейсах описывается каждый шаг подробно, а вот в чеклистах кратко.
2. Отличие высокоуровневых и низкоуровневых тест-кейсов?
Высокоуровневый тест-кейс он краток и не всегда понятен джуну, в то время как в низкоуровневом тест-кейсе полностью прописаны каждые шаги, что куда и как. Из высокоуровневого тест-кейса всегда можно сделать низкоуровневый. С низкоуровневым легче работать.
3. Отличие Test suite от test case?
Тест сюьт это набор тест кейсов, которые отвечают за множество целей, в то время как тест-кейс отвечает за 1 цель
4. Обязательные атрибуты тест-кейса?
В обязательные атрибуты входят: номер, предусловие, шаги, ожидаемый результат, статус, комментарии
5. Чем тест-кейс отличается от баг-репорта?
Баг-репорт - это артефакт тестирование, который информирует разработчика об ошибки. Это отчет
Тест-кейс - это артефакт тестирования, который направлен на проверку какого-либо функционала. Это ТЗ
Леша, ты умный парень и я уверен многово добьешься. В плане обучения много трудно понимаемых определений(объясняешь по простому и по сложному, но в результате все очень сложно и не совсем понятно). Определения должны быть короткими. И очень мало примеров из практики. Теория хорошо запоминается когда ты сразу приводишь пример из жизни. Хотя извлёк из твоих лекций много полезного. Спасибо!
Алексей, спасибо! Вы очень понятно, доступно объясняете материал! Попала под сокращение в феврале и уже год не работаю тестировщиком, многое позабылось.. Повторяю по вашим видео теорию в том числе.
Здорово, что учтены замечания к прошлым урокам. Надеюсь и дальше уроки будут также проиллюстрированы схемами и примерами. Спасибо за труд.
огромное спасибо, хорошо, что вы есть
Спасибо за твою работу! Очень помогает !
у вас такой голос приятный, слушать одно удовольствие, материал лучше заходит))
1) Я бы добавил в предусловия либо пост-условия "обнуление". Иначе в поле ввода уже может быть что-то, что исказит тест. 2) Для операций я бы прописал поведение калькулятора, иначе не понять были ли нажата кнопка операции или нет. 3) Проверка ввода с клавиатуры 4) ЛКМ мне кажется писать излишне. 5) В названии не указано, что мы проверяем правильность операций )) просто сложение и вычитание. 6) Не хватает негативных кейсов и обработки исключений, хотя возможно они ниже 8) Опечаток много в словах. 9) Возможно я бы вынес все значения в таблицу с данными.
Это если прям быстро не особо думая :)
Дз 1.
Отличие чек листа от тест кейса:
1. Чек лист содержит идеи проверок,а не пошаговое руководство, как т.кейс
2.чек лист проще обормляется и может нагляднее из-за этого выглядит, особенно если он представлен схемой.
3. Чек л. Легко, быстро изменить, при необходимости (добавить, убавить, исправить пункты проверок)
Когда нужно выбрать чек лист/тест кейса?
1. Если специалист достаточно опытен, чтобы не тратить время на создание по шаговой инструкции
2. И наоборот если нужно создать точную инструкцию по разным причинам (не опытен специалист, или нужна точно проверить фенкцию). Тогда тест кейс
3. Если разночтения идей проверок идут на пользу, так как расширяют потенциалтные пользовательские пути, то чек лист
4. Если нужны конкретные тестовые данные, тогда тест кейс
Дз 2
Идеи тестов для калькулятора
1. Возведение степени в степень
2. Попробовать ввод данных вместо цифр буквы или символы (тере, слеш и прочее)
3. Проверить порядок и правильность выполнения вычислений при сочетании разных действий (пример: сложение и умножение. Или минус и степень)
Тест-кейс - инструмент тестировщика для непосредственного тестирования ПО,
Баг репорт - это занесение в базу дефекта, обнаруженного при прохождении тест-кейса (тест-комплекта) с последующей его передачей разработчику
Спасибо за курс!
Я думаю, что главное отличие тест-кейса от баг репорта заключается в том, что в баг репорте даётся конкретное описание, что пошло не так или не работает, а не просто ставится статус FAILED как в тест-кейсе. Так же в баг репорте даётся оценка уровня бага: не критичный, критичный, блокирующий.
Главное отличие тест-кейса от баг репорта заключается в том, что Баг-репорт(это отчёт об ошибки), а Тест-кейс(это тестовый случай)
( Отчёт об ошибкЕ)
1) упрощение можно не писать лкм
2)опечатка + в шагах можно добавить 4 ряд где есть 0 =
3)в предусловии обезличеность + опечатки
4)опечатки + обезличеность в (шаги "введите цифры")
5)опечатки + обезличеность (название проверки "вычесть цифры" )
6)опечатки + обезличеность (название проверки "умножить цифры") + (шаги упрощение нажать кнопку лкм)
7)обезличеность (название проверки " сложить цифры = сложение чисел " ) + (шаги упрощение нажать на кнопку лкм)
8) не полная информация (на какие кнопки циферблата нажать)
9)упрощение(шаги "кнопку лкм на кнопку
обезличеННость)
@@allakoalla5993 какой ты молодец 👍
Тест-кейс от баг-репорта отличается тем, что тест-кейс - это артефакт, целью которого является проверка определённой идеи, определённого пути. И в результате может быть не выявлено дефектов. Баг-репорт же составляется когда баг выявлен и его необходимо исправить)
баг репорт не всегда является описанием бага ;)
@@oleksandrsemishan1869 например?
Алексей, спасибо вам за такие видео и домашние задания)))
Здорово, что предупредили об ошибках в таблице Т-К и обострили внимание смотрящих коллег.
Спасибо за видео
И ещё: номер 11. Если мы будем вводить подряд все цифры , то в поле ввода будет сначала 1, потом 12, потом 123... То есть, ожидаемый результат не совсем такой, как указано.
Большое спасибо за отличное видео! Очень рад что на вас подписался!
Здравствуйте!
Ошибки, которые я нашла:
1) номер 3. Мне кажется, Предусловия Б и В нужно сделать шагами.
2) в номерах 4, 6, 7, 9, 10, 12, 14 в некоторых шагах не написано , каким образом ввести числа - с клавиатуры или с помощью ЛКМ
3) номер 5. Проверяем вычитание, но не хватает шагов - собственно, нажатие на минус и на равно.
4) номер 8. Посмотреть на кнопки циферблата. Какого циферблата? Что это за циферблат, где он?
5) номер 12. Предусловие: в поле ввода пусто. А если нет? Что делать в этом случае?
6) номер 13. Предусловие: калькулятор в режиме Инженерный. А если нет?
В ожидаемом результате : открывается обычный режим калькулятора, (здесь сомневаюсь) нужно ли здесь более подробное описание, как определить , что это обычный режим ( где это написано), или это уже нарушение правила Упрощай ?
7) номер 15. То, что написано в шагах , скорее похоже на идею, но не на подробные шаги .
Спасибо большое!
Супер спасибо
И еще вопрос относительно "1 кейс - 1 цель": если мы применяем попарное тестирование и сразу в одном тесте учитываем несколько параметров, то получается, что мы несколько целей проверяем, разве не так?
Тест кейс делается когда обнаружена ошибка/неисправность или всё что мы только тестировали?
А вообще хотел написать СПАСИБО!!!!!!! 👍🤝🤝🤝
Алексей, вы не добавили данный урок в плейлист к остальным 15
Хорошей практикой считается конкретный результат и конкретные вводимые значения? Или можно оставить это на откуп того, кто будет делать тест кейс?
всё чётко и ясно! правда в Excel максимально не понял за VirtualBox, зачем и для чего
Все видео размыто
Когда новые уроки?
Подскажите, пожалуйста, по следующему моменту. Когда дают тестовое задание составить тест-кейс для проверки какой-то странички, то насколько исчерпывающий список ожидают? Потому что я в ступор впадаю, если честно, когда задумываюсь о том, сколько всего можно проверить - неужели все-все-все это нужно описывать для простого тестового задания, да еще и в подробном виде тест-кейсов? Или большинство нанимателей устроит пример нескольких позитивных и негативных ТК с упоминанием, что можно еще сделать так-то и так-то? И еще вопрос, связанный с тестовыми данными: если проверять, например, форму покупки товара, то ок написать в шагах какого-нибудь Ивана Петрова с конкретным адресом доставки в Москве и т.д. или нужно как-то так заворачивать мысль, чтобы можно было любых Маш и Сереж с соседних улиц туда подставить? Не представляю, как сделать это лаконично, понятно и универсально одновременно...
привет, как успехи? Смогла выполнить задание, взяли на работу?
Ну, тест кейс это описание совокупности шагов, условий и параметров, необходимых для проверки тестируемой функции, а баг репорт-отчет о найденных багах/ошибках
Алексей, подскажите, считается ли нормальной практикой организовать процесс тестирования без использования тестовой документации, а именно чек-листов и тест-кейсов?
Возможно ли, тестировать только методом исследовательского тестирования, опираясь на какую-то базу знаний о продукте? Насколько страдает качество продукта в выборе такого подхода? Сталкивались ли вы с такой ситуацией на реальном проекте?
Не сталкивался. Потому что это нельзя считать полноценным тестированием. Это скорее зародышь. Исследовательское тестирование может быть как часть большего процесса. Если остановиться только на нем, то не будет нормального качества . Можно попробовать начать с этого и внедрять остальные технологии тестирования. Но это только в самом карйнем случае
Зародыш(Ь)- слово мужского рода и окончание мягкого знака после шипящих не пишется, а вот в словах женского рода пишется: рожь, течь, молодёжь
Где можно скачать эту табличку для домашнего задания?
Где-нибудь можно посмотреть презентации к урокам?
1) при нажатии кнопки - или + в поле ожидаемый результат не чего не указано( а должно быть указано появление -,+.
2) в поле ожидаемый результат не указана кнопка 0
"ничего" надо писать слитно
5)пропущен шаг нажать кнопку+,-
А как может быть не зависимость, если для всего остального, нужно быть авторизованным на сайте или в приложении, или это прописывается в предусловии?
Здравствуйте. Подскажите, тест кейсы - это то же самое, что и тестовые сценарии? И атрибуты тест кейса такие же, как и у тестовых сценариев?
Да
@@flankes3339 спасибо!
Дз
Ошибки в тест кейсе:
1. В тест кейсе #5 пропущен шаг: назвать кнопку -. Это надо было додумать по логике. Правило полноты не соблюдено
2. В т.к. #10 в одном кейсе, 2, не 1 цель. : Первое, сбросили данные об операции, а второе стоило в отдельный тест вывести, там где проверили, что 2 =2 без дополнительных действий
3. #11, принцип полноты нарушен, так как если соблюдать шаги подряд ввести 1, потом 2, то должно отображаться 12, а не 2, тут либо не хватает шага стереть данные, либо автор т.к. опечатался и нарушил принцип однозначности заодно
4. #15 нет детальных шагов для выполнения. Не все находится в одном месте, не понятно где искать virtual box, чтобы его запустить. И как внутри него открыть калькулятор
Уроков больше не будет? (
Баг-репост - это отчёт об ошибки. Найдя баг, заводят отчёт(баг-репорт)
Сложилось ощущение что обилие грамматических ошибок в таблице с заданием было призвано отвлечь от основной сути задания
К сожалению, или к счастью, но опечатков очень много. Это считается за ошибками? (На всякий случай пропишу, в №4 "Отображается" и "число"; №10 " калькулятор " и в названии проверки "о проведённых операциях" ).
В №5 в ОР после 2 шага отобразилось неверное число. Либо Баг , либо ошибка тестировщика.
В №8 ,мне кажется(хочу у вас уточнить), в шагах указано "посмотреть ..." может более грамотно будет написать "проверить параметры кнопок" или "кнопки одного размера/параметра"?.
И, в каждой проверке на стадии сложения/деления ОР не прописан, так и должно быть или это как раз ошибка в тк?
Лёша, в комментах уже перечисленны основные ошибки. Но есть ещё - путаешь понятия цифра и число :)
А по атрибутам тест-кейса я бы добавил ещё помимо ожидаемого результата фактический результат ибо статус не всегда даёт полное понимание того как повёл себя тестируемый продукт мне кажется. Как считаете, Алексей?
Вы скорее всего перепутали тест-кейс с баг репортом, когда тест-кейс пишется ещё никакого фактического результата нету, но вот в баг репорте это обязательный пункт
Thanks
Лутанулся както тут нехило. Теперь местный чел здесь)🐵
Что ты имеешь ввиду?
А что такое артифакты ? Не менее запудренное определение !
с сентября "домашка" не проверялась ...(((
Тест-кейсы говорят как система задумана работать, а баг-репорты описывают где, когда и как реальность отличается от ТЗ
Спасибо за контент, но не упомянуты end-to-end тесты...
Тест - кейс помогает выяснить есть ли ошибка, а баг - репорт фиксирует дефект, который уже нашли.
Да, и ещё я так понимаю отличие то что что баг-репорт заполняется в спец программе. В xl таблице его точно не сделаешь, в отличие от чек листа
Ещё 11) в разделе ожидания есть логическая ошибка, запрос на ожидания не соответствует логике
Я знаю что бак Репорты это некая ошибка которую пропустили, или не сделали.. По крайней мере в играх так
А почему в обязательных атрибутах нет фактического результата?
Откуда в тест кейсе фактический результат ? Нет такого пункта в тест кейсе .
@@leshamarshal А, ну да, разобрался
@@leshamarshal как раз главное различие тест-кейса и баг репорта)
Добрый день! Есть ЛКМ аббревиатура. Существует ли на английском такие? Спасибо!
Есть точно такое же сокращение только от английских слов и это LMB (лкм) и RMB (пкм)
@@DrakonchikAngel нашла другое значение для LMB на английском и хотела уточнить :))
@@CristinaTudorean мб перепутали с BLM?
14:50 а разве Вы не говорили 2 минуты назад, что нужно упрощать шаги? "Нажать ЛКМ на цифру 3" - как раз пример того, как писать не стоит. Думаю, 99,99% людей понимают, какую кнопку мыши нажимать. А так похоже на то, как я своих престарелых родителей обучаю пользованию компьютером))
Если эта аббревиатура уже применима, то почему бы об этом и не сказать.
@@Sirina-o1 тут еще другой момент. Кейсы нужно создавать так, чтобы при каких-то незначительных изменениях не приходилось менять другие. Например, в программе сделают все наоборот - для действия нужно нажимать ПКМ, а не ЛКМ. В таком случае все кейсы, где говорится "нажмите ЛКМ" придется менять, а их могут быть сотни. В таком случае указание "нажмите на цифру 3" является примером оптимизации.
Добрый день. У баг - репорта есть Фактический результат, а у тест - кейса нет
А зачем тест кейсу фактический результат? Его могут проходить огромное количество раз. Каждый раз будешь писать новый фактический результат? А зачем тогда нужен баг репорт, если все эти атрибуты можно писать в тест кейсах?
@@ГеоргийВелинский Так я ответил чем они отличаются, читайте пожалуйста внимательней !)
Разве 2+2=6
120 отображается 3
🤔🤔🤔
Там дублирование действия, в предусловием было что складываете 2+2=4, а потом просто повторно нажимаете =, и действие дублируется, и внутри выполняется к результату 4, снова 2 и равно 6. Увидела в комментариях идею, что это стоило прописать в шагах, а не предусловии, как вариант ошибки) мне показалось разумное предложение)
+
По-моему он просто хочет шобы мы покупали у него уроки и поэтому решил не выпускать новые ролики
Не. Все прозаичнее. Я записывал курс по мобилкам. Очень уж его просили
Вы выполняете прекрасную миссию просвещать будущих коллег своим "титаническим" трудом. Если здесь комментирующие исправляют Ваши или других ошибки, значит это кому-нибудь нужно и укрепит память о грамматике русского языка. Спасибо Вам.Вы добрый человек!
Правило НЕЗАВИСИМОСТЬ ничего непонятно🤷
спасибо, хорошо и толково, приятно что размеренно