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

clipsa

Регистрация: 18 окт 2012
Offline Активность: 13 сен 2023 07:46
*****

#146426 Объясните пожалуйста что такое test-case data-driven с примерами

Написано clipsa 25 ноября 2015 - 13:43

 

 

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

 

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

 

Хорошо, какая особенность данного тест-кейса, почему его называют управляемые-данные? В Вашем примере с калькулятором я понял, что есть общая идея, ряд идентичных шагов при тестировании различных действий, но не понятно до конца почему мы называем «управляемые-данные», это название как-то в прямом смысле что-то значит и мы имеем какое-то преимущество, имея возможность осуществлять определенные действия с данным тест-кейсом или как? В чем прикол его так называть, давайте разберемся!Спасибо!

 

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


  • 1


#146223 Наставничество. Ищу падавана.

Написано clipsa 19 ноября 2015 - 15:09

Коллеги, друзья, товарищи! 

Решила я себя попробовать в роли наставника в тестировании.

В этой профессии я уже 8 лет, хочу помочь начинающему тестировщику найти свой путь. Бесплатно.

 

Требования к падавану: целеустремленность, готовность учиться и искать пути, желание развиваться в области тестирования. Желательно часовой пояс МСК или не слишком далеко от него для облегчения коммуникаций.


  • 2


#146089 Резюме не хочет работать

Написано clipsa 17 ноября 2015 - 08:20

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

Если нужна помощь в оформлении резюме, пишите в личку, помогу чем смогу. 


  • 1


#145897 Кто лучше справляется с регрессом (в рамках полового деления)?

Написано clipsa 10 ноября 2015 - 11:44

В текущем опросе ответили 5 человек...ммм...очень репрезентативная выборка... :)

Нет деления по половому признаку качества усидчивости. Если вы считаете иначе, набирайте себе гарем, ктож вам запретит то :)


  • 1


#145864 Кто лучше справляется с регрессом (в рамках полового деления)?

Написано clipsa 09 ноября 2015 - 14:04

Эх вы! Знание психологии у вас прям таки зашкаливает!

 

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

 

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

 

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

т.е. вы для себя уже все решили и думали, что мы ринемся дружно ваше мнение поддерживать? :)

 

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

Должен быть индивидуальный подход к каждому собеседуемому, а не "это мальчик, не будем приглашать его на собеседование, он не усидчивый"))) это смешно)) вы еще по цвету кожи подбирайте или по ухоженности ногтей :)


  • 1


#145743 Кто лучше справляется с регрессом (в рамках полового деления)?

Написано clipsa 06 ноября 2015 - 07:21

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

Без обид, это просто моё мнение :)


  • 1


#144886 Насколько вы углубляетесь в найденный 'явный' баг?

Написано clipsa 07 октября 2015 - 07:58

ИМХО зависит от ситуации на проекте и самого бага.

Если у вас тестирование - узкое место, то тратить время тестировщика на детальный разбор дефекта не стоит (только если дефект странный, сложновоспроизводимый и т.п.). Если узкое место - разработка, то будет правильнее потратить время тестировщика на детальный разбор бага.

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

Ну и конечно, от конкретных людей зависит, от их квалификации, настроения, фазы луны и пр.)))


  • 2


#144436 Помогите разрулить тестовое задание

Написано clipsa 24 сентября 2015 - 11:03

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


  • 1


#142702 Тест дизайн для функциональности под несколькими ролями

Написано clipsa 20 июля 2015 - 07:48

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


  • 2


#142445 Баги в кино и книгах

Написано clipsa 08 июля 2015 - 15:44

В "Гарри Поттере" спецификацию на то, как работают заклинания, Роулинг переписывала прямо-таки на лету - от части к части от них нельзя увернуться / можно отскочить или увернуться, убивает только Авада Кедавра / нет, не только, если в сердце целиться, и в конце выходит такая каша, что тому-кого-нельзя-называть логичнее было охотиться за ядерной бомбой, а не за волшебной палочкой, было бы куда эффективнее)

Есть потрясный фанфик на Гарри Поттера, где убраны все эти ляпы, называется "Гарри Поттер и методы рационального мышления" - рекомендую :)


  • 1


#140842 Зависимость тест-кейсов

Написано clipsa 21 апреля 2015 - 12:31

Но на курсах по тестированию преподователь указал, что нормальной практикой является тестировать логику последовательно, те тест кейс 1, тестирует логику из шага 1, тест-кейс 2 - логику из шага 2 (при этом больше ничего не указывая и тд.), те делать зависимость выполнения тест-кейса для шага 2 от выполнения тест-кейса для шага 1.

 

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

Т.о. если вы проверяете весь процесс целиком (интеграция с другими системами в рамках тестирования функционала), то одни тест-кейсы должны описывать весь процесс, состоящий из всех последовательных шагов (но без проверок интерфейса). А другие кейсы будут атомарно проверять каждый шаг в отдельности, имея в предусловии кратко описанные предыдущие шаги.

 

Такая система подходит для большой распределенной команды, особенно, если состав команды постоянно расширяется/меняется.

Для маленьких команд вполне подойдет чек-лист или очень кратко и вольно описанные полу-тест-кейсы))

 

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

 

ИМХО :)


  • 1


#140588 Принципиальная разница между Severity & Priority

Написано clipsa 09 апреля 2015 - 16:03

 

У нас на проекте Severity обозначает критичность дефекта для работы функционала, а Priority - приоритет исправления дефекта. Т.о. вполне могут быть критичные, но не приоритетные дефекты (например, если данный функционал внедряется не в текущем релизе, а в одном из последующих)

Да, так везде и пишут в интернете :) Т.е. на 1-ый вопрос ответ - "да". А на второй?

Если что, мне пока важнее узнать просто "да-нет" на оба вопроса. На второй вопрос, опционально - какие именно споры самые заметные. 

 

Действительно, не ответила, отвлекли, наверное :)

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

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

 

Думаю, что это не секретная информация и я могу выложить эту табличку :)

 

 

6-Блокирующий

·         Присваивается дефектам, блокирующим новые или дорабатываемые в тестируемом релизе интеграционные взаимодействия, при этом отсутствует обходной путь проверки этих интеграционных взаимодействий из интерфейса ЕРИБ, либо любым другим способом указанным в РО.

·         Присваивается дефектам, блокирующим прохождение одного или более тест кейсов, при этом отсутствует обходной путь проверки заблокированных тест кейсов нового и регрессионного функционала из интерфейса ЕРИБ, либо любым другим способом указанным в РО.

 

5-Критический

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

·         UX дефекты (опечатки, ошибки дизайна, разметки и т.д.), несущие репутационный риск

4-Условно критичный

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

3- Существенный

·         Присваивается дефектам, минимально влияющим на функциональность и не мешающим выполнению бизнес-процесса, таким как отсутствие второстепенных полей и т.п.

2-Средний

·         Присваивается дефектам не несущим репутационных рисков, не влияющим на функциональность системы и не мешающим выполнению бизнес-процесса.

 

 
 

>> И еще один вопрос назрел. 3. Есть ли у вас в проектах KPI связанный с Severity или Priority (не только для тестировщиков, а для проекта в целом или разработчиков), и если есть - то какой.

 

У нас нет, возможно есть у программистов, но я этого наверняка не знаю, т.к. они аутсорс :)


  • 1


#140438 Как составлять тесты для пересекающегося диапазона значений?

Написано clipsa 07 апреля 2015 - 08:40

Думаю, что для начала вам надо выписать все возможные пересечения.

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

Негативные проверки необходимо проводить по отдельности (в цепочке все случаи позитивные, кроме какого-нибудь одного, по которому проводится негативная проверка).


  • 1


#139878 Вопрос по курсам skillup.com.ua

Написано clipsa 12 марта 2015 - 13:34

 

И вообще устроиться ничаниющим тестировщиком почти невозможно.

 

Не отчаивайтесь, мы все когда то были начинающими и устроились ведь как-то! Какие вопросы вам задавали на собеседованиях и какие из них вызвали у вас затруднения? Проработайте их и ищите дальше!

Удачи!


  • 1


#139149 Тестирование мобильных приложений для начинающих или с чего начать ?

Написано clipsa 15 февраля 2015 - 13:57

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

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

 

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

 

Самообучение - это хорошо, но обычно весьма сложно в новой для себя области самостоятельно систематизировать знания.


  • 1