Сообщений в теме: 31

[frei_by]

Устроился на работу тестировщиком, в конце этого лета. До этого работал инженером эенергетиком. Надоело, решил попробовать начать карьеру в IT.

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

Когда я пришёл уже была установлена BTS TargetProcess, с более менее удобной системой трэкинга багов. Документации тоже только тень, удобно зато что я нахожусь в одном помещении с программистами (около 10 человек) и можно подойти и спросить если что-то неясно.
Требования и документацию восстанавливаю через аську. Прямо так в план и заношу логи разговоров.

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

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

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

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

Короче много всякого. Может через пару лет напишу чем кончится...

[CVD]

Как насчет стратегии тестирования? Вроде как не упомянута.

[saezar]

Надо же, как неожиданно всплыла тема!
Сколько же я на форуме не появлялся... Кошмар.

[frei_by]

Как насчет стратегии тестирования? Вроде как не упомянута.

Вот давеча написал тестовый план (дизайнеры вместе с жаба-скриптчиками переделалаи корзину в магазине и поставили задание проверить корректность работы ++ "краш тест") :

2. План тестирования, [TP]

Введение.
Данный документ представляет из себя план тестирования модуля, осуществляющего функции стандартной корзины в системе магазинов. План предназначен для организации тестирования модуля после выполненных в модуле доработок. В рамках данного плана предполагается выполнить ограниченное функциональное тестирование работы корзины. Тестирование производится с точки зрения конечного пользователя (клиентский уровень). Разработанные тесты могут быть использованы для приёмочного тестирования.

Тестируемая система.
Тестируемая система представляет из себя магазин расположенный по адресу http://***/ доступный через сеть Интернет с сервера ***. Требования к системе описаны в SRS. У модуля можно выделить 4 режима работы, указанных в п.1.3. Режимы отличаются количеством шагов, которые покупателю необходимо выполнить для оформления заказа.

Тестируемые аспекты
В рамках данного плана предполагается выполнить (для каждого из вариантов режима работы соотв.):
1. Корректное функционирование системы: последовательность шагов, возможность вернутся по шагам, корректные данные заказа для каждого шага независимо от того, проходит ли покупатель шаги последовательно от первого до последнего, либо переходит с одного шага вперёд либо назад.
2. корректность расчёта величин для всех возможных валют,
3. корректность сопоставления доставка – способ оплаты – доступные валюты для данного способа
4. Валидация вёрстки, кроссброузерность: IE6 + Mozila FF 3.6. + Opera 10.62
5. Цитата из задания «by <тим лидер дизайнеров> - и просто краш-тест» - в рамках краш теста намеренное искажение данных с целью сформировать ошибочный заказ.

Не тестируемые аспекты
Настройки специфических электронных видов расчёта для корзины, как-то WebMoney и т.п.
Безопасность корзины в плане похищения конфиденциальных данных покупателя (номер паспорта, адрес и т.п.), способ передачи данных для сторонних платёжных систем.
Подмодуль «сообщения в корзине», подмодуль «получение заказов» - и общая корректность работы корзины со стороны продавца.
Нефункциональное тестирование, в том числе нагрузочное тестирование, тестирование производительности, тестирование удобства использования (usability)

Подход к тестированию
Уровень тестирования системное, с точки зрения конечного покупателя. Основная часть функционального тестирования будет выполнена вручную. «краш-тест» будет выполнен с использованием Jmeter путём искусственного создания запросов к системе. Метрики для ручного тестирования – покрытие путей модели, описанных в TDS. Метрики для автоматизированного краш теста – покрытие путей модели описанных для раздела автоматического краш-теста TDS.

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

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

Поставка.
В результате выполнения данного плана должны появится:
Документ [TDS]
Комплект тестов, оформленный в виде [TSC]. Будут созданы два комплекта тестов – для ручного тестирования и для автоматизированного «краш-теста».

Требования к окружению.
Никаких.
(цитата из лога аськи)
<тим лидер програмистов>14:36
нагрузка не предсказуема
<тим лидер програмистов>14:37
то есть, может быть на 15 минуте быть, потом 15минуте 14 секунде, пропасть

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

Первое время это напоминало партизанскую оборонительную войну - ставится задание - я вообще первое время никаких документов не оформлял, а сразу писал баги в трекер на задание. Баги правят - задание приходит ко мне. Я пишу новые - отправляю назад. Их исправляют - возвращают ко мне. Обычно после двух трёх перебросок кое-как закрывали задание, но при этом треть багов переносились как доработки на потом...

Сейчас - когда приходит новое задание, пробую начинать оформлять на него план тестирования.
Что-нибудь посоветуете?

[Oregu]

Приветствую всех!

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

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

Подскажите пожалуйста, есть ли какие-нибудь правила организации тестирования модульных систем?

Спасибо!

[contestar]

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

[bsu26]

Приветствую всех!
Ситуация подобная, первый тестировщик, документации нет. Баги сразу заносятся в задачи, после исправления возвращаются ко мне.
Работаю тестером недавно, хотелось бы узнать о разработке стратегии и плана тестирования.
Спасибо. Тема, действительно, очень интересная.

[Sataly]

Моя ситуация примерно как у всех вышеотписавшихся. Есть продукт без т.з. и т.п., который писали, писали, использовали, дописывали, а теперь решили тестировать.
Мой совет: Надо просто брать и описывать все подряд. Как протокол осмотра места преступления... все подряд... параллельно структурируя информацию. "Разбить" продукт на фрагменты/модули или как в вашем конкретном случае и постепенно все описывать.

Баги сразу заносятся в задачи, после исправления возвращаются ко мне.

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

Вспомнился стишок:
Если вас трамвай задавит,
вы конечно вскрикнете,
раз задавит, два задавит,
а потом привыкнете.

[kokos68]

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

[DiNoS]

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

Да я читаю и улыбаюсь, действительно с некоторыми постами один в один ситуация. Нету ни ТЗ, ни требований, ни актуальной документации в целом. Подошел к проблеме следующим образом:

• Написал план внедрения тестирования в процесс разработки (Если коротко, то там по пунктам цели и задачи тестирования, анализ бизнес-процессов, нормативное и регламентное обеспечение отдела, порядок проведения тестирования, основные проблемы, этапы развития);
• Потом тупо сел с тех. поддержкой и поработал с ними изучая продукт, потом подошел к программистам и с их стороны рассмотрел продукт. Представления о продукте оказались разными. Тех. поддержка воспринимала продукт по названию компаний эксплуатирующих его, а прогеры по названию определенных его модулей;
• В "свободном полете" побегал по продукту, попутно занося баги в БТС;
• Написал тест-кейсы (хотя для экономии времени они больше смахивают на чек листы, пришлось опустить детализацию , с благословения прожект менеджера, из-за экономии времени) и более детально прошелся по продукту, отсеяв еще большее количество багов.
• В итоге прогеры сели за исправление багов, а я попутно проверял исправленное регрессионно. В остальное время более детально начал расписывать тесты и придумывать новые.

P.S. Естественно я очень коротко описал свою ситуацию. Какими программами или методами я пользовался, если кому интересно, можете спросить дополнительно.

[floyder]

Если у вас отсутствует документация на проект, добро пожаловать в scrum. Для начала советую определиться с целью тестирования. Если цель - сделать заказчика счаствливым, тогда читаем дальше.
1. Ежедневные митинги с обсуждением тасков - позволят структурировать информацию и выбрать приоритеты (кто-то должен писать или озвучивать юзер кейсы)
2. Планнинг покер и другие игрушки - позволяют обмениваться участникам горизонтальной информацией

[jjjzmey]

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