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

[K_G]

Собственно, вопрос был такой: у вас тысяча тест-кейсов, завтра сдавать проект, понятное дело, что все тест-кейсы вы пройти не успеете, что будете делать?

[vesa]

Собственно, вопрос был такой: у вас тысяча тест-кейсов, завтра сдавать проект, понятное дело, что все тест-кейсы вы пройти не успеете, что будете делать?

определю критичный функционал, если он еще не определен.
выберу тест кейсы, проверяющие этот функционал, и пройду только их.

[Freiman]

Собссно, у нас 2 набора тест-кейсов: критичные и все остальные

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

Критичные кейсы подобраны таким образом, чтобы, во-первых, с их помощью проверить всю основную функциональност, а во-вторых, сделать это не более чем за 1 рабочий день.


Кроме этого, у меня есть мысль разделить их на 3 набора: Critical, High, Normal.
Соответственно, это должно позволить еще быстрее выявить баги с высокой важностью.

[Фрося]

Собссно, у нас 2 набора тест-кейсов: критичные и все остальные

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

Критичные кейсы подобраны таким образом, чтобы, во-первых, с их помощью проверить всю основную функциональност, а во-вторых, сделать это не более чем за 1 рабочий день.


Кроме этого, у меня есть мысль разделить их на 3 набора: Critical, High, Normal.
Соответственно, это должно позволить еще быстрее выявить баги с высокой важностью.

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

[LeshaL]

Собственно, вопрос был такой: у вас тысяча тест-кейсов, завтра сдавать проект, понятное дело, что все тест-кейсы вы пройти не успеете, что будете делать?

Да много чего можно предпринять.
Можно забить на тест кейсы и протестировать продукт на столько на сколько позволяет время. Можно подключить к тестированию других участников разработки. Можно в конце концов и не сдавать проект завтра, ведь если даже во время прогона 1го теста найдется критический дефект - проект не будет сдан, так? А если будет по-любому сдан завтра, даже, несмотря на критические дефекты, то можно вообще не напрягаться особо - прогнать например все 1000 за столько за сколько надо, починить всё да и сделать патч.

[anr]

Я вижу тут две проблемы.

Одна из них, понятно, какие именно тест-кейсы проходить.

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


Насчет первой проблемы:
протестировать новый функционал, обращая внимание на те баги, которые находились в процессе разработки - это вопрос к разработчикам (при таком подходе тест-кейсов для новго функционала Вы не найдете).
Разработчики, кстати, ещё могут подсказать, на что обратить внимание, какую конфигурацию (ось, тд) выбрать.
Если тест-кейсы как-то приоритезированы, и реально пройти критичные, то брошусь их проходить.
Иначе: проведу smoking (exploratory, как хотите называйте) тестирование основного функционала: ставится, запускается, вроде всё на месте, что основные use-case'ы проходят.

[anr]

Вы сами как ответили?
Что Вам сказали собеседователи?

[enki86]

Это было собеседование на вакансию лида?

Если нет - правильный ответ - спросить у менеджера проекта какой из вышеописанных коллегами стратегий воспользоваться
Два плюса вам сразу - во-первых, вы сразу предлагаете варианты решения, во-вторых, вы соблюдаете иерархию и не нарушаете нормальную командную работу
Золото, а не сотрудник :-)

В данном случае, Фрося, мне кажется, не совсем права

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

Никогда не надо ничего прикидывать! Ни в коем случае! Мы-то самые умные, разумеется, и все знаем только так делать не стоит, чтобы в привычку не вошло...
В нетривиальном проекте, тестировщик вряд ли способен достаточно точно все это оценить, если, конечно, не принимал непосредственного участия в разработке.

[Freiman]

Никогда не надо ничего прикидывать! Ни в коем случае! Мы-то самые умные, разумеется, и все знаем только так делать не стоит, чтобы в привычку не вошло...
В нетривиальном проекте, тестировщик вряд ли способен достаточно точно все это оценить, если, конечно, не принимал непосредственного участия в разработке.

не согласен. прикидывать и проверять надо! но только не в том случае, если у нас последний день перед релизом.
если у тестировщика есть время, не занятое прогоном тест-кейсов, то он вполне может "покопать" те области, где были изменения. Мне кажется, тут мы как раз подходим к exploratory testing :)

[Фрося]

Никогда не надо ничего прикидывать! Ни в коем случае! Мы-то самые умные, разумеется, и все знаем только так делать не стоит, чтобы в привычку не вошло...
В нетривиальном проекте, тестировщик вряд ли способен достаточно точно все это оценить, если, конечно, не принимал непосредственного участия в разработке.

Так это ж мой опыт . С теми разработчиками, и на тех проектах - с какими имею дела.

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

[Freiman]

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

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

[Фрося]

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

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

[Freiman]

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

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

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

[Фрося]

Собственно, вопрос был такой: у вас тысяча тест-кейсов, завтра сдавать проект, понятное дело, что все тест-кейсы вы пройти не успеете, что будете делать?

Вообще без знания особенностей Проекта - все предложения только предположения...

Сдавать проект?
Что значит - сдавать?
Показать заказчику, чтоб он (заказчик) подпись поставил - типа, работу принял?
Ну так для этого - в запасе должен быть набор тестов, на которых и показываем заказчику - что все ОК.
А что -не ОК, то ерунда, и устраним-с...по ходу дела...

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

[enki86]

Друзья,
"Давайте отделим мух от котлет" (с) Путин

Кто отвечает в целом за проект?.. Чью... кхм... филейную часть ждеть жестокое наказание за то, что за сутки перед релизом ничего не готово?.. Кто виноват, что процесс разработки и общения не налажен в команде?.. Ответ очевиден?..
Это менеджер проекта. В общем и целом, давайте исключим эфемерне возможности типа это вы такой-сякой(сякая) не хотели ничего проверять, сидели за столиком, поедали дефлопэ с семечками кациуса и плевали на умоляющих вас потестить проект программистов...
Во многих компаниях (если он сам занимается бюджетированием и разработка fixed price), менеджер еще и финансово ответит...

А теперь вопрос - а кто должен принимать решение каким из 199999 способов, известных талантливому тестировщику, прогонять проект за сутки перед релизом? Для меня ответ очевиден.
Грамотный QA всегда что-то там себе думает, что-то разрабатывает, имеет много вариантов поведения, знает закономерности, может строить какие-то выводы и модели на основании своего опыта... НО есть ситуации, когда его опыт может ничего не давать.
Скажем, поменялся не какой-нибудь стандартный контрол, местоположения которого вы прекрасно знаете. А обновления касались деликатных моментов хранимых процедур БД. И что тогда? Пышуший злорадством базист сообщает, что изменения были внесены в процедуры um_ter_del_davai_idi и так далее
Для меня поведение очевидно - идти к менеджеру проекта и вместе решать как избежать самых больших проблем. Он со своим более обширным и полным знанием программной части (именно он ведет всю работу на проекте! а у вас может быть до N таких проектов), вы со своим опытом - где тоньше всего и чаще всего рвется. Пять минут обсуждения принесут гораздо больше пользы, нежели пять минут вашего вдохновения. ИМХО

Фрося, Freiman

Вообще без знания особенностей Проекта - все предложения только предположения...

Именно, но вопрос-то был конкретный.
Давайте не будем уходить в дебри дебревые. Мы зашли в тему, чтобы ответить на конкретный вопрос собеседования. Какой такой опыт может быть у человека, которого не так давно приняли на работу? Кого здесь интересует как бы вы с Фудзиямы своего опыта поступили? (вообще-то меня интересует, но явно не автора...) Вопрос на новичка в команде. Или он студент, который привык сам героически решать проблемы в последнюю ночь (у всех была такая фигня?.. ) или он профессионал, который работает и мыслит в рамках команды.

[Natalya Rukol]

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

enki86, в теории Ваши слова звучат здорово, но на практике - покажите мне менеджера проекта, который вкуривает, что такое риск возникновения ошибки, и который за день до релиза располагает свободным временем для приоритезации тестов!

[enki86]

А я таких знаю...
мне повезло?

[Clauster]

Забить на прохождение кейсов. В этом нет никакого смысла.
В идеальном случае, за день вы сможете пройти всего порядка 70-80 простейших кейсов. Пусть 10% кейсов критичные, это уже 100. Дальше можете прикинуть сами, сколько времени вам потребуется на выявление критичных для релиза кейсов, на инициализацию нужного окружения и их прохождение, занесение ошибок, исправление ошибок, верификация исправленных ошибок и т.д. - за день точно не управиться.
Варианта два - выпускаться уже сегодня (я предполагаю какое-то тестирование все-таки проводилось и статус продукта известен) или сдвигать сроки релиза пока не будет выполнено финальное тестирование прогонят эти 1000 кейсов.

[anatashka]

К сожалению в реальной жизни такие случаи не редкость (лично у меня так часто случалось).

Т.е. с заказчиком оговариваются сроки, которые нарушать никак нельзя. Разработчики тянут до последнего, дорабатывают что-то, или срочно чинят то, что неожиданно сломалось в процессе добавления нового функционала. И даже если везде прописано, что у тестировщика должно быть минимум 3 дня для предварительного тестирования его все равно ставят перед фактом, что его надо сделать за 1 день (ведь нехорошо подводить заказчика.. он же нервничать будет..). Почему только это не так часто говорится разработчикам??? ;-)

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

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

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

[Clauster]

К сожалению в реальной жизни такие случаи не редкость (лично у меня так часто случалось).

Т.е. с заказчиком оговариваются сроки, которые нарушать никак нельзя. Разработчики тянут до последнего, дорабатывают что-то, или срочно чинят то, что неожиданно сломалось в процессе добавления нового функционала. И даже если везде прописано, что у тестировщика должно быть минимум 3 дня для предварительного тестирования его все равно ставят перед фактом, что его надо сделать за 1 день (ведь нехорошо подводить заказчика.. он же нервничать будет..). Почему только это не так часто говорится разработчикам??? ;-)

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

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

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

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