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

[Preston]

Добрый день уважаемые жители форума! Сразу скажу, во избежании лишнего флуда, пришел не жалобы ради, а лишь совета для :)

Дело в том, что я являюсь единственным тестировщиком одной небольшой, но быстрорастущей компании. Работаю в данной компании около 3 месяцев. Компания и начальство просто великолепные, лучше и не придумать. Но, есть все же одно "но". Начальство видимо предполагает, что раз есть в компании тестировщик, то багов в их программах не должно быть вообще, независимо от времени уделенного тестированию.

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

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

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

P.S.
Хочу добавить, что компания и начальство и вправду великолепны. У меня нет на них зла, я понимаю что для них это просто в новизну. Мне не хочется стать жертвой недопонимания и честно, очень хочется работать в данной компании и коллективе. Не потому, что не могу найти другую работу, нет. Перед устройством сюда, я уже прошел собеседования в "Oracle" и еще несколько крупных компаний, но сделал выбор в пользу данной компании.

[Vasiliy]

Список тестов, который вы прогоняете за выделенное время, согласован с руководством? Может оно думает, что вы смотрите в первую очередь совсем другие вещи?
Когда-то был доклад, вроде от Алексея Баранцева, с объяснением "Почему тестирование занимает столько времени?". Там хорошее объяснение есть.

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

[Rebz]

Можно сделать отчет, где будет написано что тестировалось (что протестировано), сколько времени это заняло.
Затем сколько времени ещё нужно, что проверить непокрытые тестированием области. Это будет основанием для увеличения времени, имхо.

[Preston]

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

Список тестов, который вы прогоняете за выделенное время, согласован с руководством?

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

Когда-то был доклад, вроде от Алексея Баранцева, с объяснением "Почему тестирование занимает столько времени?". Там хорошее объяснение есть.

Где найти данный доклад? С удовольствие почитаю.

Можно сделать отчет, где будет написано что тестировалось (что протестировано), сколько времени это заняло.
Затем сколько времени ещё нужно, что проверить непокрытые тестированием области. Это будет основанием для увеличения времени, имхо.

Пробовал, чуть выше описал почему не работает данный подход :)

[Molechka]

Когда-то был доклад, вроде от Алексея Баранцева, с объяснением "Почему тестирование занимает столько времени?". Там хорошее объяснение есть.

Где найти данный доклад? С удовольствие почитаю.

Первая же ссылка в google - http://software-test...-taking-so-long />
Похожий доклад был на confetQA у Алименкова - http://video.yandex..../?ncrnd=2232#hq

[Vasiliy]

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

Там есть оценки выполнения по времени? Вы можете сказать, что если вам дадут 3 часа, то вы проверите столько-то, а если 3 дня - столько?

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

Руководство не участвует в приоритезации?
Те тесты, что вы успеватете прогнать дают ошибки? Их успевают исправить?

Можно сделать отчет, где будет написано что тестировалось (что протестировано), сколько времени это заняло.
Затем сколько времени ещё нужно, что проверить непокрытые тестированием области. Это будет основанием для увеличения времени, имхо.

Пробовал, чуть выше описал почему не работает данный подход :)

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

[Preston]

Первая же ссылка в google - http://software-test...-taking-so-long />
Похожий доклад был на confetQA у Алименкова - http://video.yandex..../?ncrnd=2232#hq

Прошу прощения, подумал что доклад какой-то внутренний. Спасибо :)

Там есть оценки выполнения по времени? Вы можете сказать, что если вам дадут 3 часа, то вы проверите столько-то, а если 3 дня - столько?

Оценок никаких нет. Сказать могу и говорю постоянно. Но, от этого ничего не меняется. Начинают делать "как привыкли", а взгляды неодобрения в мою сторону.

Руководство не участвует в приоритезации?
Те тесты, что вы успеватете прогнать дают ошибки? Их успевают исправить?

Те что я успеваю прогнать, ошибок не дают и исправить успевают, с трудом конечно (но это совсем другая история из ряда "разбалованные программисты" - тут опыта у меня много, с ними справляюсь).

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

[Llanie]

Очень-очень адекватное и замечательное начальство, говорите? Если отношения позволяют, посадите их на своё место. Дайте им какую-нибудь программку, какой-нибудь сырой или обучающий продуктик, и час времени. В жестоком варианте можно ещё попросить писать полноценные дефекты.
От "ты же тестировщик, чего там, нажал там, нажал тут, как можно не найти" обычно помогает.
Или более мягко, если достаточно уверены в себе и отношения, опять же, позволяют, -- посадите начальство рядом с собой следующий раз и покажите, что Вы делаете и как. Принимайте предложения по тому, что сейчас проверять, не спорьте, а делайте максимально быстро и аккуратно. Покажите, сколько времени уходит на оформление дефекта или обходной путь из-за другого дефекта. Говорите вслух, когда прошло 25%, 50%, 75% и 100% отведённого на задачу времени. Скажите потом, что из критичного не успели. Обсудите потом сроки, приоритеты, наборы тестов, степень детализации дефектов и прочее.
Ещё раз подчеркну, что не всегда и не со всеми работает, смотрите сами, подходит ли Вам такой вариант.

Обратите внимание на вопрос от Vasiliy:

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

Попробуйте немного попиариться, в хорошем смысле слова. На вопрос "А почему ты не нашел эту ошибку?" ответьте не "недостаточно времени, бубубу", а с "зато нашёл и добился исправления вот этого, чтобы пользователь вообще смог зарегистрироваться и дойти до этой кнопки, было бы больше времени, бубубу", условно говоря. Подгоните там под свои отношения и проекты.

Если ещё не начали, подумайте о мелкой автоматизации. Не тратите ли Вы слишком много времени на установку? регистрацию? генерацию данных? переход к нужной менюшке восемьдесят пятого уровня?

Да, и не берите на себя лишнего, тестировщик обычно и не должен решать, релизиться ли. Не спорьте, что нельзя "лететь в релиз", не проверив всё тщательно. Они до Вашего появления так и делали, и ничего, не утонули, развиваются, доросли до того, что нашли деньги на тестировщика. Может, у них сроки горят и важнее КОГДА, чем КАК. Например, пользователи привыкли, что новая фича выходит как раз к воскресному полднику, а Вы тут со своими томами чек-листов.

Кстати, если за час не прочитать Ваших тестовых сценариев, то не показывайте их все, покажите только оглавление, сам список необходимых проверок. Можно добавить примерное время выполнения в идеале и со средним по больнице количеством дефектов.

И, может быть, спросите прямо в лоб у начальства, недовольно ли оно Вами или существованием ошибок? Это две разные вещи и решать их надо с разных сторон.

[notProgrammer]

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

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

Вообще.... Вам столько полезных советов написали: и чеклисты писать, и с начальством согласовывать... Не хочется демотивировать прямо... Но из личного опыта: 99%, что ситуация не изменится. Эти люди все девелоперы (если не по нынешней должности, то в душе). Они и дальше будут думать, что Вам не нужно читать спеку чтобы тестировать; что вам можно выслать документацию вместе с новым билдом за час до релиза, а через 10 минут спросить: "Ну как оно? Нормально выглядит?". Для них Ваша работа - так, кнопочки беспорядочно нажимать. Можете попытаться изменить мир и перевоспитать их... Но в положительный результат не верю. Простите. />

[Vasiliy]

А зачем цитату одного человека приписали другому?)

[Mac]

Их можно и нужно воспитывать. Но только с пониманием их "особенностей". Чеклисты точно читать никто не будет. С начальством надо по-простому, циферками, желательно на языке рублей и трудозатрат. Это сложно. Это требует наличия soft skills и умения осознать и поставить себя полноправным участником процесса, а не обезьянкой с улицы, которая только и умеет что тыкать кнопки.

1. Перед началом тестирования - планируем и оцениваем. Четкий список тех самых критических проверок, которые вы собираетесь пройти за данные вам 3-4 часа.

2. Этот самый список - письмом начальству. Недвусмысленно дав понять, что за данное время будут пройдены эти и только эти проверки. Читать они не будут, но на будущее - пригодится.
2.1. Опционально - пояснение, что вам кажется необходимым пройти еще такие-то критические проверки, на что требудется дополнительно X часов. И такие-то менее критичные, но все равно важные, на что требуется еще N часов.
2.2. Далее топаем ножками к начальству и говорим по душам.

3. После релиза - анализ просочившихся к пользователю дефектов.
3.1. Могли найти их теми кейсами, которые изначально запланировали пройти? Тогда сами себе Злая Буратина, посыпаем голову пеплом, делаем работу над ошибками, в следующий раз тестируем более лучше.
3.2. Могли бы, но в тех самых кейсах, которые были в дополнительных X или N часах? Топаем к начальству, говорим по душам. При себе имеем оценку трудозатрат на починку бага, передеплой в продакшене и отпаивание кастомеров элитным коньяком а сейлзов - валокардином. Тогда совсем хороший разговор получается, вида "Иваныч, лысый ты хрен, вот дал бы дополнительный 1 час тестирования - съэкономил бы 8 человеко-часов работы по починке дефекта в продакшене и чёртзнамосколько денег в виде репутационных потерь".
3.3. Не могли бы, поскольку таких проверок не было? Оцениваем трудозатраты на создание новых тесткейсов, или на проведение исследовательского тестирования. Опять топаем к начальству и говорим по душам.

Повторяем несколько итераций подряд. Рано или поздно - получится ;)

PS: "Insanity: doing the same thing over and over again and expecting different results" - Albert Einstein

[krukovskiy]

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