lurk

Ты курсы проходил, наверное, на тему "Как стать большим умником!"? 

Сценка. Недалекое будущее. Вы и ваш QA Lead. 

Вы: Я тут провел тестирование проекта 1 - все работает. Проверяйте.

QA Lead: Хм, проект не стартует. От слова вообще.

Вы: Да ты я гляжу курсы проходил "Как стать большим начальником".

Раз такое дело, то покритикуйте и мое )))
drive.google.com/...YeGVoLTQ/view?usp=sharing

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

По-моему, работы должно быть всегда столько, что бы сотрудник не успевал все сделать за день, но и мучался тем, что ее слишком много. Тогда самоорганизация его не позволяла бы ему пинать балду свыше какой-то нормы.
Если работы нет столько, то нужно контролировать его временные затраты кем-то стороны, вплоть до почасового контроля (например ежедненвые/еженедельные таймшиты с часовой разбивкой). Ибо его самоорганизация начала бы уделять работе не более 4-6 часов в день и качество его работы, как следствие, начало бы падать.

 

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

Если работы слишком много - то человек становится узким местом проекта. Любое узкое место надо находить и устранять.

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

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

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

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

PS: Прочитайте "Цель" Голдратта для начала.

Zo0, у вас есть возможность уточнить у вашего тренера ПОЧЕМУ он вам сделал данное замечание, с вашими АРГУМЕНТАМИ почему это замечание не соответствует данной ситуации.

Вы МОЖЕТЕ выслушать его объяснение - и СДЕЛАТЬ ВЫВОДЫ или не делать.

Можете также продолжить ДИАЛОГ, используя НОВУЮ ИНФОРМАЦИЮ. 

Это конструктивно.

Обвинять человека тем более не разобравшись до конца в ситуации - неправильно. Зато удобно.

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

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

Ссылка на карту (XMind)

В майнд-карте даны ссылки на перечисленные ниже документы. 

Ссылки на ГОСТы брались с просторов Рунета - используйте их на свой страх и риск. 

Содержание карты:

1. Профессиональные стандарты в области ИТ

1.1 Специалист по тестированию в области информационных технологий

2. ISTQB

2.1 Глоссарий терминов тестирования ISTQB 2.3

2.2 Программа обучения ISTQB Базового уровня 2011

3. ГОСТы

3.1 Серия 19 (ссылки в майнд-карте отсутствуют)

3.2 Серия 34 (ссылки в майнд-карте отсутствуют)

3.3 ГОСТ ИСО 9000-2011 Системы менеджмента качества. Основные положения

3.4 ГОСТ ИСО 9001-2011 Системы менеджмента качества. Требования

3.5 ГОСТ Р ИСО/МЭК 9126-1993 Информационная технология. Оценка программной продукции

3.6 ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

3.7 ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование

3.8 ГОСТ Р ИСО/МЭК 15288-2005 Системная Инженерия. Процессы жизненного цикла систем

3.9 ГОСТ 28806-90 Качество программных средств. Термины и определения

3.10 ГОСТ 28195-89 Оценка качества программных средств. Общие положения

3.11 ГОСТ Р ИСО 31000-2010 Менеджмент риска. Принципы и руководство

4. Основы Программной Инженерии (по SWEBOK)

4.1 Тестирование программного обеспечения 

4.2 Качество программного обеспечения 

В общем случае:

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

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

Неплохо сделать критерии приёмки программы в тестирование (если в приёмке есть ошибки - тестирование не начинается) и критерий остановки тестирования (после нахождения, например, 30 ошибок среднего и выше приоритета Тестирование останавливается и не продолжается до тех пор пока количество ошибок среднего и выше приоритета не сократиться хотя бы до десяти) 

Как мне сказали - 4-5 дней, этого пока хватает. Но как выявить наиболее критичные баги, если всякая мелочь сыплется в глаза постоянно... 

По поводу цветов - возьму на заметку. 

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

Основной функционал проверять: добавление, удаление записей, постройка графиков, отчеты, проверка интерфейса.

Строите сценарии использования системы реальным пользователем(я) с разными ролями, уровнем доступом - его (их) и прогоняете.

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

Имхо: критерием завершения тестирования удобно сделать время тестирования (Это тестовое задание и тратить на него более n времени не рационально).

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

Предположение: Для качественной проверки спички требуется коробок.

Без него большинство ваших тестов не будут иметь практический смысл:

Часть 1. 

1. удобство: удобно ли держать спичку и зажигать

Сказка: Тестировщик сказал, что спичку в руках держать очень удобно и она хорошо зажигается. Но заказчик спичку не принял. Ведь спички планируется делать для безруких людей. 

Мораль: Не проверяй удобства пока не знаешь для кого это делается и с чем им придется столкнуться.

2. проверить есть ли сера на кончике

Сказка: Тестировщик проверил и сказал, что серы на конце нет. Правда для данных спичек используется другое вещество для возгорания - не сера. Но кого это волнует?

Мораль: Уточняй требования.

3. спичка отшлифована? или на ней есть шероховатости, заусеницы

4. представим, что у нас на улице -60=) попробуем заморозить спичку и попробовать зажечь

Сказка: Мы спички для Африки делаем, она при +40 на улице самовозгорается. Только это мы не проверили.

Мораль: Уточняй условия эксплуатации.

5. намочим-попытаемся поджечь

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

Мораль: Не всегда нужна проводить тестирование за границами рамок эксплуатации.

6. намочим -высушим в микроволновке- зажигаем

Сказка: ПМ увидел счет о покупке микроволновки. Спросил зачем? На что ему ответили для тестов. Он посмотрел на тестеровщика, как на дебила. И отменил покупку микроволновки. Так что тест сделать не удалось. 

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

7. цвет спички: крашенная, или нет

Сказка: В этот раз спички делали для слепых. И опять тест мимо.

Мораль: Знай своих пользователей.

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

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

PS: И кто сам этот софт будет тестировать? 

Например можешь так:

0. Открыть TestLink Факабы (Логин: admin Пароль: admin)

1. Нажать Test Project Management

2. Нажать кнопку Create

3. Заполнить Name * и Prefix (used for Test case ID) *

4. Нажать Create - Проект создан.

Или тебе что-то другое нужно?

При поиске работы тестировщика сталкивалась с очень разными тестовыми заданиями. Каждая компания проводит отбор на свой лад. Вот например столкнулась с таким вопросом:

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

Какие есть варианты? Как бы вы ответили на этот вопрос?

Используйте для ответа информацию с официального сайта:

Использование шаблона в качестве основы

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

Источник: Новые возможности Word 2013

Выбор шаблона

Как правило, документы удобнее создавать на основе шаблона, а не пустой страницы. Шаблоны Word содержат темы и стили и готовы к использованию. Остается только добавить в них содержимое.

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

Источник: Основные задачи в Word 2013

 

Сравните задачу _Roman_ с задачей отсюда

Да, формулировка похожа, но есть один важный момент. В формулировке Романа указано рассмотреть все возможные сценарии рассчёта. При помощи pairwise мы сократили количество сценариев.

А как хорошо замечено в статье по вашей ссылке,

 

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

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

 

Если бы я отвечал на данный вопрос, я бы привёл два решения - полное и pairwise-ное, и привёл бы плюсы и минусы обоих вариантов.

 

При формулировки все возможные сценарии, нужно рассматривать и такие ситуации тогда: если возраст не указан - то какой сценарий? если не указан пол? или количество детей? А если возраст отрицателен? А при возрасте сотрудника 24, 25, 45, 46 - правильно ли отрабатывает наш тест? Если сотруднику исполнилось 25 в день расчета премии (например, 1 февраля) - а премия за январь - то как мы должны обрабатывать данный случай...

PS: а так согласен с вашей фразой: я бы привёл два решения - полное и pairwise-ное, и привёл бы плюсы и минусы обоих вариантов.

Подтверждаю, при описании шагов тест кейса в TestLink 1.9  можно сделать гиперссылку на другой уже существующий тесткейс.

как вариант: