Hi   Начните писать кейсы для формы регистрации/авторизации/восстановления пароля данного форума. Я когда-то давно, когда начинал изучать тестирование, пытался это сделать) Расшарю вам доступ с правами редактора если есть желания продолжить) Там конечно не все правильно, но идеи черпать можно) https://docs.google....dit?ts=5ca71853  

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

http://blog.shumoos.com/archives/154

файл calc_days.zip

 

Сделал 11 лет назад, последний раз на тренинге использовал в феврале 2019.

Спасибо))))Буду изучать! А сейчас чем занимаетесь?

http://software-test...ting-challenges

Спасибо))) это я уже делала, но тут из разряда просто запомнить, что можно вносить! А вот к примеру если это календарь, с 19 по 20 век, то там очень тяжело понять, что и как тестировать)

Всем привет!

Подскажите, пожалуйста, может кто-нибудь находил практические задачи (веб формы, приложения либо еще что-то) на которых можно было бы потренироваться в составлении testcases (особенно использование техник тест дизайна) с готовыми ответами, либо описанием подходов, какими-то объяснениями. Либо может кто-то на интересное видео попадал (не про сами техники,а про то,как подходить к решению конкретных задач используя данные техники), либо ресурсы есть позновательные. Вообще идеально, если есть форма с разнообразной функциональностью, для понимаю общих принципов и подходов. Если новички, да и не только сталкивались с подобными проблемами, с которой столкнулась я, то можно пообщаться на эту тему в личные сообщения.

Спасибо,ребята!

Если просят дать эстимацию

И у вас руки дружат с головой

И нет спешки (собеседование, например),

ТОГДА рассмотрите такой метод https://testitquickl...7/06/20/stones/

 

Он как раз на грани стыка исполнительского и менеджерского уровней подхода к работе.

 

 

Спаисбо, обязательно сегодня вечером посмотрю.Я вообще знаю методы эстимации некоторые: 1.По тесткейсам (за сколько человек придумывает тесткейс и исполняет его)(либо взять кол-во тесткейсов в день).2. взять эстимации разработчика и поделить на 3. 3.при помощи экспертной оценики. 4. В Скраме: planning poker (основанный на сторипоинтах).

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

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

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

 

я бывала на собеседованиях и там нет такого, что - зависит от требований, зависит от условий. там конкретно - напишите тесткейсы для smoke тестирования формы и ВСЕ. Больше нет ничего, только PM сидит и все и ждет вопросов. А я что тогда не знала, что ответить,что сейчас.

 

 

Тестировщики разные нужны.

 

Если нужен простой исполнитель (реальный примитив!), то ответ будет такой: "Тыцну в первое поле, тыцну во второе, если все ок, то переходим к расширенному тестированию, где я буду тыцать по полям до тех пор, пока эти поля не лопнут" — ожидаемый результат может быть разным.

 

Если нужен непростой исполнитель, если нужен менеджер-присматриватель за ВСЕМ процессом, могущий указать на аспекты, которые были забыты, и объяснить, что не надо про них забывать, а то будет бэмц, то ответ будет такой: "Надо продумать процесс".

 

Ещё раз — продумать процесс, а не тыцать по полям.

 

В процессе тестирования есть несколько Сцилл и десяток Харибд, про которые вкратце упомянуто в http://www.sqa.net/iso9126.html - шесть основных характеристик качества, а именно:

1. Functionality
2. Reliability
3. Usability
4. Efficiency
5. Maintainability
6. Portability

А под ними есть еще подпункты (см. там же таблицу The full table of Characteristics and Subcharacteristics for the ISO 9126-1 Quality Model).

 

То есть, тыцать в поля - это всего лишь пункт №1 (Functionality), его мы поручим выполнять одному тестировщику.

 

А убедиться в том, что приложение можно будет успешно устанавливать в разных окружениях? Это мы поручим другому тестировщику, который знает, чем отличается Андроид от Лолипоп (№6 Portability).

 

А убедиться в том, что приложением удобно пользоваться, мы поручим третьему тестировщику и дизайнеру (№3 Usability).

 

И так далее, пока не будут охвачены все аспекты, которые для вашего продукта надо охватить. В зависимости от ситуации, некоторые аспекты будут проигнорированы, а на некоторые будет сделан особый акцент, но так или иначе, менеджер будет думать о много всяком, а не только про функциональность разрабатываемого ПО, ведь функциональность — всего лишь один из аспектов.

 

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

 

Вы освоились на первом уровне (исполнительский), и не знаете про существование второго (менеджерский), но пытаетесь их совместить.

 

Сосредоточьтесь! (и вы найдете свой путь).

 

ЗЫ Рекомендую не щеголять термином "расширенное тестирование", бо он условный и требует контекста.

 

ДА,вы правы, Но как тогда нужно было отвечать на вопросы?! если просят дать эстимацию на smoke тестирование для данной формы? Какие вопросы нужно задавать для представления полной картины (менеджмент+тестирование) у себя в голове для качественного ответа на вопрос.

 

 

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

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

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

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

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

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

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

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

НУ почему. Если на smoke сделать тест на обязательное поле с валидным значением, то остальное тестироание - это еще каждое поле проверить на невалидные значения (а это еще тесткейсов 50) можно придумать, так что 2 и 50 - это разница большая)

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

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

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

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

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

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

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

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

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

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

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

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

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

О, в голове щелкнуло немного:))

"Вот вам сборка, ответьте через 5 минут берете ли вы ее в тестирование? и если нет, то почему" - так вот если бы у меня про форму спросили,я бы ответила:

1. Заполняю обязательное поле Valid data  = OK

2. Пустой ввод - "FAIL"

Все, этого мне будет достаточно, что бы понимать, что форма выдает и положительный и отрицательный результат.

Далее я буду уже проверять на комбинации заполнения всех полей + invalid data + sql иньекции + файлы в эти поля перетаскивать.

 

 

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

 

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

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

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

 

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

 

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

Согласна! Толмуты получаются)

Ребята, А можете тогда что-то у меня спросить, проверив мою склонность к мышлению для решения подобных задач. Очень было бы интересно:)

Кстати, на счет 6'' экрана. Если в спецификации этого сайта было заявлено: Отображение на телефонах 4 - 6 дюймов, то получается, что это проблемы с........Юзабилити? Либо GUI тоже с этим связан?

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

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

 

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

 

А мне то оно зачем? =)

 

Вы же хотите человека наставить на путь истинный и получить +5 в карму:)

 

 

 

 

 

 

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

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

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

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

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

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

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

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

 

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

Кстати, есть еще актуальный вопрос: Клиент-серверные отношения (смотрела сегодня много видео на эту тему и сделала для себя такой вывод.

1. Есть клиент, есть сервер. серверы бывают сервер-приложений и сервер базы данных (2х и 3х уровненная организация). Клиент - это по сути интерфейс взаимодействия с сервером. Допустим есть сайт РЖД (мой любимый пример). На нем есть некая информация (расписание на среду). Я на фронтенде(на клиенте) нажимаю РЖД.ру/расписание/среда - и нажимаю на ссылку. В этот момент мой клиент формирует запрос: get /расписание/среда HTTP 1.1 (на второй строке host: РЖ.ру (ДАЛЕЕ НЕПОНЯТНЫЙ МОМЕНТ для меня...он в заголовок что вставляет при таком запросе,какие-то параметры?. Тело запроса будет пустым я так понимаю. В ответ сервер, видя мой запрос - посылает ответ. HTTP 1.1 200 OK, и в теле запроса присылает Html код и css файл, который принимает мой браузер и по тегам размечает мне визуально страницу (читаемую красивую). + Присылает мне (НО Я НЕ ПОНИМАЮ КАК) куки файлы (о моем запросе(к примеру если я  перед этим авторизовалась). Кажется теперь я стала понимать, почему реклама постоянно донимает тематическая!!! 

2. А между тем, как я сформировала запрос: get /расписание/среда HTTP 1.1 (на второй строке host: РЖ.ру - он ведь передается по проводам( по воздуху) на сервер, значит есть модель OSI ...мой запрос сформирован на прикладном уровне, который через сокет общается с транспортным уровнем(который гарантирует доставку сообщений). Соответственно мой запрос ПК видит как 1 и 0. соотсетственно есть какой-то порядок этих 1 и 0 ,который на сервере преобразуется в запрос. Соответственно пусть мой запрос это (условно) 11111111. (через сокет я передаю его уровню TCP, но запрос(предположим велик), он делает так: (TCP1)1111 (TCP2)1111 (разбивает) на более мелкие части (TCP - это он придает заголовок свой с атрибатами (особенно сегментация, что бы не потерять последовательность при разбиении. Помоему тут фигурирует понятие - ПОРТ. Этот протокол говорит, что я со своего IP стучусь на порт 80 сервера (перед посылкой запроса произошла сессия инициализации соединения). Когда порт установлен и подтвержден - то мои пакеты передаются по на сетевой уровень, где уже протокол IP присваивает свой заголовок (IP)(TCP1)1111 и (IP)(TCP2)1111 (добавляет в заголовок мой айпи и айпи сервера) и передает на след уровень (через интерфейсы передача осуществляется). Передает на канальный уровень, где опять заголовок канального уровня добавляется и записывается мак адрес устройства моего и мак адрес отправляющего устройства и далее происходит деление на Frame (до 1500б) и идет передача тока( либо света, если оптоволоконный кабель) по сети. ПО мак адресу оно уходит туда, откуда мне пришло сообщение, далее идет поиск по IP, далее через 80ый порт попадает на сервер. Так отбрасываются все заголовки по очереди поднимаясь наверх и на уровне прикладном мы видим мои 11111111.

Ой, душу излила! Наткнулась на видеоурок отличный, целый день смотрела - вот так поняла всю процедуру. Если кто-то понял мой крик души, то дайте,пожалуйста, свой комментарий, где я недостаточно вникла и где заблуждаюсь!?)

 

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

 

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

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

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

Вас готов рассмотреть на джуна, вашего друга нет)

Смотреть - можно, а лучше по теме помочь, так как хотела поднять не один вопрос)

 

 

 

 

ну и в догонку, люди охотнее думают над реальными проблемами, чем над выдуманными. Потому вы тут 4ый день ничего добиться и не можете =) Успехов.

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

 

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

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

 

т.е smoke тестироание для ДАННОЙ формы будет ТОЛЬКО нажатие на кнопку? - предположим...Нажали (дым из формы не пошел). Но что мы проверили этим нажатием, когда к примеру есть просто кнопка без логики никакой.

Smoke тест прошли - отдали тестировщикам, программисты перешли к другой задаче. тестировщик берет Критикал пас тест: вводит валидные данные в поля - нажимает кнопку - 0 реакции, прогоняет все тесты - все FAIL. Потрачего 3 часа времени в пустую, так как кнопка REGISTRATION не имела никакого события. Вопрос - что мы добились smoke тестом из вашей логики и на что мы потратили3  часа тестирования?

 

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

 

Описанное вами из за кривых рук разработчика должно в итоге привести к его увольнению. Как-то так это работает.

 

Если только к моему, так как я не понимаю процесса тестирования и вместо того,что бы отдать на доработку программисту, проведя 2-3 теста, я провела один бестолковый и отдала в отдел тестирования, которые зная, что смоук пройден - начали еще прогонять 50 тесткейсов.

 

 

Не задавайте вопросы, если вы не готовы выслушать и принять ответы. Вот назвали меня бестолковым, а я ведь на основе более 10-ти летнего опыта вам ответил, обидно... . =)

 

Извините, если обидела. Я с точки зрения полезности данного теста. Он только помог выявить, что программист - криворукий либо забывчивый.

Я выслушиваю и принимаю ответы, но я бывала на собеседованиях и там нет такого, что - зависит от требований, зависит от условий. там конкретно - напишите тесткейсы для smoke тестирования формы и ВСЕ. Больше нет ничего, только PM сидит и все и ждет вопросов. А я что тогда не знала, что ответить,что сейчас.

1. Первый раз я помню начала писать тесткейсы: Заполнить все поля, заполнить по очереди, разные комбинации, далее валидные и невалидные значения во все поля, на что мне ответили - что вы понятия не имеете о приоритизации тестов и подхода. Сейчас я подняла этот вопрос, но судя по всему - тут никто такого понятия не имеет, так как и условие есть и сопутствующая информация, но ДЛЯ себя, я так и не поняла, как тестировать эту форму.

2. Тоже самое и с РЖД. и подобный вопрос я получала и отвечала, как и описывала выше ( но опять не верно, так как приоритеты неправильные) Ответы: согласно тестплану, пожеланию заказчика и аналогичные игнорировались, просто пишите виды/типы для тестирования именно этого сайта.

Если я без опыта не смогла ответить за 10 минут, то 4 для люди с  опытом вокруг да около ходят, а я не понимаю ничего(

Если вы считаете мои задачи абстрактными, то давайте РЕАЛЬНУЮ придумаем, что бы я на основании реальной задачи поняла, как решить предлагаемые мною. Такой вариант развития событий тоже отличный!

У меня нет мнения, поэтому я и спрашиваю. Я всегда теряюсь на вопросах : Протестируйте что-нибудь. Да, я смотрела видео, читала, про карандаш видела таблицы, но как таковой методики не нашла (везде написано - зависит от обстоятельств). Но ведь если все идеально, должен же быть подход какой-то. Это ведь и отличает junior От senior Специалиста. Я ведь должна понимать и уметь производить декомпозицию. Но по факту (в видео смотрела), дали человеку протестировать маркер - и он: "ну...напишу, попробую стереть, сверю цвет с описанным на самом маркере, потрясу...ну...эээ". Я бы сама так и делала, отсюда вопрос и был про РЖД. Как подойти к тестированию данного сайта (по документации?), а если ее нет. Тогда исследовательское тестирвоание, но оно тоже должно быть структурированным.