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

[Sergios83]

Здравствуйте, я начинающий тестировщик, в компании я 1 тестер спросить о помощи не у кого (людей которые имеют опыт практики тестировщиком в компании)! Тестируя я пишу тест-кейсы и планирую писать ежедневныйе отчеты о тестировании что протестировано результаты тестирования и т.д., т.е. есть тест-кейсы по которым я провожу тестирование и отчеты о провдеденном тестировании для руководителя компании в которой я работаю.

 

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

 

Буду ждать советов от опытных практикующих квалифицированных тестировщиков, т.к. спросить совета о тестировании в своей компании не у кого (остальбные сотрудники программисты)!!

 

Заранее спасибо! С уважением, Сергей.

[Molechka]

А с какой целью Вы пишите ежедневные отчеты руководителю? 

Он требует или Вам это кажется правильным?

 

Что он с ними делает? Изучает? Указывает Вам на то, что Вы пропускаете проверки?

Если нет, то зачем тратить время на бюрократию?

 

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

Читайте книги, статьи, блоги, смотрите видео, проходите курсы... Вариантов много! Тут главное — не просто прочитать книжку и покивать головой "да, да, это все правильно", а пойти и сразу начать применять. "Тааааак, поиск граничных значений. Что у нас тут сегодня? Ага, формочка А менялась. Посмотрим, какие тут есть границы!".

 

Проводите анализ пропущенных ошибок методом "5 почему?" - задайте себе этот вопрос 5 раз "почему я пропустил ошибку? А почему *ответ на прошлый вопрос*" и докопайтесь до первопричины. Возможно, тестируя ввод числовых данных, Вы не стали заморачиваться вводом отрицательных значений и у Вас покупатели в магазине смогли купить "минус 3 товара" и требовать с магазина оплаты. Ага, делаем себе пометочку, не забывать о таких значениях. Потихоньку собственные знания, собственные чек-листы будут расширяться, но это бесконечный процесс :)

[Sergios83]

А с какой целью Вы пишите ежедневные отчеты руководителю? 

Он требует или Вам это кажется правильным?

 

Что он с ними делает? Изучает? Указывает Вам на то, что Вы пропускаете проверки?

Если нет, то зачем тратить время на бюрократию?

 

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

Читайте книги, статьи, блоги, смотрите видео, проходите курсы... Вариантов много! Тут главное — не просто прочитать книжку и покивать головой "да, да, это все правильно", а пойти и сразу начать применять. "Тааааак, поиск граничных значений. Что у нас тут сегодня? Ага, формочка А менялась. Посмотрим, какие тут есть границы!".

 

Проводите анализ пропущенных ошибок методом "5 почему?" - задайте себе этот вопрос 5 раз "почему я пропустил ошибку? А почему *ответ на прошлый вопрос*" и докопайтесь до первопричины. Возможно, тестируя ввод числовых данных, Вы не стали заморачиваться вводом отрицательных значений и у Вас покупатели в магазине смогли купить "минус 3 товара" и требовать с магазина оплаты. Ага, делаем себе пометочку, не забывать о таких значениях. Потихоньку собственные знания, собственные чек-листы будут расширяться, но это бесконечный процесс :)

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

[Molechka]

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

 

Давайте начнем с того, зачем это надо.

 

Руководство говорит "мало багов" — почему?

• До вас на проекте был другой тестировщик и находил больше багов?
• Вы пропускаете ошибки. на которые потом напарывается начальство / Заказчик?
• Вы создаете отчет о 2 ошибках в день и начальство думает, что это работа на полчаса, а остальное время вы пинаете балду?

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

[Sergios83]

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

 

Давайте начнем с того, зачем это надо.

 

Руководство говорит "мало багов" — почему?

• До вас на проекте был другой тестировщик и находил больше багов?
• Вы пропускаете ошибки. на которые потом напарывается начальство / Заказчик?
• Вы создаете отчет о 2 ошибках в день и начальство думает, что это работа на полчаса, а остальное время вы пинаете балду?

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

Пропускаю ошибки. на которые потом напарывается начальство / Заказчик - этот пункт наверное причина

[clipsa]

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

По книжкам и интернетам или записаться на курсы.

[Molechka]

Да даже если без курсов.

 

Вам же показывают ошибки, которые вы пропустили? Анализируйте их.

Почему вы сами не нашли? У вас такой тест-кейс есть в ваших записях? Если нет, то почему? 

 

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

 

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

"АГА!", должны подумать вы, "я вообще про кнопку "назад" в браузере не думал. Таааааак, где еще можно поотменять действия? Можно ли нажать назад, только только откры страницу? А вот из этого меню? А с формы, где я какие-то данные ввел? А..." и так далее. Нашли новый класс эквивалентности, посмотрите, где еще вы могли его пропустить

[Sergios83]

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

[FestiveGrape]

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

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

В первую очередь функционал должен работать без всяких там негативных тестов, ведь если, например, калькулятор должен умножать, то не нужно бросаться и проверять что станет, если туда вбить отрицательные или какие-нибудь бесконечные значения чисел. Просто проверьте, что калькулятор вообще умножает цифры, двух-трех-четырех-пятизначные числа и убедитесь, что всё работает как надо. Ведь если вы проверите умножение двух-трехзначных чисел и умножение отрицательных, а калькулятор сломается на умножении четырехзначного числа, то это полный фэйл. 90% пользователей будет умножать одно и тоже, и только 10% пользователей будут извращаться и умножать -9999 на 0.

 

В общем, так как вы один и не сможете объять необъятное, проверяйте общий workflow, чтобы всё работало для обычного юзера, а все остальные ситуации, которые случаются в 1% случаев, оставляйте на потом.

[Sergios83]

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

[SALar]

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

[Sergios83]

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

[alexa22]

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

[krukovskiy]

Периодичность отчетности говорит об уровне доверия руководства, чем чаще - тем меньше доверия.

 

 "Пропускаю ошибки. на которые потом напарывается начальство / Заказчик - этот пункт наверное причина"

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

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

 

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

[Sergios83]

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

[Tishka]

Предложил бы сделать так:

1. Заняться исследовательским тестированием проекта

2. По полученным знаниям о проекте, сгруппировать функционал(может это разделы типа "Профиль", "Галерея" ну и т.д)

3. Далее изучаете функционал по группам (предложил бы начать с самых простых, чтоб руку набить)

4. Пишите тест кейсы по очереди для каждой группы, тут поможет пункт 1. Если тестировать сразу несколько групп то получается хаос.

 

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

[Sergios83]

Предложил бы сделать так:

1. Заняться исследовательским тестированием проекта

2. По полученным знаниям о проекте, сгруппировать функционал(может это разделы типа "Профиль", "Галерея" ну и т.д)

3. Далее изучаете функционал по группам (предложил бы начать с самых простых, чтоб руку набить)

4. Пишите тест кейсы по очереди для каждой группы, тут поможет пункт 1. Если тестировать сразу несколько групп то получается хаос.

 

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

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

[Tishka]

По поводу ежедневных отчетов:

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

- Отчеты должны быть краткими. Я со своим начальством договорился вкладывать отчет в 3-4 предложения.

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

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

 

Если им нужны будут детали, то просто попросят обсудить это в переговорной.

[irko]

У Вас есть ТЗ? Советую детально пройтись по всем пунктам технического задания с применением всевозможных техник тест-дизайна. Во-первых, таким образом, изучите все имеющиеся функциональности Системы, во-вторых, сможете в то же время провести тестирование всей Системы. Чем более разнообразные и приближенные к жизни пользователей сценарии и тест-кейсы будут, тем больше вероятность найти баги и проблемы. В первую очередь советовала бы проверять позитивные и наиболее критичные сценарии, далее - негативные и менее критичные. И не забывать делать регрессию перед релизом.

[EugeneL]

А я бы предложил следующее

 

Проблема №1. "Плохое знание приложения".

Способы решения:

№1. Попробуйте потестировать приложение с применением существуюших наборов тест-кейсов. В процессе тестирования, отметьте для себя:

- что, по Вашему мнению, осталось за бортом

- какие тесты к какой области приложения относятся

№2. Если тестов нет, попробуйте почитать документацию (руководство пользователя, Proof of Concept и т.д.). В процессе чтения

- выделите наиболее понятные Вам функции

- набросайте чек-лист для проверок таких функций

- напишите тест-кейсы для случаев из чек-листа

- определите, к каким областям прилодения относятся Ваши тесты

- какие области приложения или функции надо покрыть.

 

Проблема №2. "Пропущенные тараканы на стороне клиента"

Способ решения.

- Как только Вам стало известно о новом дефекте, определите его приоритет (я не хочу вступать в казуистику по поводу приоритета и важности, просто, выясните, насколько дефект критичен для Заказчика)

- Если этот дефект влияет на важный (с точки зрения Вашего Заказчика) функционал, занесите его в тест-кейсы для смоук-теста и теста критического пути

- Если Ваш смоук-тест проходит без ошибок, попробуйте поэкспериментировать с начальными условиями и тестовыми данными (да, это не Happy Path, но Заказчик тоже любит ломать приложение -- лучше сделать это раньше его)

- Добейтесь того, чтобы у вас был понятный и недвусмысленный Definition Of Done для каждой фичи

- Нововведенные фичи тестируйте с двойной внимательностью. Если Вы из описания, не понимете (или можете толковать функционал двояко), обратитесь к бизнес-аналитику, project owner-у, Заказчику). Лучше получить от них письмо с пояснением, чем пропустить дефект на продуктив