Открыта регистрация на курс “Основы тестирования ПО. Старт Карьеры” / Минск, 20 сентября

Уже запущена регистрация на мой курс по тестированию, который начнется буквально через 3 недельки! Приглашаю желающих поучавствовать!

Это курс для начинающих тестировщиков или для тех, кто только желает освоить эту профессию. Для тех, кому нравится мир IT!
Стать тестировщиком будет намного проще, если вы склонны мыслить аналитически и любите покритиковать мир вокруг себя. А вот наличие опыта для начала занятий совсем не обязательно.
Благодаря этому курсу вы разберётесь с основами тестирования ПО – выучите терминологию, познакомитесь с ключевыми техниками и сможете попрактиковаться в задачах, которые выполняет на работе новичок тестировщик.

Подробная программа курса представлена ниже.
Его длительность составляет 48 академических часов.
Всего 16 занятий, каждое из которых по 3 академических часа.
Стоимость курса: 2 000 000 бел. руб
Начало занятий: 20 сентября 2014г.
Расписание: по субботам и воскресеньям с 16 00 до 18 30.

 

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

Continue reading

Как правильно выбрать severity для бага?

Severity (критичность) бага выставляется после анализа двух факторов:

  1. насколько та область (модуль) приложения, в которой найден баг, важна для пользователя или бизнеса компании-разработчика
  2. как проявляется проблема – креш, проблема интерфейса, нарушение логики работы и т.п.

Если баг относится к фичам “для бизнеса”, “для менеджмента” или “для продуктивной работы всей команды разработки”, то при выборе критичности бага стоит подумать о том, не теряет ли статус компания, не теряется ли рейтинг приложения, не уменьшатся ли доходы компании, какими будут потери команды (временные, материальные, психологические) в случае, если баг останется в приложении не исправленным.

  • Blocker – это баги, ведущие к бизнес потерям: риск непрохождения ревью в appstore; критически большое уменьшение количества скачиваний приложения; уменьшение доходов, понижение рейтинга приложения в appstore; расхождение реализованного и планов маркетологов (например, неверная иконка приложения). Примеры багов: нет попапа на ревью, не отображаются smart news (новостные и рекламные попапы), неверная иконка приложения и т.п.
  • Critical и Medium – нарушения в логике работы бизнес-фич. Например, smart news отображаются, но первый раз появляются на 3й вызов приложения, а не на 2й.  Разницу между критичностями уровня critical и medium необходимо определять интуитивно.
  • Minor и Trivial. То, что относится к удобству работы команды и к бизнес-фичам, но не мешает их работе никаким образом. Например, в коде приложения стоит неверная ссылка на файл smart news, или опечатка в названии папки с библиотеками, которая видна только через iFunbox и пользователю должна быть безразлична, или ключ для  локализации в string файле написан с грамматической ошибкой. Разницу между критичностями уровня minor и trivial необходимо определять интуитивно.

Если же баг относится к фичам “для пользователей”, то для выставления severity необходимо ответить на вопрос о том, сколько пользователей заметят проблему. “Заметят” – это ситуация, когда пользователь не просто открывает экран с какой-то неточностью, а видит её и для себя воспринимает как проблему.

Для выбора severity можно пользоваться таблицей ниже.

 

Баг в “пользовательской фиче”: сколько пользователей столкнутся с проблемой либо обратят на неё внимание?

bug severity

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

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

 

Cколько времени выполняется некая операция на iPhone 4 в зависимости от количества файлов?

Кол-во объектов Blocker Critical Medium
до 5 > 1 сек около 1 секунды 0,5-1 секунда
5 – 15 > 2 сек около 2 секунд 1-2 секунд
16 – 50 > 3 сек около 3 секунд 2-3 секунд
> 50 > 5 сек около 5 секунд 3-5 секунд

Декомпозиция в тестировании и при анализе приложения

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

Декомпозиция, как процесс расчленения, позволяет рассматривать любую исследуемую систему как сложную, состоящую из отдельных взаимосвязанных подсистем, которые, в свою очередь, также могут быть расчленены на части. Continue reading

Планирование и оценка трудозатрат на тестирование

С очень хорошим и сильным докладом на конференции SQA Days-15 выступила Александа Ковалева – “Планирование трудозатрат на тестирование”. Саша, как и на прошлых свои выступлениях,  была воодушевляюща, мила, открыта, профессиональна! Восторгаюсь ей. Всё очень по делу.

Как и ранее, я транслирую конспект доклада, совмещенный с моим пониманием этой темы и моими дополнениям.

Планирование тестирования – это целый комплекс работ, состоит из следующих этапов:

  1. Определение требований к тестам
  2. Оценка продуктовых и проектных рисков
  3. Разработка плана тестирования:
    1. Разработка стратегии тестирования
    2. Определение ресурсов
    3. Проработка конкретных задач по тестированию
  4. Оценка трудозатрат на каждую из работ
  5. Создание графика работ с распределением ресурсов
  6. Мониторинг и сравнение результатов работы и на соответствие плану и графику. Перепланирование по необходимости.

Continue reading

SQA Days 15. Обзор докладов про тестировщиков-автоматизаторов

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

  • Про обучение автоматизации людей, совершенно незнакомых с программированием, – Вадим Зубович “SikuliScript как идеальный инструмент для обучения автоматизации”
  • Про то, каким автоматизатором не нужно быть, – Игорь Мирошниченко ” Антипаттерны поведения и развития тестировщиков – автоматизаторов”.

Continue reading

Исследование багов: учимся у Шерлока Холмса!

В сегодняшнем обзоре я затрону только один доклад – доклад Инны Смирновой на тему «Исследование багов: учимся у Шерлока Холмса!»
Инна подняла отличную и наболевшую тему для многих тестировщиков и их руководителей. У меня давно уже крутилась в мыслях похожая идея. Всё думала как к ней подступиться, а тут прелестный доклад Инны.

Continue reading

SQA Days 15. Обзор докладов из секции функционального тестирования

Во втором обзоре докладов SQA Days-15 рассмотрены следующие:

  •  Дмитрий Химион “Тестирование игровой механики в компьютерных играх”
  •  Наталья Голодюк “Quality Assurance в условиях тотального A/B тестирования”
  •  Сергей Остапенков «Обеспечение качества: практические советы»

Continue reading