На правильном ли я пути?
#1
Отправлено 03 апреля 2012 - 13:33
Я уже работаю тестером аж три месяца, и более менее освоилась: Прочитала много мануала, просмотрела записи конференций, стала усиленно вспоминать забытые языки программирования, немного разобралась с TestComplete, однако большим пробелом остаются багтрекеры :)
Как я уже писала в одной из тем, отдела тестирования или какого-либо тестирования отдельно от программистов в моей компании не было, поэтому я все сделала с нуля и не уверена, что правильно.
И на данном этапе я прошу указать мне на мои недочеты.
Итак, как я организовала работу лично для себя.
1. Если начинают разрабатывать какой-то новый Плагин я сижу рядом и конспектирую задачи, потому что ТЗ, как такового, обычно нет
2. В большинстве случаев у меня на руках небольшое описание уже готового продукта, поэтому я завожу новую тетрадочку и сначала руками расписываю чего я хочу проверить
3. Вся фиксация работы происходит в Excel'e, Я создаю файлик <ProductName>_Test_Suite, в котором куча вкладок, каждая из которых это какой-то тест-кейс.
4. Если тест кейс не требует сложных рассчетов, то он существует только в файле <ProductName>_Test_Suite, а если нужно проверять результаты каких-либо изменений, то в другом файлике я теоретически рассчитываю результаты тест-кейсов уже на конкретном примере, а потом на этом же примере сравниваю уже с фактическими результатами
5. Если найдены какие-то баги, то запихиваю их в третий файлик <ProductName>_bugs
Вот я прицепила файлик, как это выглядит. Exemple.rar 837,43К 56 Количество загрузок:
Там пример Тест-Комплекта, Контрольного примера, и Баг-репорта.
Я прошу вас сказать похоже ли это на правду?
Заранее спасибо! )
#2
Отправлено 03 апреля 2012 - 14:43
1. Правильно, вы молодец! :) Раз ТЗ нет, то хоть так))) Я вот тоже на новой работе с блокнотиком бегаю, уже найти не могу, что куда записывала, много страниц задействовано...
2. Лучше бы сразу на wiki\confluence, так как ваши тетрадочки потом пропадут, а так хоть история будет...
3-5. Каждая вкладка = 1 кейс? Нечто страшное...
А если много-много кейсов...
Имхо, не стоит прям совсем подробно расписывать.
Посмотрела ваш файлик с багами, мне неясно.
Страница "Баг №6" например. Вроде одна ошибка, но на каждый шаг написан ожидаемый результат... И итоговый.
Но ведь если они различаются - это баг, причем отдельный. А если нет, зачем для каждого шага писать результаты?
В багтрекере обычно пишут так:
То есть результат один на все ваши шаги :)Шаги:
1.
2.
3.
Результат:
...
Ожидаемый результат:
...
И очень советую использовать таки багтрекер, а не эксель. Проще + история...
JIRA для маленьких компаний чуть ли не 10 баксов стоит...
В общем, баг-репорт странный :)
Я и в экселе писала шаги тест-кейса прямо в одной ячейке:
1.
2.
3.
И рядом ожидаемый результат :)
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#3
Отправлено 03 апреля 2012 - 15:23
#4
Отправлено 03 апреля 2012 - 16:27
Но попробуйте как-то уговорить программистов поставить хотя бы Mantis или любой другой баг трекер. Лучше ещё и Test Link. Это бесплатные инструменты. Mantis, насколько знаю, не сложно поставить. У меня знакомые руководители проектов, не программеры, сами ставили. Можете сами попробовать поставить))
+ Test Link можно интегрировать с Mantis.
Molechka права на счёт wiki.
Тетрадки это конечно хорошо. Но информация очень неупорядочена, долго искать, нельзя дать другому человеку. А в wiki, если что и программер подправит что-то, или сам добавит.
Подобные инструменты помогут сэкономить вам массу времени. И не только вам. Вашему руководству будет проще получить всю информацию о проекте.
#5
Отправлено 04 апреля 2012 - 05:24
2. Лучше бы сразу на wiki\confluence, так как ваши тетрадочки потом пропадут, а так хоть история будет...
Руками проще и удобнее, это конечно занимает доолнительное время, но так меньше риска, что я что-то пропущу. Думаю со временем от этого отойду)
Ну видимо много-много вкладок :))3-5. Каждая вкладка = 1 кейс? Нечто страшное...
А если много-много кейсов...
Точнее наверное сказать - одна вкладка одна функциональность)
Ну тут скорее специфика самой тестируемой программы. Чтобы получить итоговый ожидаемый результат, мне нужно его рассчитать, собсно я его и рассчитываю теоретически, а потом сравниваю на каком этапе пошло расхождение.Посмотрела ваш файлик с багами, мне неясно.
Страница "Баг №6" например. Вроде одна ошибка, но на каждый шаг написан ожидаемый результат... И итоговый.
Может быть непонятно, потому что вы не знакомы с той в программой, в которой я тестирую плагины? Все тест кейсы предполагают, что человек знает как "создать ордер" - без этого никак)Как совет могу сказать, что ваши кейсы должны быть в таком виде, чтоб любой человек смог разобраться,в вашем же случае я что-то совсем мало что понял.
Но попробуйте как-то уговорить программистов поставить хотя бы Mantis или любой другой баг трекер.
А скажите пожалуйста, я могу сначала втихаря поставить себе на комп десяток багтрекеров, чтобы посмотреть на них, а только потом уговаривать программистов, или они(багтрекеры) не будут работать только на одном компе?
Всем огромное спасибо за ответы!
#6
Отправлено 04 апреля 2012 - 07:22
Вполне можете поставить. Только я б порекомендовал для настройки на своей рабочей машине к программистам обратиться всётаки, чтоб долго не возиться(а то если вы новичок в этом деле, много времени можете потратить).А скажите пожалуйста, я могу сначала втихаря поставить себе на комп десяток багтрекеров, чтобы посмотреть на них, а только потом уговаривать программистов, или они(багтрекеры) не будут работать только на одном компе?
#7
Отправлено 04 апреля 2012 - 08:05
А скажите пожалуйста, я могу сначала втихаря поставить себе на комп десяток багтрекеров, чтобы посмотреть на них, а только потом уговаривать программистов, или они(багтрекеры) не будут работать только на одном компе?
Можете конечно, только смысл вам от этого? Они все похожи. Самые распространённые это: Mantis, Redmine, Bugzilla. В Mantis есть очень много полезного, но мне не нравится его мрачность. Буду смотреть к нему дополнительные модули. Redmine - показался беднее по нужной функциональности, если сравнивать с Mantis. Хоть и симпатичнее. Сейчас читаю про Bugzilla - может поставим, но пока останавливает то, что мне тогда придётся использовать этот баг трекер минимум несколько месяцев. Другие, которые видела и про которых читала - или не понравилось, или за них нужно платить. + если баг трекер экзотический - его сложнее настраивать и интегрировать с системой управления тест кейсами. Если распространён - настройка проще.
Как вариант, можно попробовать portable баг трекеры.
#8
Отправлено 04 апреля 2012 - 08:16
Можете конечно, только смысл вам от этого? Они все похожи.
Ну чтобы разобраться как в них работать, а то всем установим, а я в нем ни бе, ни ме, ни кукареку)
#9
Отправлено 04 апреля 2012 - 08:55
Ну чтобы разобраться как в них работать, а то всем установим, а я в нем ни бе, ни ме, ни кукареку)
Главное, чтобы поставили, а там уже по ходу можно разобраться :)
Небольшое руководство по Mantis на русском. Документация с официального сайта. Можно ещё погуглить.
Руководство по установке Mantis на Windows. Можно попробовать :)
Здесь небольшое сравнение баг трекеров.
#10
Отправлено 04 апреля 2012 - 09:08
А зачем?Как совет могу сказать, что ваши кейсы должны быть в таком виде, чтоб любой человек смог разобраться,в вашем же случае я что-то совсем мало что понял.
SQL для тестировщиков
Тренинги по HP QTP и автоматизации тестирования
Если минарет, значит выше всех (с)
#11
Отправлено 04 апреля 2012 - 09:35
А зачем?
Как совет могу сказать, что ваши кейсы должны быть в таком виде, чтоб любой человек смог разобраться,в вашем же случае я что-то совсем мало что понял.
Если завал и есть свободные руки, то почему бы не дать им на выполнение простые тест кейсы?
Как потом передавать дела другому/новому тестировщику?
#12
Отправлено 04 апреля 2012 - 09:47
Главное, чтобы поставили, а там уже по ходу можно разобраться :)
Небольшое руководство по Mantis на русском. Документация с официального сайта. Можно ещё погуглить.
Руководство по установке Mantis на Windows. Можно попробовать :)
Здесь небольшое сравнение баг трекеров.
Спасибо большое!
#13
Отправлено 04 апреля 2012 - 12:52
Как попробовать баг трекер Redmine
1. Перейти по ссылке: http://m.redmine.org/hostings/new
2. Заполнить форму корректными данными.
3. Записать себе эти данные.
4. Отправить форму.
После успешного входа,
5. Перейти в админ панель: по ссылке "administration panel".
6. Ввести username и password, которые были записаны.
И дальше создавать проекты, назначать полномочия, баги и т.д. :)
#14
Отправлено 06 апреля 2012 - 05:03
Руками проще и удобнее, это конечно занимает доолнительное время, но так меньше риска, что я что-то пропущу. Думаю со временем от этого отойду)
Начинайте заранее :)
И все же, я советую 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 результат :)
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#15
Отправлено 06 апреля 2012 - 06:19
Специфика программы не должна влиять на читабельность кейсов. И все тестировщики, составляя план, кейсы, в идеале должны именно угадывать поведение системы, а не писать по существующему функционалу.
Но у вас в любом случае - шаги + результат. Не надо писать на каждый шаг результат, иначе это получается 10 кейсов в одном.
Свалится система на одном из шагов - "кейс провален", а какой именно? Остальные точно нельзя проверить в обход баги?
"1 тест-кейс = 1 проверка", святое правило.
А одна проверка = 1 результат :)
Molechka, для того чтоб была читабельность - нужно знать предметную область.
И, если тестируется программа, решающая определенные задачи, тестировщик хорошо знающий предметную область (т.е. вот уже уверенно ориентируется в бухгалтерии/косметологии,работе томографа) может предполагать -как должна себя вести программа. Но только - ПРЕДПОЛАГАТЬ.
Правильность угадаек тетировщика должна быть подтверждена специалистами.
А для программ, которые что-то считают, порой логично собирать в кучу проверки расчетов.
В примере вроде как проверяется, как состояние двух мастеров меняется при изменении курса валюты.
)) понятия не имею - что есть мастер и аккаунт , потому даже не буду предполагать -разносит проверки по разным тест-кейсам или нет.
#16
Отправлено 06 апреля 2012 - 09:34
А как вы сами думаете, удобно это - много-много вкладок? :)
Ну а как по другому-то, если много функциональностей?
Свалится система на одном из шагов - "кейс провален", а какой именно? Остальные точно нельзя проверить в обход баги?
"1 тест-кейс = 1 проверка", святое правило.
А одна проверка = 1 результат :)
Но я в принципе и получаю один конкретный результат.
Я понимаю, что вы имеете ввиду, но, как бы это сказать, положительный результат тест-кейса будет только в том случае, если все составные части рассчитаются правильно. Я рассчитываю поведение программы, чтобы увидеть в каком месте произошла ошибка. Как аналогия - решение очень сложного уравнения, например, если какая-нить программа считает это уравнение, то тест кейс должен выглядеть:
1.Записать уравнение в программу
2.нажать "рассчитать"
Ожидаемый результат:
42.
Но только, чтобы узнать этот результат, мне нужно решить этот пример руками с промежуточными расчетами.
И если, допустим, эта программа показывает ход решения, а я знаю этот алгоритм, то я могу сравнивать промежуточные данные, чтобы найти ошибку, может оно просто умножает неправильно, И как же мне это отражать в тест-кейсе?
Насчет читабельности, я прошу уточнить в каком месте непонятно, ибо, по-моему, я просто пишу пошагово свои движения мышкой. :)
#17
Отправлено 06 апреля 2012 - 11:22
#18
Отправлено 06 апреля 2012 - 15:06
А промежуточные результаты тестируемое ПО где-то отображает? Или вы вводите данные и видите конкретную цифру, в качестве ответа?
Да, конечно.
Но только это не совсем промежуточные расчеты, это просто результаты, но мне нужно пройти их все, чтобы вывести положительный ли результат или нет)
#19
Отправлено 06 апреля 2012 - 15:21
Я бы несколько иначе организовал сам процесс. То, что Вы называете тест-кейсом, это целый тестовый сценарий (последовательность тест-кейсов, которую необходимо выполнить, для завершения сценария). Расчеты промежуточных результатов -- это уже тест кейсы. Т.е. пишем примерно такой сценарий:Да, конечно.
А промежуточные результаты тестируемое ПО где-то отображает? Или вы вводите данные и видите конкретную цифру, в качестве ответа?
Но только это не совсем промежуточные расчеты, это просто результаты, но мне нужно пройти их все, чтобы вывести положительный ли результат или нет)
Нахождение объема.
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
Расчеты вполне можно вынести в эксель (если их сложность ему по зубам). Тест-кейсы можно хранить там же. Там же можно и баг-репорты писать.
#20
Отправлено 07 апреля 2012 - 04:45
Плохой совет. Любой человек не придет и не начнет тестировать, а времени на написание такого рода тестовых описаний уйдет много и будут они еще скорее всего трудно-пререписываемы и быстро-устареваемы.Как совет могу сказать, что ваши кейсы должны быть в таком виде, чтоб любой человек смог разобраться,в вашем же случае я что-то совсем мало что понял.
Писать тестовые описания, на мой взгляд, надо так, чтобы они были максимально понятны участникам процесса. При этом желательно, чтобы это не отнимало много времени (ведь тестировать важнее, чем писать описания) и чтобы были устойчивы к незначительным изменениям.
Alexey
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных