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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

 

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

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

 

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

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

 

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

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

извиняюсь за дубликаты! спасибо за ссылку!

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

Заранее спасибо.

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

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

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

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