Нужна помощь - совет опытного тестировщика

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

 

Я устроился на новую работу QA Engineer, (до этого работал тестировщиком года полтора), причем QA в полном смысле этого слова. Мне надо постравить процесс тестирования "с нуля". Фирма занимается разработкой приложения (веб, андроид, айос) и релиз будет через месяца полтора. 

Директор выслал что то вроде qa протокола, где написано что мне по идее надо делать

Test Strategy Document.

Среди пунктов:

- бизнес ищщус - не пойму что это?

- индустри стандартс ту фоллоу - а где эти стандарты брать то?

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

-Testing Measurements and metrics - расскажите пожалуйста что такое эти метрики в конкретном моем случае.

-Risks and mitigations - что такое риски я тоже не очень понимаю, откуда эту инфу брать?

 

 В разделе мобильное тестирование написано

Successful testing must take into account the functionality, security, performance, compatibility 

 

- возможно ли самому сделать секьюрити, стресс, перформанс тестинг если до этого его не делал? И если на вебе еще куда ни шло (sql иньекцию сделать), то как это сделать на приложении андроид и айос?
 

Мне надо создать мастер тест план, где будет описано как я собираюсь тестировать, туда же

-Test approach, data, environment, tools

-And assumptions, risks and limitations. 

 

И еще вопросы: нужно ли тестировать старые версии броузера, как создать матрицу где будут покрыты разные броузеры и версии (я ж не буду полностью проверять сайт на каждом броузере каждой версии)

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

Где держать документацию? Там предлагают Testlink но не проще ли где нибудь в гугл доке держать?

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

В доках писать позитив сценарии и рядом негатив?

Т.е. вам нужно по имеющейся стратегии тестирования проводить тестирование или что?

Что от вас хочет руководство? 

Сколько у вас тестировщиков? 

Сколько разработчиков? 

В какой системе разработчикам ставятся задачи? 

Есть ли документация по проекту (ТЗ, спецификации и пр.)?

 

Мне надо создать мастер тест план, где будет описано как я собираюсь тестировать

Что имеется в виду под созданием некоего "мастер тест плана"? А стратегия, которую вам дали - это не оно?

 

- бизнес ищщус - не пойму что это?

там так и написано по русски "бизнес ищщус"? :) Скорее всего это описание бизнес-задач, которые должны быть реализованы (в этом релизе или вообще)

 

 

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

Зависит от поддерживаемых вашим приложением браузеров (на это должны быть требования)

 

Где держать документацию? Там предлагают Testlink но не проще ли где нибудь в гугл доке держать?

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

Т.е. вам нужно по имеющейся стратегии тестирования проводить тестирование или что?

- никакой стратегии тестирования, все с нуля. Мне просто написали что то вроде инструкции как я должен работать

 

Что от вас хочет руководство? 

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

Сколько у вас тестировщиков? 

 - Я один (есть возможность нанимать кого то, но не хотелось бы к этому прибегать)

Сколько разработчиков? 

 - около 8

В какой системе разработчикам ставятся задачи?

- в Gitlab, там же и баги пишу 

Есть ли документация по проекту (ТЗ, спецификации и пр.)?

- есть да, ТЗ страничек на 20, там описано как себя ведет приложение и какие там есть функции.

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

И как вы проверяете различные разрешения мониторов для тестирования веба? (Я пока что нашел разширение Screen Resolution Tester для хрома)

 

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

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

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

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

На мобильные версии и на тестирование безопасности, имхо, нужны отдельные специально обученные люди.

 

 

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

 

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

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

 

 

 

- есть да, ТЗ страничек на 20, там описано как себя ведет приложение и какие там есть функции.

ТЗ страничек на 20, т.е. либо у вас совсем небольшой проект (тогда не очень понятно, зачем 8 разработчиков), либо у вас хреновое ТЗ и детали надо выяснять у тех кто в курсе (аналитики, бизнес, начальство, программисты и т.д.)

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

 

Да, и еще такое имхо: если вы один тестировщик на проекте, то вы именно тестировщик, а не QA.

 

И пожалуйста, про риски расскажите

Про риски есть много чего в интернетах - наберите в гугле "Управление рисками в ИТ проектах" или "Управление рисками в тестировании ПО". Но я считаю, что рисками должен заниматься менеджер проекта или тест-менеджер, видимо ни того, ни другого у вас нет.

 

Про матрицы, видимо, вы это имеете в виду: http://iiba.ru/requi...ability-matrix/ да и тоже погуглите, в интернете много информации по этой теме.

 

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

 

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

Удачи! :)

Я устроился на новую работу QA Engineer, (до этого работал тестировщиком года полтора), причем QA в полном смысле этого слова. Мне надо постравить процесс тестирования "с нуля". Фирма занимается разработкой приложения (веб, андроид, айос) и релиз будет через месяца полтора.

Широкий фронт работ - это хорошо.
 

Директор выслал что то вроде qa протокола, где написано что мне по идее надо делать
Test Strategy Document.

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

И немного по конкретным вопросам:

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

Опять же обсудить, что вы поддерживаете и какая ЦА. От ЦА может зависеть - будет ли делаться упор на флагманы и популярные модели + ОС последних версий или же придётся поддерживать более широкий зоопарк. В любом случае не будет лишним изучить актуальную ситуацию по распространённости ОС (найти свежий обзор рынка мобильных девайсов не должно составить труда).

И как вы проверяете различные разрешения мониторов для тестирования веба?

Chrome devTools в помощь. Вообще, если до этого и веб плотно не тестировали, то задача представляется архисложной.

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

 

Сколько у вас тестировщиков? 

 - Я один (есть возможность нанимать кого то, но не хотелось бы к этому прибегать)

Кому не хотелось бы? Вам или вашему руководству?

 

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

 

От кого вы скрываетесь, что даже термины боитесь называть своими именами?

 

 

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

Почитайте вот эту тему:

http://software-test...-testirovanija/

 

"Они" - это руководство компании?

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

 

У меня сложилось впечатление, что руководство автора темы совершенно не понимает, чего хочет. Реально, такое впечатление, что хотят внедрить всё, что нагуглить удалось :)

 

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

Одно дело на собеседовании в теории полялякать, другое дело самому организовывать процессы

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

Вас скорее всего взяли за рублей 70, иностранцы наверное, т.к. много терминов на английском. За такую работу нужно требовать минимум в 2 раза больше. Если же Вам хорошую сумму дали, то непонятно, каким образом взяли, наверное их тупые тесты прошли успешно. Тогда испытательный срок не пройдете, т.к. ошиблись они в Вас. Эх, сколько хорошей работы пропадает... к-но, при подкованном в техническом вопросе рук-ве.

Одно дело на собеседовании в теории полялякать, другое дело самому организовывать процессы

Ну, извините, вопросы были в стиле "что это такое" и "где это брать"...

 

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

 

У меня сложилось впечатление, что руководство автора темы совершенно не понимает, чего хочет. Реально, такое впечатление, что хотят внедрить всё, что нагуглить удалось :)

 

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

 

Так может вы расскажете об оценке рисков и возможности их снижения? Это тема уровня senior и выше.

Или вы готовы рассказать о метриках в тестировании? Что, как, почему, для чего будет оценивать? Кому предоставлять отчет и кто несет ответственность?

Бизнес задачи - тоже  не уровень junior или middle специалиста.

И я не слышал о junior специалистах умеющих проводить тестирование безопасности iOS и Android Приложений.

 

 

 

С другой стороны определить зоны ответственности отдела тестирования, составить план работ до релиза (на написание стратегии тестирования у автора нет ни опыта, ни времени). Сейчас ему нужно определиться с тем, за что он несет ответственность и в каком случае он её несёт. Затем эту зону ответственности автор собой закрывает. И в случае, если он не успевает, он сразу идет к начальству и говорит, что ВСЕ ПРОПАЛО, нужно срочно принять меры (автор докладывает начальству комплекс мер, которые помогут решить задачи которая стоит перед отделом тестирования). В любом случае нужно узнать у начальства, что нужно СРОЧНО ВПЕРВУЮ очередь сделать, а что может подождать. 

Ну они хотят что бы небыло багов. В одном видео Руколь говорила что план тестирования должен быть не больше 2 страниц что б его легко было корректировать каждый день. Повторюсь, одно дело в теории рассказать что да как, другое дело применять это все когда ты единственный человек ответственный за качество. И вот еще вопрос. Допустим меня спросят, сколько надо времени что б полностью протестировать билд. Так вот что будет входить в это "полное тестирование"? К примеру негативные тест кейсы надо исполнять в каждом билде? Секьюрити тестинг же нет смысла делать каждый билд к примеру? Или всякие девайсовые фичи в стиле прерывания, слабой батареи и тд - это вообще наверное достаточно 1 раз проверить или как? И как часто должны разработчики поставлять мне билды?

 

 

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

 

У меня сложилось впечатление, что руководство автора темы совершенно не понимает, чего хочет. Реально, такое впечатление, что хотят внедрить всё, что нагуглить удалось :)

 

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

 

Так может вы расскажете об оценке рисков и возможности их снижения? Это тема уровня senior и выше.

Или вы готовы рассказать о метриках в тестировании? Что, как, почему, для чего будет оценивать? Кому предоставлять отчет и кто несет ответственность?

Бизнес задачи - тоже  не уровень junior или middle специалиста.

И я не слышал о junior специалистах умеющих проводить тестирование безопасности iOS и Android Приложений.

 

Даже не знаю в таком случае, что может мешать джуниору или миддлу знать об оценке рисков, метриках в тестировании и бизнес задачах.

Но я не хочу с вами спорить. Уверен, опыта у вас больше. Заканчиваю оффтопить и удаляюсь.

Ну они хотят что бы небыло багов. В одном видео Руколь говорила что план тестирования должен быть не больше 2 страниц что б его легко было корректировать каждый день.

Ох уж это высшее руководство. Чтобы не было багов можно запретить разработчикам писать код)

У вас не будет времени корректировать план каждый день, имхо. 

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

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

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

Не знает термина? Будучи джуном, я бы задумался принимать ли оффер такой компании.

Во 1х меня на собеседовании ничего такого не спрашивали, а во 2х повторюсь языком вертеть не мешки тягать :) Одно дело сказать что такое тест план, другое дело написать его. Я задаю такие вопросы не потому что хочу увидеть ответы из гугла. Мне интересно как бы вы поступили конкретно в моей ситуации. Надо себя ставить на место заказчика что бы понимать почему все так происходит. Заказчик сам немного далек от айти, и хочет повысить качество продукта за счет тестировщика. Не надо искать подлянки и тд

Заказчику, который хочет повысить качество за счет тестирования нужен не тестировщик, а человек, который объяснит, что так не бывает)

По сути вам уже ответили - http://software-test...chika/?p=140252

Документ вашего директора положите пока что на полку и забудьте.

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

 

По шагам:

1. Соберите воедино все, что знаете о продукте;
2. Разбейте функционал на крупные блоки;
3. Опишите в простых словах как тестировать каждый блок, например - web-часть тестировать под разными браузерами (без списка браузеров!);
4. Составьте порядок таких работ, но без дат. Оценку по длительности вы сейчас вряд ли сможете сделать;
5. Обсудите этот список с вашим руководством и коллегами. Они могут подсказать где стоит обратить большее внимание, что не так критично;
6. Отредактируйте список по замечаниям;
7. Расширьте список тестов, там где написанного ранее не хватает.

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

Ценные советы от Василия и Ольги, спасибо