BornInUSSR.ca

Siberian_girl wrote:Goldy, я не MrsPerkins, но в одном из постов выше уже все есть: и про образование, и про опыт. Я не наезжаю, просто зачем человеку два раза одно и то же повторять.

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

malcolm wrote:

Lark wrote: А как вы первоначальные 50 тесткейзов в Тест Лаб загрузили?
Я не знаю, как у вас настроен Quality Center, в разных организациях QC Admin-ы могут делать разные настройки. Я работаю с древовидной структурой и там это решается просто.
Например, вам надо протестировать Login Page, какого-то сайта.
В QС Test Plan-e вы создали фолдер Login Page и создали там свои 50 тесткейзов.
Чтобы их Run (execute) в QC Test Lab создан фолдер Cycle 1 и в нем Test set - Login Page. Чтобы загрузить туда тесткейзы помещаем на Test set курсор, на центральном тулбаре есть кнопка "Select tests", а в правом фрейме появляется дерево с фолдерами из Тест Плана. Выбираем нужный фолдер "Login Page" и кликаем на зеленую стрелку вверху тулбара правого фрейма "Add Tests to Test set". И все 50 тесткейзов загружены в Test Lab
Когда вы создали новые 10 тесткейзов в Тест плане в том же фолдере, то действия аналогичные - курсор в Тест Лабе на тест set -> select Tests -> только добавляем тесткейзы в тест set по одному - помещаем на него курсор и нажимаем зеленую стрелку.

Да, я все так и делаю, но как выбрать тест кейсы по одному и добавить их в текущий сет - вот что не получается!
Посмотрите, пожалуйста, вот эти два скрина
http://www.box.net/shared/2yfa1xc541
http://www.box.net/shared/cno3n0gi4q
Видите, у меня в test lab есть фолдер ver.1.00, в нем есть test set First QA cycle, и в нем 5 подпунктов. В центре видите подпункт 2.1.2.1 Purchase - там было внутри 100 test cases, я добавил еще 20, и хочу добавить их туда в уже имеющийся (видите там статус failed, я их уже сделал и сделал баг репорты, хочу только новые добавить).
Выбираю справа в test plan tree пункт 2.1.2.1 Purchase тест сет, жму стрелку зеленую влево, и он просто создает новый сет в центральном окне с таким же именем Purchase, в котором все тест кейсы непройденные (скрин 2).
А вот как добавить в уже существующий наполовину законченный тест сет еще внутрь тест кейсов - ума не приложу.

Посмотрела я скриншоты. На мой взгляд, так, как вы структуру тесткейзов сделали, вы и не добавите, т.к. структура изначально создана неверно. Тест кейзы в QС должны быть небольшие - на проверку небольшой функциональности (часто бывает 1 requirement - 1 тесткейз). Как правило в них всего несколько степов. Это делается специально, чтобы мелкая ошибка в степе не тормозила большой тесткейз.

У вас же 2.1.2.1 Purchase в Тест Лабе - это не тест сет, а один большой тесткейз по сути.

2.1.2.1 Purchase - должен быть фолдер в Test Plan-e.

А в нем уже должны быть отдельные тесткейзы. Что у вас там есть, какая-то форма?

Тогда отдельные тесткейзы будут, например,

1) - Проверка внешнего вида страницы Purchase
2) - Завести правильно все поля в форму, нажать Submit
3) - по каждому полю отдельный тесткейз на проверку неверных значений....
и т.д.

И, как я уже писала, в Test Lab-e - First QC Cycle - это фолдер. А в нем тест сеты. Т.е создать 2.1.2.1 Purchase как тест сет и в него загружать отдельные мелкие тест кейзы.

Я с QC (а еще раньше с Test Director-ом) работала в разных местах и все время это было именно так.

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

Примерно вашу мысль, понял, да, спасибо.
Да, это конечно нас так учат. Это миниатюрная тест программка просто, там кроме логина и пары пунктов ничего нету.
В меню Purchase вылезает форма для ввода информации из кредитной карты.
То есть получается мы сделали в test plan фолдер тестирования по drop down menu - User и Transaction. А в Transaction - Purchase и Void Purchase тест сеты. И уже в Purchase тест сетах steps. Их там было 50, допустим, я добавил еще 10. И вот эти 10 steps как раз не получается обновить никак, чтобы Purchase test set не делать manual run с нуля.
То есть, по идее steps у меня такие как вы и описываете... только тетечка нам говорит, что структуру в тест плане она каждый раз делает по-разному, типа как креатив пойдет. Мне это немного странно, потому чо я думал как раз, что всегда надо по одному принципу следовать.

Pavel:
спасибо за добрые слова!

Goldy:
Удачи 14 июля!

Siberian_girl:
спасибо за внимательность и оперативность.

to all:
Как тут все здорово и по умному ответили. Внесу свои 5 копеек в дискуссию. Этот ответ нам подсказали в колледже на курсах на вопрос: Что лучше waterfall или agile? Большинство тестеров не любят Waterfall, но работать где-то надо. Этот ответ заставил улыбнуться моего работодателя, что тоже не маловажно на интервью.
Ответ: Все зависит от того, что компания делает. Если, например она строит самолеты, то полетели бы вы на самолете, построенном на agile предприятии, когда требования, сроки меняются ежемесячно и еженедельно? - спарашиваете вы с улыбкой и глядя в глаза своему потенциальному работодателю. Взаимная улыбка обеспечена.

malcolm:
Про automation tools. Я, конечно, не эксперт, но я с трудом представляю использование любого automation tool без программирования. Может я чего-то недопонимаю, но по моему автоматизация тестирования не возможна без каких либо adjustments, применения scripting language, которые есть практически у каждого automation tool (как в QTP - VB Script). Вот тут очень много умных людей сидит по automation tools, если кому надо: http://www.sqaforums.com/ubbthreads.php

А разве большинстов тестеров не любят Waterfall? Я думал почему-то наоборот.

нам так говорили на курсах и я с этим согласна, что при waterfall нагрузка на тестеров очень не равномерна в течение проекта. Как правило, в начале проекта тестерам делать особо нечего, а в конце проекта начинаются авралы. Это то, что я сейчас уже наблюдаю на практике. Может, где и по-другому.

MrsPerkins wrote:нам так говорили на курсах и я с этим согласна, что при waterfall нагрузка на тестеров очень не равномерна в течение проекта. Как правило, в начале проекта тестерам делать особо нечего, а в конце проекта начинаются авралы. Это то, что я сейчас уже наблюдаю на практике. Может, где и по-другому.

Понятно. Ну, я сам пока не работал, но наша тетенька наоборот говорит, что agile ей не нравится, что он неэффективен и все такое. И она, мол, рада, что 90% компаний работают с waterfall в Канаде.

malcolm, a что за тетенька?

Goldy wrote:malcolm, a что за тетенька?

Просто тестер с опытом из какой-то фирмы.

malcolm wrote: только тетечка нам говорит, что структуру в тест плане она каждый раз делает по-разному, типа как креатив пойдет. Мне это немного странно, потому чо я думал как раз, что всегда надо по одному принципу следовать.

Я бы рекомендовала следовать следующим принципам:

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

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

Lark wrote:

malcolm wrote: только тетечка нам говорит, что структуру в тест плане она каждый раз делает по-разному, типа как креатив пойдет. Мне это немного странно, потому чо я думал как раз, что всегда надо по одному принципу следовать.

Я бы рекомендовала следовать следующим принципам:

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

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

Да, я так тоже примерно и думал, но спасибо все равно за совет.
Ну просто некоторые вещи она иногда разбивает так, что мне кажется неудобным. Но может это у меня просто от малоопытности.
Например, у нас есть там меню Purchase. Так мы его сделали в тест сете Functionality и его же в тест сете Drop Down Menu. Что меня в итоге только запутало, т.к. я не понял сразу, какие аспекты проверять там а какие там.
Потом уже сообразил, что в первом случае мы проверяем это меню на основные работающие моменты, типа что покупка совершается, а всякие n-cases и т.д. уже в Drop Down Menu. Только все равно не кажется эта система очень удобной...
Кстати, насчет HP QC я так и не нашел эту функцию, обыскав форумы разные... видимо, добавить в текущий незаконченный  test set новые steps нельзя.. странно, ведь по идее это должно быть довольно частым случаем, когда требуется добавить несколько новых мини кейсов.

malcolm wrote: Ну просто некоторые вещи она иногда разбивает так, что мне кажется неудобным. Но может это у меня просто от малоопытности.
Например, у нас есть там меню Purchase. Так мы его сделали в тест сете Functionality и его же в тест сете Drop Down Menu. Что меня в итоге только запутало, т.к. я не понял сразу, какие аспекты проверять там а какие там.
Потом уже сообразил, что в первом случае мы проверяем это меню на основные работающие моменты, типа что покупка совершается, а всякие n-cases и т.д. уже в Drop Down Menu. Только все равно не кажется эта система очень удобной...

Обычно возможны разные варианты. Обычно вся функциональность проверяется вместе в одном тест сете (но там много мелких тесткейзов у нас). Но бывают варианты, когда создают тест сеты для core functionality (чтобы легче было использовать в regression потом) и для остальной части, которая не часто нуждается в проверке.

malcolm wrote: Кстати, насчет HP QC я так и не нашел эту функцию, обыскав форумы разные... видимо, добавить в текущий незаконченный  test set новые steps нельзя.. странно, ведь по идее это должно быть довольно частым случаем, когда требуется добавить несколько новых мини кейсов.

На мой взгляд не является это частым случаем, если тесткейзы небольшие. Но и при вашей струкутре можно выкрутиться - создаете дополнительный test set, называете его, например, Purchase additional test set и добавляете туда только новые степы. Загружаете его независимо в Тест Лаб и выполняете. Если вам нужны какие-то степы из основного тесткейза, то загоняете их в pre-conditions (подразумевается, что они уже проверены и работают!).

Вас учат, что в Details tab у test cases должны быть Purpose (Objective) и Pre-conditions?

Кстати, еще один плюс небольших теткейзов. В крупных организациях принято при тестировании приааттчивать screenshots для expected results. Как доказательство работоспособности. Для этого в QC есть иконка с камерой. Когда тесткейз маленький, достаточно одного скриношота для последнего степа, если степов много, то не всегда понятно, как каким скриншот нужен, к к каким нет и впоследствии анализировать труднее.

Lark wrote: На мой взгляд не является это частым случаем, если тесткейзы небольшие. Но и при вашей струкутре можно выкрутиться - создаете дополнительный test set, называете его, например, Purchase additional test set и добавляете туда только новые степы. Загружаете его независимо в Тест Лаб и выполняете.

Я знаете как придумал еще один способ выкрутиться... можно сделать Continue Manual testing и уже внутри него можно добавить дополнительные степы, а потом при выходе он спрашивает - хотите сохранить это дело в test plan? Говорим да.
Не знаю насколько это удобно, но вот такое придумал.

Lark wrote: Если вам нужны какие-то степы из основного тесткейза, то загоняете их в pre-conditions (подразумевается, что они уже проверены и работают!).

Вы имеете в виду загоняю в Details tab у test cases?

Lark wrote: Вас учат, что в Details tab у test cases должны быть Purpose (Objective) и Pre-conditions?

Нет! Вы имеете в виду когда я создаю new test слева в test plan и в центре появляется меню и там первый пункт details, а второй design steps, то вот в табе деталей я должен написать что-то? Нет, мы там не пишем ничего. В поле description или в поле comments? Простите, а что именно там писать? Цель всего теста (всех степов) и условия (типа имеем пароль и логин такой-то)? Это всегда так делают?

Lark wrote: Кстати, еще один плюс небольших теткейзов. В крупных организациях принято при тестировании приааттчивать screenshots для expected results. Как доказательство работоспособности. Для этого в QC есть иконка с камерой. Когда тесткейз маленький, достаточно одного скриношота для последнего степа, если степов много, то не всегда понятно, как каким скриншот нужен, к к каким нет и впоследствии анализировать труднее.

Хочется уточнить. Когда вы говорите тест кейз то имеете в виду в тест плане new test серую иконку, верно ведь? А степс это уже шаги тест кейза.
То есть, надо стараться разбивать на большее количество тестов задачу, чтобы не было по 50 шагов в каждом тест кейзе...

Goldy, есть новости?

malcolm wrote:но наша тетенька наоборот говорит, что agile ей не нравится, что он неэффективен и все такое. И она, мол, рада, что 90% компаний работают с waterfall в Канаде.

Хм...что-то верится с трудом. IMHO - waterfall может быть приемлем для проектов типа "большой банк" или "больница", где есть люди, чтобы загодя все расписать до пиксела и потом строго придерживаться наисанного (то есть где не стоит задача "выйти на рынок первым" и т.п.). А в жизни, сколько видел, ситуация обратная - есть только "хочу серое, как слон, но не слона" от Заказчика и постоянное корректирование проекта

Siberian_girl wrote:Goldy, есть новости?

Начала писать историю. Надеюсь, что будет как в agile,а не в waterfall

malcolm wrote:

Lark wrote: Если вам нужны какие-то степы из основного тесткейза, то загоняете их в pre-conditions (подразумевается, что они уже проверены и работают!).

Вы имеете в виду загоняю в Details tab у test cases?

Да

malcolm wrote:

Lark wrote: Вас учат, что в Details tab у test cases должны быть Purpose (Objective) и Pre-conditions?

Нет! Вы имеете в виду когда я создаю new test слева в test plan и в центре появляется меню и там первый пункт details, а второй design steps, то вот в табе деталей я должен написать что-то? Нет, мы там не пишем ничего. В поле description или в поле comments? Простите, а что именно там писать? Цель всего теста (всех степов) и условия (типа имеем пароль и логин такой-то)? Это всегда так делают?

В тестинге не бывает "всегда". В разных компаниях может быть разная практика. Из моего опыта с QC в закладке Details у всех тесткейзов пишем Purpose и Pre-conditions.

В Purpose пишется кратко, что проверяется в тесткейзе. Например:

TC#1 Проверить внешний вид Login page
TC# 2 Ввести правильные данные - убедиться, что пользователь успешно залогинился
TC#3 Проверить сообщение об ошибке при неправильно введеном user ID и пассворде
и.д.

Это нужно для того, чтобы быстро понять, что же тесткейз проверяет. В больших организациях иногда бизнес-аналисты проводят Test case review, особенно для sensitive areas.

В Pre-conditions обычно пишут то, что должно быть сделано до того, как его начнут выполнять. Например, Test data set up, какие-то режимы switch ON/OFF, требования к environments и т.д.

Вопрос про Test data set up, кстати, довольно часто задают на интервью, если на проекте придется с этим сталкиваться.

malcolm wrote: Хочется уточнить. Когда вы говорите тест кейз то имеете в виду в тест плане new test серую иконку, верно ведь? А степс это уже шаги тест кейза.

Да, именно ее я и имею в виду.

malcolm wrote: То есть, надо стараться разбивать на большее количество тестов задачу, чтобы не было по 50 шагов в каждом тест кейзе...

Да. Надо стараться проверять независимые функции в разных тесткейзах.
Иначе у вас failed один из начальных шагов и весь тесткейз будет failed. Т.е. реальную картину тесткейз с большим количеством шагов не отражает.

Lark wrote:
В Purpose пишется кратко, что проверяется в тесткейзе. Например:

Это нужно для того, чтобы быстро понять, что же тесткейз проверяет. В больших организациях иногда бизнес-аналисты проводят Test case review, особенно для sensitive areas.

В Pre-conditions обычно пишут то, что должно быть сделано до того, как его начнут выполнять. Например, Test data set up, какие-то режимы switch ON/OFF, требования к environments и т.д.

Вопрос про Test data set up, кстати, довольно часто задают на интервью, если на проекте придется с этим сталкиваться.

Спасибо. Надо же, нас такому совсем не учат. Цель мы не пишем вообще, а прекондишин чатос пишем в самих степах просто.

Lark wrote:

malcolm wrote: Хочется уточнить. Когда вы говорите тест кейз то имеете в виду в тест плане new test серую иконку, верно ведь? А степс это уже шаги тест кейза.

Да, именно ее я и имею в виду.

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

Lark wrote:

malcolm wrote: То есть, надо стараться разбивать на большее количество тестов задачу, чтобы не было по 50 шагов в каждом тест кейзе...

Да. Надо стараться проверять независимые функции в разных тесткейзах.
Иначе у вас failed один из начальных шагов и весь тесткейз будет failed. Т.е. реальную картину тесткейз с большим количеством шагов не отражает.

Да. У нас так и получается, например Usability Testing folder, в нем штук 5 test sets и в каждом по 20-30 test steps.

Goldy wrote:

Siberian_girl wrote:Goldy, есть новости?

Начала писать историю. Надеюсь, что будет как в agile,а не в waterfall

А для agile что-то отдельно учить надо вообще?
По теорию не понятно особо, а на курсах нас учат только waterfall подходу, мол, он везде и agile не нужен и малоперспективен.

Приветствую всех на этом дружелюбном форуме. Принимайте новичка.

Имею 10-летний стаж программистом. .Net Developer C#. Уклон в сторону web.
После прочтения сотен постов на разных форумах, сложилось впечатление ,может ошибочное, что QA Tester найти работу проще.

Нашёл курсы у нас в Израиле, берутся за 4500$ и 112 часов (два раза в неделю в течении 9 месяцев) выучить на сертификат - ISTQB Foundation level . По-моему, сказали ручной проверки, не автоматической. Предупредили ,что будет скучно. Потому что основной контингент ни бум-бум в компах и начнут с самых азов.

Вопросы:
1. Правда ли тестерам жизнь легче в Канаде, чем программистам? Понимаю ,что вопрос очень общий. Так и ответ ожидаю такой же.
2. Имеет ли смысл учиться в Израиле? Обучение на иврите. Или если так уж хочется, то лучше взять ускоренный курс в ctcollege.ca ? SOFTWARE QUALITY ASSURANCE TESTER (NOC:2283)
3. Кто-нибудь знает сколько он стоит? Я где-то в теме натыкался на цифру в 2000$. Правда ли? Они там не пишут. Точно как у нас в Израиле. Цена курса- это самая большая тайна. Пока не созвонишься и тебя всего не перепроверят, цену не скажут. Секретчики.

Если все будет идти как запланировано, то переезд в Канаду намечен на следующее лето.
То есть год ещё в запасе есть.

Спасибо.