Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Нужна критика/наставления по данным тест кейсам

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Добрый день.
Просьба посмотреть на написаные мной тест кейсы и сказать что не так, что так а чего там вообще не должно быть.

Объект тестирования: форма регистации сайта «dynamo.kiev.ua»
Ссылка на саму форму регистрации: goo.gl/kYh2s6
Тест кейсы: goo.gl/t3oFqS

Баг-репорты по рег. форме выложу позже.
Остальной сайт в процессе тестирования.
Закончу тестировать сайт — сразу скину им весь список найденных багов. Мне опыт — им лучшая версия сайта)

Огромное спасибо!
Буду очень очень признателен Всем!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

а почему не попробывать автоматизировать эти сценарии имхо это может быть интересней ?

Сейчас изучаю это вопрос — буду пробовать.

Случайно зашел в ветку, посмотрел. Делюсь мнением — Вы врядли пройдете собеседование на КуА! Первое, главное, отсутствие приоритезации кейсов и требований. Почему у Вас сплошной негатив ? первыми должны быть позитивные тесты. Затем, я всегда всем говорю — никогда не использовать в описании «Try» — это девочку можно трайнуть на кофе, а в тесткейсе должно быть действие четко выраженное, если есть сомнения в успешности, то это + сценарии позитивные и негативные. Зачем Вы требования назвали прекондишенами ? Одной из основных философий тестирование является воспроизводимость успешных или неуспешных резултатов — Вы же оставляете на откуп тестировщика+человеческий фактор(типа All valid data), я бы применил жесткие константы к валидным/невалидным данным, однако убрал бы константы с UI контролов. Вот пример, классика собеседования:
DYN-PRE-003 требует от 3 до 30.
DYN-REG-009 и DYN-REG-010 -ок
DYN-REG-017 и DYN-REG-018 — не годится так как 1 и 10001 попадают по Ваши критерии но не являются границей диапазона
DYN-REG-019 и DYN-REG-020 — бессмысленны так как покрыты в DYN-REG-017 и DYN-REG-018 соотв.

Спасибо за комментарий.
Почерпнул для себя много полезного из него — обязательно учту это.
И приложу максимум усилий что бы собеседование пройти.

И вопрос к Лупану. На вашем сайте написано
«Ввeсти в поле логина правильный логин, начинающийся с нескольких пробелов, и правильный пароль. Expected: alert.»

— вопрос: зачем там алерт?
К примеру в Facebook, Browserstack и думаю бог знает где еще нету алерта и это здорово. Юзвери бывает копируют емейл из ворда и допускают пробел в начале/конце

Ну если не будет алерта, а функция авто удаления пробелов перед логином не предусмотрена? Или просто удачно не подключена. Что потом будет делать юзвер когда попытается залогинется с емейлом, но уже без пробелов? Восстановление пароля и саппорт?

Хотя я конечно не Алексей Лупан

В ФБ и тд таки да, пробелы «игнорируются», и это здорово. На самом деле, они не игнорируются, а отдельно обрабатываются. То есть, программист вынужден скрипеть креслом и заниматься и этой «мелочью». Ну или во фреймворках уже зашито, и об этом даже думать не надо. А тогда надо было думать, бо магазин был самописный, фреймворк сугубо внутренний, и если будет сбой, то со стороны никто не поможет.

Если вводим логин, но перед ним ставим пробел — это уже неправильный логин, бо пробел — тоже символ, который с точки зрения кантупира имеет право на жизнь. Например, есть у меня блог, в котором логин выглядит как ’Слово Слово’ - там пробел внутри, и все ок. Уберу пробел — будет фэйл, а не логин.

Когда это записывалось, рассуждал так: поскольку пробел символ, но «неявный» (можно и не заметить, в чем проблема), то пусть лучше система о нем сообщит, нежели юзер будет методично расследовать причину сбоя. Ну или самостоятельно уберет, чтобы двурукого не злить.

Ого расписал тест кейсов! У меня вопрос к тестировщикам. Вы тоже тестируете регистрацию используя такое кол-во тест-кейсов? И каждый новый релиз вы по всем ним проходитесь?)

TC в теме не читал. Обычно да, тестов очень много, но автоматизированы же

Первая задача тестировщика — всё предусмотреть.

А для этого нужно всё продумать. А не «Давайте искать только самые важные баги»...

А с чем связан выбор гуглодрайва? Почему бы не посмотреть в сторону простых тест-менеджмент систем?

Решил для начала выяснить правильным ли я путем вообще иду.
А потом со временем уже практиковаться на зверях побольше.

А што ж так мало тест кейсов и ниочем. Хотел скинуть ссылку Лупана где расписаны проверки полей логин пароль, но вижу он уже тут. А вообще дальше второго тест кейса читать трудно, засыпать начинаю

Дима, ты не тест-кейсы пишешь. Ты просто описываешь то, что видишь на экране (причем излишне подробно), и исходишь из того, что если все шаги будут воспроизводиться, то и приложение работает as expected. Это принципиально неверно. Все так начинают делать, и потом никак не поймут, почему чем дальше, тем хуже получается. Врубись в то, что означает ’test case’, и почему оно так называется.

Вместо:
1. Input into «Адрес електронной почты» field valid email in lower case
2. Filling up other fields by valid data
3. Press button «Зарегистрироваться»
пиши так:
«Проверить, что можно зарегистрировать почтовый адрес, который написан только заглавными буквами».

Зачем писать тесты на английском языке, если приложение сплошь русскоязычное?
«1. Keep „Пароль“ and „Подтверждение пароля“ fields blank
2. Filling up other fields by valid data
3. Press button „Зарегистрироваться“» — смешно же.

У тест-кейсов должны быть заголовки. Тоже, кстати, уникальные.

Не надо просто пересказывать требования, или писать что-то вроде ’try to...’ Кейсами проверяются требования. Зачастую одно простое требование легко может\должно быть проверено аж десятком кейсов, а не только одним.

Понял.
Буду пробовать по новой и исправляться.
Спасибо Вам, Алексей, за такой полезный подзатыльник в нужном направлении :)
Побольше бы их...

Присоединюсь к мнению по поводу англйского. Но раз уж описываете поведение на иностранном языке, придерживайтесь проверки грамматики и пользуйтесь спеллчекером для проверки написания слов. К примеру, вместо be open -> be opened. Если это страница, то она не «открыла» (opened), а «открылась».

В ближайшем будущем — обязательно, надо наверстать упущенное. Сейчас к сожалению никак(

Оформлялось на английском, для того что бы освежить свои знания в нем. Устная практика была в принципе регулярно, а вот письменной — не было давненько. А теперь вот результат на лицо.
Спасибо.
Буду стараться.

Смысл выставлять пару тест кейсов?
Такое ощущение, что не понимаешь смысл слова Precondition. PREcondition — условие которое должно быть удовлетворено ПЕРЕД началом теста. Например, юзер должен быть залогиненным.
Поменяй формат.
Как вариант:
|Номер(или ID) | REG — 01|
|Название тест-кейса | Registration with valid data|
| Шаги |1) Go to dynamo.kiev.ua/user/registration ;2) Fill the fields:..
|Ожидаемый результат|User is registered|

Не нужно переписывать требования, просто опиши по шагам, без лишних слов, как будет проходить тест.

Согласен. С Precondition немного напутал. Учту. Спасибо.

Если честно не совсем понял что Вы имеете ввиду говоря

Смысл выставлять пару тест кейсов?
Для меня смысл в том что бы набраться опыта, набить пару шишек и сделать с этого выводы.

Ну как сказать... Несерьёзно, что ли. )
Это всё равно, что судить об умении писать сочинения по одному предложению)
Ведь и тест-кейсы должны составлять относительно полную картину о качестве тестируемого софта.)

Коментар порушує правила спільноти і видалений модераторами.

Какое количество тест кейсов должно быть, и какой примерный объем тестирования должен быть проведен, по Вашему мнению, что бы это считалось серьезным?
Должен быть протестирован весь сайт результат представлен к рассмотрению?

Это всё равно, что судить об умении писать сочинения по одному предложению)
Тут я с Вами не согласен полностью. Если начальное предложение будет в стиле «дерево бежало в воздух кот улетел за зарплатой двери му Страдивари» то думаю можно предоставить какое и сочинение будет. Конечно если это сочинение пишется под какими то грибами — то да, оно может считаться правильным.

Та же беда думаю и с тест кейсами — даже если их будет три штуки, и они будут не правильно оформлены — то еще 300шт таких же ситуацию не улучшат.
К чему веду — я выложил свои тест кейсы для формы регистрации, что бы как раз и узнать правильно ли я их пишу, где ошибки, что изменить, что добавить или убрать.
Можно конечно протестировать весь сайт, потом дать кому то посмотреть, что бы узнать что вся проделанная работа в априори не верна и является полной чушью. Вот это бы было по-моему точно не серьезно — куча потраченного времени и ресурсов — в открытый космос. Тогда как можно было просто спросить, еще на начальной стадия, у знающих людей «я правильно делаю?».

Объём тестирования зависит от требований, хотелок клиента, наличия времени и других ресурсов.

2 тест-кейсами можно показать как ты умеешь описывать тест-кейсы, но невозможно увидеть насколько хорошо ты умеешь, находить что-ли, нужные тест-кейсы.

Понятно.
Видимо мы с Вами находимся на разных полюсах понимания. Думаю не стоит больше припираться по данному вопросу.
Спасибо!
Выводы сделал.

Попытаюсь объяснить, что хотела сказать Лариса.
Процесс тестирования не начинается с написания тестовых случаев.
Вообще, тестирование как процесс ставит задачу оценки и повышения качества тестируемого объекта в отведенное время.
Иными словами, если у заказчика на тестирование есть месяц — то через месяц заказчик должен получить твои выводы касательно качества данного объекта — готов ли он к использованию, какие остались проблемы, их влияние на возможность использования это объекта и т.д.
Если ты сделаешь работу в 100 тыщ раз лучше, но за 2 месяца — это будет никому не нужно, рынок уже изменился, конкуренты выпустили что-то похожее, заказчик не получил долю на рынке и т.д.
Таким образом, твоя задача всегда ставится так: сделать максимум в заданное время.
Исходя из этого, первична задача по приоретизации направлений тестирования: функциональность, более критичная для тестируемого объекта, имеет более высокий приоритет, нежели менее критичная. Например, для сайта будет более важна функциональность авторизации (если ты не смог залогиниться — тебе как пользователю уже неважно, что всё остальное работает идеально — ты не можешь этим пользоваться), нежели, например, отображение сайта в IE 5.0, которым никто не пользуется.
Далее, критична полнота тестирования: насколько твои тесты покрывают существующую функциональность? Нет ли непротестированной функциональности? Почитай про матрицу прослеживаемости (traceability matrix).

Это если очень коротко, буквально в 2-х словах. Очень много я не затронул — иначе придётся книжку писать )))

Дмитрий, я прекрасно понимаю о чем выговорите. Знаю, что тестирование это далеко не одни тест кейсы и баг репорты, а еще и уйма других вещей. Так же я прекрасно понимаю что время — деньги, и никто не будет ждать пока кто то там, ковыряясь в носу, что то протестует и сдаст работу через n-недель, когда оно уже никому не надо.
Хотя до этого не работал в тестировании и в разработке ПО (только учился на программиста), но знаю что такое сроки сдачи, и чем чреваты их срывы.
Но данный топик был открыт с целью оценки и критики написаных мной «тест кейсов» (если их можно еще так назвать))) ) для формы регистрации на готовом давно работающем сайте. В данном случае никакого заказчика нету. Заказчик я сам, так как мне нужна практика, и в написание кейсов в том числе.
Для меня это проект самообучения, целью которого является повышение своего уровня знаний, и в будущем — первая работа в сфере тестирования. Очень хочется вырваться из цикла
IF experience ≤ 0 THEN
PRINT «Опыта нет — работы нет»
Как то так...

Хотите увеличить шансы, займитесь автоматизацией. Сейчас вы глупостями занимаетесь.
Делать правильные ТС с точки зрения оформления научитесь в первый день на реальной работе, покрытие так проверять неудобно — матрицей лучше (но валидировать на форуме это никто не будет), и.т.д. и т.п.
А вот если вы автоматизируете весь этот процесс (в данном случае не сложно, т.к. ТС простые) — уже получите «плюс в карму» на интервью. Дальше делаем сложнее и сложнее. После, сканером на инджекты что-нибудь проверить.

Честно говоря я немного боюсь распылиться на все и не получить ничего. Сейчас и так подтягиваю тестирование, HTML, CSS, SQL и учу JavaScript. В планах на будуще — Selenium, Java или Python.
Хотелось бы структурировать и закрепить знания по тому что уже знаю и только потом браться за Selenium, Java или Python. Может конечно что то и не надо из этого будет, но такой багаж за спиной не носить, так что учу.
Не хочется дополнительной каши в голове)

Если учился на программиста, то зачем идти в мануальные тестировщики???

Видимо мы с Вами находимся на разных полюсах понимания.
Увы, в этом проблема и трудность общения с противоположным полом касательно рабочих процессов. Даже если этот пол работает в IT, это не значит что логический аппарат работает корректно(

Підписатись на коментарі