Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Начинающему тестировщику
Как объяснить людям, далеким от IT, кто такой тестировщик
18.03.2016 11:30

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2016/02/how-i-explain-software-testing-to.html

Перевод: Ольга Алифанова

Случалось ли, что вы бесились, пользуясь компьютером?

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

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

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

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

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

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

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

 
Как тестируется продукт в реальном мире?
11.03.2016 10:34

Автор: Акшай Ананд (Akshay Anand).

Оригинал статьи: https://blog.dotsandarcs.com/how-is-a-product-tested-in-the-real-world-16cc59935120#.m52yj1yzs

Перевод: Ольга Алифанова

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

Когда я учился, мне рассказывали о множестве видов тестирования. Я узнал о куче концепций - белый ящик, черный ящик, интеграционное тестирование, проверка исправности, тестирование ядра, компонентов, и так далее. Мы активно пользовались этими определениями, нанимаясь на работу. Если эти строки читают выпускники ВУЗов - готовьтесь, сенсационное сообщение! Реальный мир очень отличается от книг!

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

Хм-хм. А что проверять-то в первый день? Еще ничего не сделано, нет никакой функциональности, так что же нам тестировать?

Подробнее...
 
Предвзятость в тестировании
19.08.2015 10:50

Оригинальная публикация: http://testsheepnz.blogspot.ru/2015/07/confirmation-bias-in-testing.html

Автор: блогер и тестировщик TestSheep

Перевод: Ольга Алифанова для Software-testing.RU

Концепцию предвзятости я понимал смутно, пока не прошел курс Джеймса Баха "RST". Смысл понятия в том, что зачастую мы видим то, что наш мозг, наша психика хотят видеть, а не то, что существует на самом деле.

В целом, такая профессия, как тестировщик, существует именно благодаря предвзятому отношению.

Представим разработчика, создающего страницу регистрации для нового приложения.  Он регистрирует нового пользователя, вводя свое имя, почту, дату рождения, и получает сообщение "Добро пожаловать, Стюарт Кук!"."Все работает", заключает разработчик, и переходит к следующей интригующей задаче.

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

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

Ввести данные и получить сообщение "Привет, Стюарт" - неплохой старт.  Но до финиша еще далеко.

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

А если мы зарегистрируемся как Вася - мы тоже получим сообщение "Привет, Стюарт"? Мелочь, а неприятно.
Что, если поля регистрации будут принимать значения любой длины? А если мы введем туда полную ерунду - удастся ли создать учетку?

Подробнее...
 
Про Severity - серьезно и несерьезно
19.06.2015 10:15

Автор: Ольга Алифанова

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

  • Критическая – системный сбой, потеря данных, проблемы с безопасностью.

  • Значительная – зависание, блокирование использования, кодирования, тестирования

  • Умеренная – функциональные проблемы

  • Низкая – косметические проблемы

Подробнее...
 
Какой результат писать в чек-листе
25.03.2015 21:31

Автор: Киселева Ольга

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

Верный гугл говорит — “О, зацени, как все просто!”:

  • Значение поля принимается.

  • Сообщение о некорректных данных.

Давайте попробуем применить на практике! Напишем чек-лист для регистрации на сайте https://dadata.ru/.

Подробнее...
 
Как заводить задачи в баг-трекер
19.02.2015 19:01

Автор: Ольга Киселева, тренер курса Онлайн-интенсив для начинающих тестировщиков

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

1. Выберите тип

Разработчики не боги, они не могут делать все и сразу. Им нужно понимать, с чего начинать. Они сортируют задачи по типу — сначала новые функции, потом ошибки, потом все остальное.

Какие бывают типы задач:

  • Баг — ошибка в программе.
  • Улучшение — все ок, но хотим с перламутровыми пуговицами.
  • Новая разработка — такой возможности нет, а очень хочется.

Допустим, заказчик захотел новую возможность, а вы завели ее не как новую возможность, а как баг. Разработчики весь месяц делали другие новые функции, и до вашей не добрались. Заказчик в ярости: вы же обещали... А виноват постановщик задачи — умей выбирать тип!

Подробнее...
 
Как искать баги — метод туров Виттакера
05.02.2015 11:47

Наш тренер Ольга Киселева подготовила статью в помощь студентам своего онлайн-интенсива для начинающих тестировщиков, описав методику систематического поиска багов по Джеймсу Виттакеру (James A. Whittaker)

Методика туров

Приложение — незнакомый город.

Тестировщик — турист.

Исследуйте ПО так, словно это — незнакомый город

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

Подробнее...
 
Баг не воспроизводится… Что делать?!
17.10.2014 14:01

Доклад Алексея Баранцева с конференции Fun ConfeT&QA.

Вы нашли баг — но не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводился — но на следующий день больше не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводится — но только на вашей машине, а на других всё работает нормально.
Вы нашли баг, он успешно воспроизводится — но только не на машине разработчика и он не может пофиксить его.
Вы нашли баг, он успешно воспроизводился, и вот сам собой исчез, хотя разработчики говорят, что ничего не исправляли.
Знакомо? Наверняка.
Что делать в таких ситуациях?
Писать в баг-трекер или не писать?
А был ли баг вообще? Поверят ли вам?
Сколько времени потратить на попытки воспроизвести хитрый баг?
Я расскажу вам свои правила и маленькие хитрости, как действовать в этих случаях.

Подробнее...
 
Что такое тест-кейс и как его писать
25.08.2014 15:45

Автор: Киселева Ольга, автор и ведущий тренинга Онлайн-интенсив для начинающих тестировщиков.

Тест-кейс — это проверка. "Выполни тест-кейс по вводу отрицательных значений" = проведи проверку такую-то и проверь, что результат будет такой-то.
Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.

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

Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план —  это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)

Стандартные атрибуты тест-кейса

  1. Номер —  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
  2. Название — краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
  3. Предварительные шаги —  описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
  4. Шаги — описание действий, необходимых для проверки (например, создание элемента).
  5. Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан").
Подробнее...
 
Взгляд на проблемы со стороны джуниора
16.06.2014 13:59

Запись доклада Андрея Кузьмичева на онлайн-конференции Fun ConfeT&QA, весна 2012.

От некоторых своих коллег я слышал, что success stories это скучно и не интересно. Я расскажу про fail`ы в то время как я был джуниором именно глазами джуниора.

Иногда я себе, а иногда мне друзья/коллеги задавали, например следущие вопросы:

  • Почему я должен работать когда остальные балду пинают? / А почему они вообще балду пинают?
  • Почему я должен ехать на конференцию за свой счет?
  • Что надо чтобы начать постить баги? / Что надо чтобы ваши джуниоры начали постить баг.
  • В какую сторону развиваться? / В какую сторону развивать
  • Сколько я стою? / Как не потерять талантливого джуниора
  • Чего я ещё не знаю?

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

Подробнее...
 



Страница 7 из 9