На правильном ли я пути?

И снова здравствуйте!
Я уже работаю тестером аж три месяца, и более менее освоилась: Прочитала много мануала, просмотрела записи конференций, стала усиленно вспоминать забытые языки программирования, немного разобралась с TestComplete, однако большим пробелом остаются багтрекеры :)
Как я уже писала в одной из тем, отдела тестирования или какого-либо тестирования отдельно от программистов в моей компании не было, поэтому я все сделала с нуля и не уверена, что правильно.
И на данном этапе я прошу указать мне на мои недочеты.
Итак, как я организовала работу лично для себя.
1. Если начинают разрабатывать какой-то новый Плагин я сижу рядом и конспектирую задачи, потому что ТЗ, как такового, обычно нет
2. В большинстве случаев у меня на руках небольшое описание уже готового продукта, поэтому я завожу новую тетрадочку и сначала руками расписываю чего я хочу проверить
3. Вся фиксация работы происходит в Excel'e, Я создаю файлик <ProductName>_Test_Suite, в котором куча вкладок, каждая из которых это какой-то тест-кейс.
4. Если тест кейс не требует сложных рассчетов, то он существует только в файле <ProductName>_Test_Suite, а если нужно проверять результаты каких-либо изменений, то в другом файлике я теоретически рассчитываю результаты тест-кейсов уже на конкретном примере, а потом на этом же примере сравниваю уже с фактическими результатами
5. Если найдены какие-то баги, то запихиваю их в третий файлик <ProductName>_bugs

Вот я прицепила файлик, как это выглядит.  Exemple.rar   837,43К   56 Количество загрузок:
Там пример Тест-Комплекта, Контрольного примера, и Баг-репорта.
Я прошу вас сказать похоже ли это на правду?
Заранее спасибо! )

Насчет вашей организации работы:
1. Правильно, вы молодец! :) Раз ТЗ нет, то хоть так))) Я вот тоже на новой работе с блокнотиком бегаю, уже найти не могу, что куда записывала, много страниц задействовано...
2. Лучше бы сразу на wiki\confluence, так как ваши тетрадочки потом пропадут, а так хоть история будет...
3-5. Каждая вкладка = 1 кейс? Нечто страшное...
А если много-много кейсов...
Имхо, не стоит прям совсем подробно расписывать.
Посмотрела ваш файлик с багами, мне неясно.

Страница "Баг №6" например. Вроде одна ошибка, но на каждый шаг написан ожидаемый результат... И итоговый.

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

Шаги:
1.
2.
3.

Результат:
...

Ожидаемый результат:
...

То есть результат один на все ваши шаги :)
И очень советую использовать таки багтрекер, а не эксель. Проще + история...
JIRA для маленьких компаний чуть ли не 10 баксов стоит...

В общем, баг-репорт странный :)
Я и в экселе писала шаги тест-кейса прямо в одной ячейке:

1.
2.
3.

И рядом ожидаемый результат :)

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

Sparkle, вы молодец, что так всё организовали.
Но попробуйте как-то уговорить программистов поставить хотя бы Mantis или любой другой баг трекер. Лучше ещё и Test Link. Это бесплатные инструменты. Mantis, насколько знаю, не сложно поставить. У меня знакомые руководители проектов, не программеры, сами ставили. Можете сами попробовать поставить))
+ Test Link можно интегрировать с Mantis.


Molechka права на счёт wiki.
Тетрадки это конечно хорошо. Но информация очень неупорядочена, долго искать, нельзя дать другому человеку. А в wiki, если что и программер подправит что-то, или сам добавит.


Подобные инструменты помогут сэкономить вам массу времени. И не только вам. Вашему руководству будет проще получить всю информацию о проекте.

2. Лучше бы сразу на wiki\confluence, так как ваши тетрадочки потом пропадут, а так хоть история будет...

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

3-5. Каждая вкладка = 1 кейс? Нечто страшное...
А если много-много кейсов...

Ну видимо много-много вкладок :))
Точнее наверное сказать - одна вкладка одна функциональность)

Посмотрела ваш файлик с багами, мне неясно.

Страница "Баг №6" например. Вроде одна ошибка, но на каждый шаг написан ожидаемый результат... И итоговый.

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

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

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

Но попробуйте как-то уговорить программистов поставить хотя бы Mantis или любой другой баг трекер.

А скажите пожалуйста, я могу сначала втихаря поставить себе на комп десяток багтрекеров, чтобы посмотреть на них, а только потом уговаривать программистов, или они(багтрекеры) не будут работать только на одном компе?




Всем огромное спасибо за ответы!

А скажите пожалуйста, я могу сначала втихаря поставить себе на комп десяток багтрекеров, чтобы посмотреть на них, а только потом уговаривать программистов, или они(багтрекеры) не будут работать только на одном компе?

Вполне можете поставить. Только я б порекомендовал для настройки на своей рабочей машине к программистам обратиться всётаки, чтоб долго не возиться(а то если вы новичок в этом деле, много времени можете потратить).

А скажите пожалуйста, я могу сначала втихаря поставить себе на комп десяток багтрекеров, чтобы посмотреть на них, а только потом уговаривать программистов, или они(багтрекеры) не будут работать только на одном компе?

Можете конечно, только смысл вам от этого? Они все похожи. Самые распространённые это: Mantis, Redmine, Bugzilla. В Mantis есть очень много полезного, но мне не нравится его мрачность. Буду смотреть к нему дополнительные модули. Redmine - показался беднее по нужной функциональности, если сравнивать с Mantis. Хоть и симпатичнее. Сейчас читаю про Bugzilla - может поставим, но пока останавливает то, что мне тогда придётся использовать этот баг трекер минимум несколько месяцев. Другие, которые видела и про которых читала - или не понравилось, или за них нужно платить. + если баг трекер экзотический - его сложнее настраивать и интегрировать с системой управления тест кейсами. Если распространён - настройка проще.

Как вариант, можно попробовать portable баг трекеры.

Можете конечно, только смысл вам от этого? Они все похожи.

Ну чтобы разобраться как в них работать, а то всем установим, а я в нем ни бе, ни ме, ни кукареку)

Ну чтобы разобраться как в них работать, а то всем установим, а я в нем ни бе, ни ме, ни кукареку)

Главное, чтобы поставили, а там уже по ходу можно разобраться :)

Небольшое руководство по Mantis на русском. Документация с официального сайта. Можно ещё погуглить.
Руководство по установке Mantis на Windows. Можно попробовать :)


Здесь небольшое сравнение баг трекеров.

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

А зачем?

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

А зачем?

Если завал и есть свободные руки, то почему бы не дать им на выполнение простые тест кейсы?
Как потом передавать дела другому/новому тестировщику?

Главное, чтобы поставили, а там уже по ходу можно разобраться :)

Небольшое руководство по Mantis на русском. Документация с официального сайта. Можно ещё погуглить.
Руководство по установке Mantis на Windows. Можно попробовать :)


Здесь небольшое сравнение баг трекеров.

Спасибо большое!

Нашла на оф.сайте Redmine.

Как попробовать баг трекер Redmine
1. Перейти по ссылке: http://m.redmine.org/hostings/new
2. Заполнить форму корректными данными.
3. Записать себе эти данные.
4. Отправить форму.

После успешного входа,
5. Перейти в админ панель: по ссылке "administration panel".
6. Ввести username и password, которые были записаны.

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

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

Начинайте заранее :)
И все же, я советую JIRA.
У вас большая компания? Если большая, вам на сайте разработки не поверят, что пользоваться ей будет только 10 человек :)
Если небольшая - это стоит 10 долларов в месяц + confluence столько же. Думаю, начальство можно уговорить на такие деньги ))

Но! Раз вы хотите попробовать - это же здорово! Поставьте себе Мантис как бесплатный, посмотрите пару дней, а потом скачайте триалки JIRA + confluence
Вот отсюда - http://www.atlassian.com/try
http://www.atlassian...e/jira/overview - багтрекер, можете посмотреть видео.
http://www.atlassian...luence/overview - вики, очень удобная.

Если вы туда внесете свои ценные мысли, то сможете даже с разработчиками так стыковаться. Записали за ними, потом кинули ссылку - "проверь, я тебя правильно поняла?"
Это лучше тетрадки :)

3-5. Каждая вкладка = 1 кейс? Нечто страшное...
А если много-много кейсов...

Ну видимо много-много вкладок :))
Точнее наверное сказать - одна вкладка одна функциональность)

А как вы сами думаете, удобно это - много-много вкладок? :)

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

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

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

Свалится система на одном из шагов - "кейс провален", а какой именно? Остальные точно нельзя проверить в обход баги?
"1 тест-кейс = 1 проверка", святое правило.
А одна проверка = 1 результат :)

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

Свалится система на одном из шагов - "кейс провален", а какой именно? Остальные точно нельзя проверить в обход баги?
"1 тест-кейс = 1 проверка", святое правило.
А одна проверка = 1 результат :)

Molechka, для того чтоб была читабельность - нужно знать предметную область.
И, если тестируется программа, решающая определенные задачи, тестировщик хорошо знающий предметную область (т.е. вот уже уверенно ориентируется в бухгалтерии/косметологии,работе томографа) может предполагать -как должна себя вести программа. Но только - ПРЕДПОЛАГАТЬ.
Правильность угадаек тетировщика должна быть подтверждена специалистами.

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

А как вы сами думаете, удобно это - много-много вкладок? :)

Ну а как по другому-то, если много функциональностей?

Свалится система на одном из шагов - "кейс провален", а какой именно? Остальные точно нельзя проверить в обход баги?
"1 тест-кейс = 1 проверка", святое правило.
А одна проверка = 1 результат :)

Но я в принципе и получаю один конкретный результат.
Я понимаю, что вы имеете ввиду, но, как бы это сказать, положительный результат тест-кейса будет только в том случае, если все составные части рассчитаются правильно. Я рассчитываю поведение программы, чтобы увидеть в каком месте произошла ошибка. Как аналогия - решение очень сложного уравнения, например, если какая-нить программа считает это уравнение, то тест кейс должен выглядеть:
1.Записать уравнение в программу
2.нажать "рассчитать"
Ожидаемый результат:
42.

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

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

А промежуточные результаты тестируемое ПО где-то отображает? Или вы вводите данные и видите конкретную цифру, в качестве ответа?

А промежуточные результаты тестируемое ПО где-то отображает? Или вы вводите данные и видите конкретную цифру, в качестве ответа?

Да, конечно.
Но только это не совсем промежуточные расчеты, это просто результаты, но мне нужно пройти их все, чтобы вывести положительный ли результат или нет)

А промежуточные результаты тестируемое ПО где-то отображает? Или вы вводите данные и видите конкретную цифру, в качестве ответа?

Да, конечно.
Но только это не совсем промежуточные расчеты, это просто результаты, но мне нужно пройти их все, чтобы вывести положительный ли результат или нет)

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

Нахождение объема.
1. Проверка площади
1. 1. Ввести длину A
1. 2. Ввести ширину B
1. 3. Нажать рассчитать
1. 4. Проверить, что результат равен S = A*B

2. Проверка высоты
2. 1. Ввести высоту H
2. 2. Нажать рассчитать
2. 3. Проверить, что объем равен V = S * H

Расчеты вполне можно вынести в эксель (если их сложность ему по зубам). Тест-кейсы можно хранить там же. Там же можно и баг-репорты писать.

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

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