Перейти к содержимому

Публикации Ekaterina1995_JuniorQA

43 публикаций создано Ekaterina1995_JuniorQA (учитываются публикации только с 30 марта 2023)



#171900 Баги ListBoxer

Отправлено автор: Ekaterina1995_JuniorQA 20 апреля 2019 - 19:51 в Тест-дизайн и ручное тестирование

 

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

1. Не уверен я в ваших цифрах. Но ищите оставшиеся 10%))
2. Мне кажется вы говорите о курсах с практикой.
3. Вы весь форум изучили? Здесь есть тема с подборками практических задач.

 

3. Если не затруднит, в лс можно ссылки на соответствующие темы, я весь форум пересмотрела и ,видимо, что-то упустила




#171898 Практические задачи тестирования

Отправлено автор: Ekaterina1995_JuniorQA 20 апреля 2019 - 18:00 в Тест-дизайн и ручное тестирование

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

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




#171897 Практические задачи тестирования

Отправлено автор: Ekaterina1995_JuniorQA 20 апреля 2019 - 17:59 в Тест-дизайн и ручное тестирование

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

файл calc_days.zip

 

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

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




#171896 Практические задачи тестирования

Отправлено автор: Ekaterina1995_JuniorQA 20 апреля 2019 - 17:59 в Тест-дизайн и ручное тестирование

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




#171889 Баги ListBoxer

Отправлено автор: Ekaterina1995_JuniorQA 19 апреля 2019 - 18:08 в Тест-дизайн и ручное тестирование

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

Приходят джуны, просят зп ведущих (от 100к, например), вот и спрос соответствующий.

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

А плохому учить не надо. Кстати, потренироваться по поиску багов - есть отличный челендж, ссылку на форуме выкладывали.

Труд ваш жаль.
 

На какую зп эта хрень?

 

Сколько я сталкивалась с собеседованиями, на позицию junior в РБ, то зарплатные ожидания (мои и с кем я общалась) в р-не 300 у.е ~ 20 тыс на рос. рубли. Причем теория на хорошем уровне, английский A2 - B1, возраст 25 - 33 года, бэкграун - технический (парни и девушки), ин.яз (девушки).




#171888 Баги ListBoxer

Отправлено автор: Ekaterina1995_JuniorQA 19 апреля 2019 - 18:04 в Тест-дизайн и ручное тестирование

Эх, что же все такие обиженные то??
Plotogon, давайте по пунктам.
1. Задание "найти максимальное количество багов" некорректное. И никто из присутствующих в беседе вам такое не даст. Если вам попадались такие работодатели, то ой, не судьба. Но не надо после этого всех под одну гребенку и считать, что все такие бестолковые.
2. Кто-то готов учить, кто-то ищет готовых специалистов. Если вам все время попадаются вакансии на джуна с опытом сеньера, то, могу предположить, это специфика местного рынка труда.
3. Я помню себя в начале карьеры. И помню, что ресурсов по тестированию не было!! Даже этого форума практически не было. На вопрос что почитать начальник выдал мне книгу Канера. С тех пор я ее перечитывал еще два раза, хотя и не целиком. И до сих пор советую ее всем начинающим.
4. Не надо думать, что если программу тестируют, то она без багов. Тестирование сообщает об ошибках, а править или не править тут дело за ЛПР. И не вина тестировщиков, если отчет прочитали, убрали в стол и решили, что деньги можно делать и с таким качеством.
5. Как вы можете догадаться, никто из специалистов форума с регистрацией уже давно не сталкивался. Потому что функция эта используется лишь единожды.

1. Такие работодатели - 90%

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

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




#171887 Баги ListBoxer

Отправлено автор: Ekaterina1995_JuniorQA 19 апреля 2019 - 17:57 в Тест-дизайн и ручное тестирование

Так и не выполняйте тестовые задания и не тратьте своё время и время работодателей. Можете хоть тысячу багов найти, а вас не возьмут. Когда мне кандидаты пишут эту хрень, мне уже через пять минут хочется отправить их куда-нибудь, особенно когда узнаю их ожидания. Им говорят протестировать, а они тупо начинают кейсы писать, при этом заканчивают курсы software-testing, американские онлайн, специалист при Бауманке (позоря универ), и т.д. и т.п.

 

На курсах учат оформлять тестовые артефакты, НО не учат самому подходу к тестированию :search: . Я сейчас junior, но посещаю собеседования (для опыта, так как у меня идет испытательный срок :secret: ) и каждый раз, когда мне дают практическую задачу, я всегда теряюсь, так как пытаюсь все разложить,как учили на курсах, но не получается у меня. Думаю многие с этим сталкиваются, поэтому и начинают писать тесткейсы так как разложить по видам, по уровням форму из одного поля, у меня лично, фантазии не хватает :shout: :shout: :shout:




#171886 Практические задачи тестирования

Отправлено автор: Ekaterina1995_JuniorQA 19 апреля 2019 - 17:49 в Тест-дизайн и ручное тестирование

Всем привет!

 

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

 

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




#171783 Клиент-серверная архитектура. Взаимодействие

Отправлено автор: Ekaterina1995_JuniorQA 13 апреля 2019 - 09:46 в Тест-дизайн и ручное тестирование

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




#171779 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 12 апреля 2019 - 18:41 в Тест-дизайн и ручное тестирование

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

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

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

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

 

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

Отличное видео! Конечно видно, что волновались читая доклад, но информация очень полезная! Я сказала - 2,5 часа, на тестирование smoke на форме, на что ребята даже воскликнули от удивления, Smoke - 2,5 часа?))))как-то логично на smoke 3 часа,на остальное 2 недели)




#171776 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 12 апреля 2019 - 12:47 в Тест-дизайн и ручное тестирование

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

 

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

 

А вы в этом разбираетесь?




#171758 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 17:13 в Тест-дизайн и ручное тестирование

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

 

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.

 

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




#171757 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 16:52 в Тест-дизайн и ручное тестирование

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

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

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

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

 

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

 

 

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




#171756 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 16:50 в Тест-дизайн и ручное тестирование

 

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

 

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

 

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




#171755 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 16:49 в Тест-дизайн и ручное тестирование

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

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




#171749 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 14:32 в Тест-дизайн и ручное тестирование

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

 

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

 

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




#171747 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 14:13 в Тест-дизайн и ручное тестирование

 

я бывала на собеседованиях и там нет такого, что - зависит от требований, зависит от условий. там конкретно - напишите тесткейсы для 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 тестирование для данной формы? Какие вопросы нужно задавать для представления полной картины (менеджмент+тестирование) у себя в голове для качественного ответа на вопрос.




#171746 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 14:10 в Тест-дизайн и ручное тестирование

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

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

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

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

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

 

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




#171737 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 10:13 в Тест-дизайн и ручное тестирование

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




#171736 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 10:10 в Тест-дизайн и ручное тестирование

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




#171734 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 09:48 в Тест-дизайн и ручное тестирование

 

 

 

 

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

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

 

Пока перерыв, так как знаю, что не все дописала из smoke, чувствую еще есть тесты, но я их не замечаю.
В смоук тестировании будет только 2 теста в данном случае 1) форма открывается. 2) кнопка нажимается без падения системы.
 
т.е smoke тестироание для ДАННОЙ формы будет ТОЛЬКО нажатие на кнопку? - предположим...Нажали (дым из формы не пошел). Но что мы проверили этим нажатием, когда к примеру есть просто кнопка без логики никакой.
Smoke тест прошли - отдали тестировщикам, программисты перешли к другой задаче. тестировщик берет Критикал пас тест: вводит валидные данные в поля - нажимает кнопку - 0 реакции, прогоняет все тесты - все FAIL. Потрачего 3 часа времени в пустую, так как кнопка REGISTRATION не имела никакого события. Вопрос - что мы добились smoke тестом из вашей логики и на что мы потратили3  часа тестирования?

 

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

 

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

 

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

 

 

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

 

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

 

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

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

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

 

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

 

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




#171732 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 09:31 в Тест-дизайн и ручное тестирование

 

 

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

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

 

Пока перерыв, так как знаю, что не все дописала из smoke, чувствую еще есть тесты, но я их не замечаю.
В смоук тестировании будет только 2 теста в данном случае 1) форма открывается. 2) кнопка нажимается без падения системы.
 
т.е smoke тестироание для ДАННОЙ формы будет ТОЛЬКО нажатие на кнопку? - предположим...Нажали (дым из формы не пошел). Но что мы проверили этим нажатием, когда к примеру есть просто кнопка без логики никакой.
Smoke тест прошли - отдали тестировщикам, программисты перешли к другой задаче. тестировщик берет Критикал пас тест: вводит валидные данные в поля - нажимает кнопку - 0 реакции, прогоняет все тесты - все FAIL. Потрачего 3 часа времени в пустую, так как кнопка REGISTRATION не имела никакого события. Вопрос - что мы добились smoke тестом из вашей логики и на что мы потратили3  часа тестирования?

 

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

 

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

 

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




#171731 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 09:30 в Тест-дизайн и ручное тестирование

 

 

 

тестировать ТОЛЬКО заявленный функционал - если его нет, просто сказано, что должно регистрировать пользователя и все.

 

 

Встречный вопрос - Как вы видите пределы тестирования данной формы?

 

Ещё небольшое лирическое отступление:

Мне на третьем курсе универа добавили бал к оценке за то, что я ответил на вопрос "Что нужно сделать первым делом когда вы начинаете писать курсовую?"

Ответьте на данный вопрос, добавлю вам бал =)

 

Узнать тему курсовой -  я бы ответила так)




#171728 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 08:58 в Тест-дизайн и ручное тестирование

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

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

 

Пока перерыв, так как знаю, что не все дописала из smoke, чувствую еще есть тесты, но я их не замечаю.
В смоук тестировании будет только 2 теста в данном случае 1) форма открывается. 2) кнопка нажимается без падения системы.
 
т.е smoke тестироание для ДАННОЙ формы будет ТОЛЬКО нажатие на кнопку? - предположим...Нажали (дым из формы не пошел). Но что мы проверили этим нажатием, когда к примеру есть просто кнопка без логики никакой.
Smoke тест прошли - отдали тестировщикам, программисты перешли к другой задаче. тестировщик берет Критикал пас тест: вводит валидные данные в поля - нажимает кнопку - 0 реакции, прогоняет все тесты - все FAIL. Потрачего 3 часа времени в пустую, так как кнопка REGISTRATION не имела никакого события. Вопрос - что мы добились smoke тестом из вашей логики и на что мы потратили3  часа тестирования?



#171727 Понимание процесса тестирования!

Отправлено автор: Ekaterina1995_JuniorQA 11 апреля 2019 - 08:51 в Тест-дизайн и ручное тестирование

 

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

 

 

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

 

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

 

 

 

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

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

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

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

 

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

 

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

 

Да, спасибо! на данный момент это лучшее, что я прочитала в этой теме (кроме того, что на меня обратил внимание некий Сергей). Я сколько читала форумы, у людей были однотипные задания - протестируй форму (менялись только кол-во полей и кнопки), но смысл одинаковый и должен быть подход универсальный, но я не нашла такого. Пытаюсь для себя разобраться! Меня из группы спрашивают: ты же работаешь уже - расскажи как это протестировать, а я смотрю и понятия не имею...Или мне тоже им рассказывать про сферические вопросы в вакууме?

"Это очень простой пример, по одному позитивному тесту на каждое поле" - это общий подход, мол проверяй все и со всем, НО если подходить более структурировано (к примеру у меня есть права на 1-2-3 тесткейса), то для этого и придумали Уровни функционального тестирования. Первым делаются смоук проверки! Зачем мне смотреть,Как работает первое поле, если у меня обязательное поле является необязательным и регистрация проходит без его заполнения. Какой смысл тестировать эту форму, когда она даже основную проверку не прошла. Привожу аналогию: Тестирование карандаша: Зачем мне смотреть, как стирка стирает, когда у меня сам карандаш НЕ ПИШЕТ. Так и с формной, зачем мне смотреть, как работает поле First name(Первое), еслиу меня mandatory field (обязательное поле) не отрабатывает.

 

Что значит СМОУК не нужно? а как вы поймете, что форму нужно тестировать? Либо по логике будете проверять все поля (необязательные), потом обнарудите, что обязательное поле не играет роли, вернете на доработку - вам поправят, вы сломав все ваши проверки и вы будете по 3 часа тестировать форму эту????

 

тестировать ТОЛЬКО заявленный функционал - если его нет, просто сказано, что должно регистрировать пользователя и все.