Сообщений в теме: 73

[Ekaterina1995_JuniorQA]

 

 

А зачем вам смоук и критикал при задании "Протестируйте"?

 

Задания как такового нет) Просто я представила, что столкнулась с таким функционалом и как мне рассуждать. Да и вообще, попав на сайт, как мне действовать.К примеру, есть сайт РЖД, как мне нужно его тестировать.

Я бы сказала так.

1.Функциональное тестирование

2. Тестирование безопасности (секьюрити)

3. Тестирование производительности

4. тестирование UI

5. Тестрование удобства использования

6. Тестирование локализации

7. А дальше идеи опять заканчиваются.

Но может мой подход в корне неверен и кто-то может аргументировать и подсказать, как с этой стороны подходить к тестированию.

Отсюда я себе поставила задачу на первое задание - протестировать.

Для начала выбрала функциональное тестирование и решила разложить его по уровням, первым написала проверки для smoke, но быстро идеи закончились(

 

вы выбрали не тот уровень абстракции. Задача составления плана тестирования, а то, что вы написали выше, это именно план тестирования, делается не путём перечисления всех применимых к продукту видов тестирования, а на основе востребованности заказчиком и проектом в целом указанных видов, с расчётом на финансовую составляющую и остальные не менее важные аспекты, такие как загруженность персонала и наличие денег на привлечение нового персонала. 

 

В общем вам необходимо тренироваться в первую очередь в составлении плана функционального тестирования, а уже потом переходить на следующий уровень абстракции. Таким образом вы поймёте как оценить время и ресурсы на следующем уровне.

 

 

Хорошо, давайте так. 1. заказчику очень надо.2. денег безлимит .3.все аспекты не важны.4. должен выдерживать всех людей на планете.5. команда безлимитная.

Я просто хочу подход понять, как подойти к тестированию и какие виды применять к реальным проектам. Ваши темы и риски( к этому еще вернемся, когда будет общее понимание у меня). А как тренироваться, если я написала план формы и столкнулась с проблемой, а помощи нет, одни непонятные для меня уходы в сторону(

 

Мой первый пост говорит о том, что там и составлен план на функциональное тестирование, но я тоже в тупик зашла и мне требуется помочь. А с РЖД это уже вторая задача.

[Ekaterina1995_JuniorQA]

 

 

 

 

 

 

Я вот понимаю, что Вы хотите (наверное)

Я бы протестировал на критикал пас:

1. Заполнить одну форму(необязательную) - отправить - посмотреть результат

2. Заполнить второю форму(необязательную) - отправить - посмотреть результат

3. Заполнить обе формы(необязательные) - отправить - посмотреть результат

4. Тоже самое проделал со всеми невалидными значениями.

5. Попробовал в обязательное валидное, а в дстальные - невалидные.

В общем хз, что тут еще можно придумать

 

 

Спасибо! Хоть один человек пока что меня услышал!!! Но я не уверена, что это именно critical path , возможно к extended.

[Ekaterina1995_JuniorQA]

Коллеги, это джун.) Может мне так везло, но 95% вообще не рассуждают как Екатерина, а сразу как по приказу "Протестировать" тупо кейсы пишут)))

Спасибо, приятно кончено, но толку от моих рассуждений, если они завели меня в тупик (нехватку знаний). И более опытные участники по факту пытаются навязать мне другие подходы (которые тоже будут обсуждаться), но хочется обсудить мою точку зрения!

[Ekaterina1995_JuniorQA]

Вы ставите абстрактные задачи и даете на них сферические ответы)) С вашим опытом лучше брать конкретные задачи работодателя, а не пытаться тнстировать клней в вакууме:) Сейчас видно только перечисление видов тестирования( я вижу)
Про сайт РЖД. Тестировать безопасность не надо, вряд ли вас об этом спросят. Что именно вы собрались тестировать на локализацию? Тестирование производительности вы напрямую через сайт тоже вряд ли сделаете.
Сосредоточтесь лучше на вопросе как тестировать, а не что.

P.S. Сергей оченрь тщательно относится к кандидатам, так что вам плюс))

Я ставлю такие задачи,как мне легче всего воспринять информацию. Для этого я привела пример и рассуждение, поэтому мне бы хотелось просто услышать продолжение моего рассуждения(где я в тупике оказалась) либо корректировки на самом этапе рассуждения.

"Тестировать безопасность не надо, вряд ли вас об этом спросят."  - тут не в этом подход спросят или нет. Мы тестировщики, мы не должны строить предположения.

По локализации. (Сайт РЖД) значит есть скорее всего возможность выбора языка (минимум Eng), максимум (+++). Проверяем все ли переведено. Все ли надписи поместились в свои lable. Переведен ли placeholder. Не поплыл ли контект и не развалилась ли структура сайта (там как немецкий язык занимает больше места).

 

По моему я и сосредоточена на том, как тестировать, а вы меня в сторону "что" склоняете(

[Ekaterina1995_JuniorQA]

Коллеги, это джун.) Может мне так везло, но 95% вообще не рассуждают как Екатерина, а сразу как по приказу "Протестировать" тупо кейсы пишут)))

 и еще хотелось бы услышать,как рассуждают те 5% кандидатов.

 

А за бис хотелось бы услышать рассуждения Вас по данной форме, а я выступлю заказчиком и могу отвечать на ваши вопросы)

[Vasiliy]

Вы ставите абстрактные задачи и даете на них сферические ответы)) С вашим опытом лучше брать конкретные задачи работодателя, а не пытаться тнстировать клней в вакууме:) Сейчас видно только перечисление видов тестирования( я вижу)
Про сайт РЖД. Тестировать безопасность не надо, вряд ли вас об этом спросят. Что именно вы собрались тестировать на локализацию? Тестирование производительности вы напрямую через сайт тоже вряд ли сделаете.
Сосредоточтесь лучше на вопросе как тестировать, а не что.
P.S. Сергей оченрь тщательно относится к кандидатам, так что вам плюс))

Я ставлю такие задачи,как мне легче всего воспринять информацию. Для этого я привела пример и рассуждение, поэтому мне бы хотелось просто услышать продолжение моего рассуждения(где я в тупике оказалась) либо корректировки на самом этапе рассуждения.
"Тестировать безопасность не надо, вряд ли вас об этом спросят."  - тут не в этом подход спросят или нет. Мы тестировщики, мы не должны строить предположения.
По локализации. (Сайт РЖД) значит есть скорее всего возможность выбора языка (минимум Eng), максимум (+++). Проверяем все ли переведено. Все ли надписи поместились в свои lable. Переведен ли placeholder. Не поплыл ли контект и не развалилась ли структура сайта (там как немецкий язык занимает больше места).
 
По моему я и сосредоточена на том, как тестировать, а вы меня в сторону "что" склоняете(

Ок. Если как, то расскажите как вы будете тестировать функциональность сайта? Я пока этого не увидел.
Про локализацию - хорошо, там понятно направление.
Подход у вас верный, но вы вывалили столько верхнеуровневых тем, что это похоже на "я буду тестировать все!". А это не самое верное рассуждение, имхо

[Ekaterina1995_JuniorQA]

 

 

Вы ставите абстрактные задачи и даете на них сферические ответы)) С вашим опытом лучше брать конкретные задачи работодателя, а не пытаться тнстировать клней в вакууме:) Сейчас видно только перечисление видов тестирования( я вижу)
Про сайт РЖД. Тестировать безопасность не надо, вряд ли вас об этом спросят. Что именно вы собрались тестировать на локализацию? Тестирование производительности вы напрямую через сайт тоже вряд ли сделаете.
Сосредоточтесь лучше на вопросе как тестировать, а не что.
P.S. Сергей оченрь тщательно относится к кандидатам, так что вам плюс))

Я ставлю такие задачи,как мне легче всего воспринять информацию. Для этого я привела пример и рассуждение, поэтому мне бы хотелось просто услышать продолжение моего рассуждения(где я в тупике оказалась) либо корректировки на самом этапе рассуждения.
"Тестировать безопасность не надо, вряд ли вас об этом спросят."  - тут не в этом подход спросят или нет. Мы тестировщики, мы не должны строить предположения.
По локализации. (Сайт РЖД) значит есть скорее всего возможность выбора языка (минимум Eng), максимум (+++). Проверяем все ли переведено. Все ли надписи поместились в свои lable. Переведен ли placeholder. Не поплыл ли контект и не развалилась ли структура сайта (там как немецкий язык занимает больше места).
 
По моему я и сосредоточена на том, как тестировать, а вы меня в сторону "что" склоняете(

Ок. Если как, то расскажите как вы будете тестировать функциональность сайта? Я пока этого не увидел.
Про локализацию - хорошо, там понятно направление.
Подход у вас верный, но вы вывалили столько верхнеуровневых тем, что это похоже на "я буду тестировать все!". А это не самое верное рассуждение, имхо

 

 

Хорошо,давайте рассуждать.

1. Сайт предназначен для покупки билетов/ просмотра расписания - это значит, что есть некая функциональность,а значит первое - функциональное тестирование

2. через сайт можно купить билеты и иметь личный кабинет, значит обязательно нужно безопасность тестировать

3.Так как на сайте покупают билеты и многие покупают пересадочные билеты, то сайт должен стабильно работать в любое время - значит тестирование стабильности (Perfarmance)

4. На сайте есть акции и какие-то выгодные предложения (либо перед праздником), когда кол-во людей одновременно что-то покупающий  - максимальный - значит проверить load (сможет ли он выдержать 50 млн человек в один момент( по ТЗ 50 млн) - это тоже (Perfarmance)

5. А вдруг какая-то акция и будет 60 млн человек - stress testing (Perfarmance)

6. Допустим 70 млн человек и сайт перестал отвечать - значит нужно посмотреть,как быстро он вернется к работе после перезапуска и что с ним произойдет (recoveriability) (Perfarmance)

7. Далее можно посмотреть, а как оформлены кнопки (цвет, рамки, читаем ли надписи на однотипном фоне, достаточно ли большие буквы, номер телефона и т.д)

8. Далее можно проверить usability (Можем ли мы заказать билет или будет час искать эту ссылку, расположение меню, главная информация на видных местах, удобная ли навигация)

9. Далее проверим локализацию Проверяем все ли переведено. Все ли надписи поместились в свои lable. Переведен ли placeholder. Не поплыл ли контект и не развалилась ли структура сайта (там как немецкий язык занимает больше места).

 

Подводя итог мы провели функциональное (пункт 1) и нефункциональное тестирование (остальные пункты). Только насчет тестирования безопасности есть вопросы куда его отнести.

 

10 После того,как все проведено(протестировано) и соответствует ТЗ и готовый Сайт уже на локальном сервере - мы проводит acceptance testing На соответствие acceptance criteria. Если тест пройден - запускаем сайт. Если нет, то на этап ремонта bugs отправляем!

 

Есть в моих словах правда?) Либо объясните как нужно подойти к этому вопросу)

[user12]

Сначало было про простенькую форму, потом внезапно про сайт РЖД, потом предложение на работу, хотя "недавно устроилась на фирму на испытательный срок" :)

 

"Смешались в кучу кони, люди" (с)

 

Вам же писал Василий:

Вы ставите абстрактные задачи и даете на них сферические ответы)) С вашим опытом лучше брать конкретные задачи работодателя, а не пытаться тнстировать клней в вакууме

[Ekaterina1995_JuniorQA]

Если вы обратите внимание, то это не я, а участники беседы на эти темы меня сами вывели. Мой вопрос про форму - это смысл топика.

 

Давайте абстрагируемся от моего опыта!

 

Про "простенкую" форму я так и не услышала рекомендаций, только один Евгений что-то внятное ответил.

Про РЖД с Василией начали общаться, может быть и получится диалог)

[Vasiliy]

"2. через сайт можно купить билеты и иметь личный кабинет, значит обязательно нужно безопасность тестировать"
Почему? Одно из другого никак не следует. Я, как заказчик, верю своим разработчикам, которые говорят, что закрыто и никто не проникнет. А еще это дорого и можно отложить на полгода, когда будет бюджет.

[Ekaterina1995_JuniorQA]

"2. через сайт можно купить билеты и иметь личный кабинет, значит обязательно нужно безопасность тестировать"
Почему? Одно из другого никак не следует. Я, как заказчик, верю своим разработчикам, которые говорят, что закрыто и никто не проникнет. А еще это дорого и можно отложить на полгода, когда будет бюджет.

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

[Little_CJIOH]

 

Вот это как раз упомянутое вами отсутствие английского языка. Леша об этом очень хорошо написал в свое время https://testitquickl...tdewBiq3X-Cith0

 

смоук - это "надо же, не взорвалось"

критикал пас - "надо же, работает"

а экстендед (вообще впервые слышу) - это уже анекдот про суровых сибирских мужиков и японскую пилораму.

 

Что-то я не могу понять!

 

По степени важности тестируемых функций тестирование делится на:

 

Дымное тестирование – проверка самой важной функциональности программного продукта.

Тестирование критического пути – проверка функциональности, используемой типичными пользователями в повседневной деятельности.

Расширенное тестирование – проверка всей заявленной функциональности.

 

Дымное тестирование - проверили,что при заполнении обязательного поля - прога регистрирует, проверили, что без его заполнения - не регистрирует. (самое важное проверили,значит можно дальше идти)

Тестирование критического пути - есть еще два поля и можно проверить, как они влияют на нашу регистрацию + проверить обязательное поля на всекие невалидные данные.

Расширенное тестирование – проверка всей заявленной функциональности. .на форме ее нет, Но если бы был (допкутим) некий фильтр, который сортирует это поля (обязательное поле сверху либо снизу отображать), то он бы попадал в расширеное(екстендед) тестирования.

 

Зачем вы переводите термины, если потом плюете на смысловое значение перевода и начинаете объяснять что он значит?

Смоук - приложение в принципе запустилось. Не значит что работает, просто не падает само по себе. Включили? дым не повалил? - смоук тест пройден. Термин пришел из электроники из которой реально валит дым если что-то принципиально неправильно собрано

Критикал пас - работает функциональность без которой не работает бизнес. Когда вы говорите "самое важное" - это и есть critical path, путь которым пользователь получает ценность.

[DReeborn]

Я тоже являюсь джуном, но о этой херне(видах и методах тестирования) с первого дня вообще не думал. Первые полтора месяца я занимался только исследовательским тестированием т.к. документации нет вообще. 4 платформы и везде приложение ведёт себя по разному. ИМХО исследовательское тестирование первое чему надо учится.

После этого я начал понимать работу приложения и знать как оно работает в разных ситуациях лучше чем кто-либо ещё из моей небольшой команды. Также станет понятно как работает команда и как тебе примерно туда входить. Поймёшь какое требуется качество продукта, что важнее, а на что вообще можно забить. Притрёшься к команде в конце концов, узнаешь как разработчики едят баги и с чем их надо подавать.

С этими знаниями ты уже будешь иметь общую картину и уже сможешь оптимизировать её и улучшать. В моём случае кейсы излишне и займут слишком много времени для поддержки, поэтому я ввёл чек листы которые весьма легко поддерживаются и помогают организовать тестирование. Теория тестирования это оптимизация процесса, улучшение его эффективности и уменьшение затратности. В корне это просто умение поставить раком систему, а теория тестирования это уже вопрос о том, что система раком нам даёт.

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

[Ekaterina1995_JuniorQA]

Я тоже являюсь джуном, но о этой херне(видах и методах тестирования) с первого дня вообще не думал. Первые полтора месяца я занимался только исследовательским тестированием т.к. документации нет вообще. 4 платформы и везде приложение ведёт себя по разному. ИМХО исследовательское тестирование первое чему надо учится.

После этого я начал понимать работу приложения и знать как оно работает в разных ситуациях лучше чем кто-либо ещё из моей небольшой команды. Также станет понятно как работает команда и как тебе примерно туда входить. Поймёшь какое требуется качество продукта, что важнее, а на что вообще можно забить. Притрёшься к команде в конце концов, узнаешь как разработчики едят баги и с чем их надо подавать.

С этими знаниями ты уже будешь иметь общую картину и уже сможешь оптимизировать её и улучшать. В моём случае кейсы излишне и займут слишком много времени для поддержки, поэтому я ввёл чек листы которые весьма легко поддерживаются и помогают организовать тестирование. Теория тестирования это оптимизация процесса, улучшение его эффективности и уменьшение затратности. В корне это просто умение поставить раком систему, а теория тестирования это уже вопрос о том, что система раком нам даёт.

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

 

Это замечательно, но мне кто-нибудь ответит на вопрос или будет пытаться убедить в чем-то своем?) Исследовательское  тестирование тоже требует определенных подходов, а не просто по сайту лазить!

[Ekaterina1995_JuniorQA]

 

 

Вот это как раз упомянутое вами отсутствие английского языка. Леша об этом очень хорошо написал в свое время https://testitquickl...tdewBiq3X-Cith0

 

смоук - это "надо же, не взорвалось"

критикал пас - "надо же, работает"

а экстендед (вообще впервые слышу) - это уже анекдот про суровых сибирских мужиков и японскую пилораму.

 

Что-то я не могу понять!

 

По степени важности тестируемых функций тестирование делится на:

 

Дымное тестирование – проверка самой важной функциональности программного продукта.

Тестирование критического пути – проверка функциональности, используемой типичными пользователями в повседневной деятельности.

Расширенное тестирование – проверка всей заявленной функциональности.

 

Дымное тестирование - проверили,что при заполнении обязательного поля - прога регистрирует, проверили, что без его заполнения - не регистрирует. (самое важное проверили,значит можно дальше идти)

Тестирование критического пути - есть еще два поля и можно проверить, как они влияют на нашу регистрацию + проверить обязательное поля на всекие невалидные данные.

Расширенное тестирование – проверка всей заявленной функциональности. .на форме ее нет, Но если бы был (допкутим) некий фильтр, который сортирует это поля (обязательное поле сверху либо снизу отображать), то он бы попадал в расширеное(екстендед) тестирования.

 

Зачем вы переводите термины, если потом плюете на смысловое значение перевода и начинаете объяснять что он значит?

Смоук - приложение в принципе запустилось. Не значит что работает, просто не падает само по себе. Включили? дым не повалил? - смоук тест пройден. Термин пришел из электроники из которой реально валит дым если что-то принципиально неправильно собрано

Критикал пас - работает функциональность без которой не работает бизнес. Когда вы говорите "самое важное" - это и есть critical path, путь которым пользователь получает ценность.

 

 

Это понятно, но! Вы предлагаете мне веб форму включить в розетку? ))))) А все манипуляции с обязательным полем в critical path записать? А все остальные - это Extended?

[DReeborn]

 

Я тоже являюсь джуном, но о этой херне(видах и методах тестирования) с первого дня вообще не думал. Первые полтора месяца я занимался только исследовательским тестированием т.к. документации нет вообще. 4 платформы и везде приложение ведёт себя по разному. ИМХО исследовательское тестирование первое чему надо учится.

После этого я начал понимать работу приложения и знать как оно работает в разных ситуациях лучше чем кто-либо ещё из моей небольшой команды. Также станет понятно как работает команда и как тебе примерно туда входить. Поймёшь какое требуется качество продукта, что важнее, а на что вообще можно забить. Притрёшься к команде в конце концов, узнаешь как разработчики едят баги и с чем их надо подавать.

С этими знаниями ты уже будешь иметь общую картину и уже сможешь оптимизировать её и улучшать. В моём случае кейсы излишне и займут слишком много времени для поддержки, поэтому я ввёл чек листы которые весьма легко поддерживаются и помогают организовать тестирование. Теория тестирования это оптимизация процесса, улучшение его эффективности и уменьшение затратности. В корне это просто умение поставить раком систему, а теория тестирования это уже вопрос о том, что система раком нам даёт.

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

 

Это замечательно, но мне кто-нибудь ответит на вопрос или будет пытаться убедить в чем-то своем?) Исследовательское  тестирование тоже требует определенных подходов, а не просто по сайту лазить!

 

 

Если вы ожидаете, что кто-то вам скажет какие кейсы делать, то зря. Даже "рекомендации" т.к. они просто могут ввести вас в заблуждение. Вам сразу об этом сказали: "Вы ставите абстрактные задачи и даете на них сферические ответы". Хотите научится рассуждать, решайте реальные задачи в реальной компании с реальными людьми.

[Ekaterina1995_JuniorQA]

 

 

Я тоже являюсь джуном, но о этой херне(видах и методах тестирования) с первого дня вообще не думал. Первые полтора месяца я занимался только исследовательским тестированием т.к. документации нет вообще. 4 платформы и везде приложение ведёт себя по разному. ИМХО исследовательское тестирование первое чему надо учится.

После этого я начал понимать работу приложения и знать как оно работает в разных ситуациях лучше чем кто-либо ещё из моей небольшой команды. Также станет понятно как работает команда и как тебе примерно туда входить. Поймёшь какое требуется качество продукта, что важнее, а на что вообще можно забить. Притрёшься к команде в конце концов, узнаешь как разработчики едят баги и с чем их надо подавать.

С этими знаниями ты уже будешь иметь общую картину и уже сможешь оптимизировать её и улучшать. В моём случае кейсы излишне и займут слишком много времени для поддержки, поэтому я ввёл чек листы которые весьма легко поддерживаются и помогают организовать тестирование. Теория тестирования это оптимизация процесса, улучшение его эффективности и уменьшение затратности. В корне это просто умение поставить раком систему, а теория тестирования это уже вопрос о том, что система раком нам даёт.

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

 

Это замечательно, но мне кто-нибудь ответит на вопрос или будет пытаться убедить в чем-то своем?) Исследовательское  тестирование тоже требует определенных подходов, а не просто по сайту лазить!

 

 

Если вы ожидаете, что кто-то вам скажет какие кейсы делать, то зря. Даже "рекомендации" т.к. они просто могут ввести вас в заблуждение. Вам сразу об этом сказали: "Вы ставите абстрактные задачи и даете на них сферические ответы". Хотите научится рассуждать, решайте реальные задачи в реальной компании с реальными людьми.

 

 

Давайте разберем реальную задачу из реальной компании с реальными людьми.

1. У меня будет тестирование формы регистрации, будет 5 обязательных и 10 необязательных полей, мне нужно дать эстимацию для smoke тестирования. По сути то, что я спросила первым постом, причем привела рассуждения свои, только в более простой форме (1 обязательное вместо 5 и 2 необязательных вместо 10).

 

Увы, комментариев по делу не было, все пиняли, на реальные задачи, только не понимаю, с чего они сделали вывод, что задача нереальна.

[Ekaterina1995_JuniorQA]

Ребята, шел 4ый день, а кроме " ты джуниор - делай реальные задачи". Только я не понимаю, чем приведенные задачи нереальны....

[BadMF]

Давайте разберем реальную задачу из реальной компании с реальными людьми.

 

 

1. У меня будет тестирование формы регистрации, будет 5 обязательных и 10 необязательных полей, мне нужно дать эстимацию для smoke тестирования. По сути то, что я спросила первым постом, причем привела рассуждения свои, только в более простой форме (1 обязательное вместо 5 и 2 необязательных вместо 10).

 

Увы, комментариев по делу не было, все пиняли, на реальные задачи, только не понимаю, с чего они сделали вывод, что задача нереальна.

 

 

 

Екатерина, в вашем упрощённом примере нечего рекомендовать и тд. Это очень простой пример, по одному позитивному тесту на каждое поле + проверка незаполнености + проверка негатива + в зависимости от платформы специфичные тесты + проверка записи в БД (если оно есть !!! этот функционал так же должен быть заявлен) при сценарии. Т.е. вам нужно проверить заявленный (!!!) функционал каждого поля, плюс заявленный (!!!) функционал каждой кнопки и то что это потом где-то хранить, если храниться. Писать на такое ответ в 100 раз дольше чем о нём подумать.

В данном конкретном случае, смоук тестирование не нужно. Окей, предположим что нужно: проверяем что форма открывается, самая важная кнопка жмётся без взрыва монитора (прости Г_спади за киношный штамп).

Критикал тесты - происходит валидация обязательных полей, происходит запись в БД (если это заявлено !!!)

Системное тестирование (я не знаю термина "расширенное тестирование") будет покрывать проверку каждого поля  СОГЛАСНО ЗАЯВЛЕННОМУ ФУНКЦИОНАЛУ (!!!).

 

Ну и на последок. Если у вас нет "заявленного функционала", вам НЕОБХОДИМО прежде чем что-то тестировать, его заявить. Таким образом, мы приходим к выводу, что тестировщик должен тестировать ТОЛЬКО заявленный функционал! Если в функционале НЕ заявлено, что данные должны быть защищены, то это значит что это никому не нужно.

 

Я ответил на ваш вопрос достаточно развёрнуто?

[BadMF]

 

Коллеги, приветствую!

 

.....

 

Пожалуйста, поправляйте меня, если мои рассуждения окажутся некорректными.

 

Пункт 1:

1. Я не знаю, что это за форма, но есть спецификация (скорее всего)  - "НЕТ". 

 

Это значит, что вы должны эти требования полностью написать. Нельзя тестировать то, что не ясно как работает. И для начала, по хорошему, провести тестирование требований. Проведя тестирование требований, вы скорее всего уже найдёте несколько ошибок. В принципе, всегда полностью читайте ТЗ для разработчиков прежде чем начать что-то делать по тестированию. Так же в технической части ТЗ для разработчиков должны быть параметры каждого поля (длинна, ширина, высота, и тд и тп).

 

2. Тогда какие были условия, что это форма появилась - "не знаю, наверное, пользователь хочет зарегистрироваться на сайте"

Это не принципиально. Если будете задаваться данным вопросом при тестировании формы, будет только хуже.

 

3.Что будет являться успешной регистрацией? какое-то сообщение? - "Вы зарегистрированы"

Это должно быть ясно из ТЗ. если ТЗ нет - СМОТРИТЕ КОД!

 

4. Соответственно нажатие на кнопку Register приведет к появлению этого сообщения при корректном заполнении формы? - "Да"

Это должно быть ясно из ТЗ. если ТЗ нет - СМОТРИТЕ КОД!

 

5. Мы должны просто увидеть сообщение и этого будет достаточно для утверждения, что мы зарегистрированы, либо должны быть соблюдены еще некие условия, например, запрос к базе данных? - "делайте два варианта"

Это должно быть ясно из ТЗ. если ТЗ нет - СМОТРИТЕ КОД!

 

6. А какой тип данных поддерживается данными полями? - "текст(символы) и цифры"

Это должно быть ясно из ТЗ. если ТЗ нет - СМОТРИТЕ КОД!

 

7. (1 вариант): 'Значит я вижу, что ОБЯЗАТЕЛЬНЫМ является только одно поле'. Отсюда делаю вывод, что для тестирования smoke мне понадобится проверить:

a.  Ввести valid data (пример: Ekaterina95) в поле nickname и нажать Registratio. - Expected result - "Вы зарегистрированы".

б. Empty input in mandatory field and click Registration - должно появится некое сообщение, но не  такие: "Вы зарегистрированы". Нужно уточнить!

Это должно быть ясно из ТЗ. если ТЗ нет - СМОТРИТЕ КОД!

 

8. А какие сообщение появляется при неудачной регистрации по причине:

a/ Ничего не введено

б/ Введено что-то отличное от текста и цифр

в/ Такой пользователь уже имеется в системе

г. Введено слишком короткое либо слишком длинное значение (Кстати - нужно уточнить)! - на все будет один ответ "Отказано!"

Это должно быть ясно из ТЗ. если ТЗ нет - СМОТРИТЕ КОД!

 

 

9 А какой максимальный и минимальный допустимый ввод по количеству символов - "От трех до бесконечности"

Это должно быть ясно из ТЗ. если ТЗ нет - СМОТРИТЕ КОД!

 

Продолжаем придумывать тесткейсы:

в.  _А больше мыслей нет для smoke?

То что вы написали, это не смоук тестирование. это системное тестирование.

 

Пока перерыв, так как знаю, что не все дописала из smoke, чувствую еще есть тесты, но я их не замечаю.

В смоук тестировании будет только 2 теста в данном случае 1) форма открывается. 2) кнопка нажимается без падения системы.

 

Как Вам такое рассуждение!?

курсивом я выделили предполагаемые ответы заказчика(на мой взгляд).

Нет. курсивом вы выделили абсолютное отсутствие процесса разработки ПО в ВАШЕЙ компании.

 

По вопросом я что-то упустила или в общем понимании процесса или еще какой-то нюанс, подскажте, пожалуйста!

См предыдущее сообщение.

 

И что тут в smoke еще модно добавить!?

Сейчас модны нанотехнологии (немного лирического отступления)

 

А далее начну Critical path писать и рассуждать далее!

Давайте!

 

Спасибо!

Не за что!