среда, 8 мая 2019 г.

IDEA. Как посмотреть локальные изменения

Допустим, мы решили выкачать folks и поиграться с ним. Потом что-то изменили и все сломалось. А что изменяли, уже забыли. Или это кот по клавиатуре прошелся. Или ребенок с ноутбуком поиграл. Как посмотреть, «что я тут наменял» в IDEA?

1. View — Tool Windows — Version Control


Снизу появится окно версионного контроля на вкладке локальных изменений (Local Changes).


Тут отображаются все измененные локально файлы. То есть все отличия от того, что вы выкачали командой «hg clone».


вторник, 7 мая 2019 г.

Сколько задач заводить в баг-трекер

Вот вы обнаружили две орфографических ошибки — это два бага или один? А если кнопка «назад» как-то странно работает, но только в двух местах? А если вы грузили файл и схлопотали несколько ошибок?

Сколько ставить задач? Есть несколько принципов


1. Одна проблема = один баг


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


Подробнее про принцип см в этой статье (плюсы, минусы, где это применяется у нас).

четверг, 25 апреля 2019 г.

Form Filler — плагин тестировщика для автозаполнения полей


Ссылка на плагин (аддон) — Chrome, Mozilla

Ну очень удобный плагинчик для автозаполнения формочек ввода! Нажал на кнопочку — и готово. Огромный плюс перед web developer toolbar — то, что значения каждый раз разные. Не нужно дополнительных телодвижений, если на поле ограничение уникальности.

Плюшки плагина:
  • Заполняет текстовые поля.
  • Поддерживает свойство maxlength .
  • Рандомно заполняет дропдауны, чек-боксы и радио-баттоны.
  • Игнорирует CAPTCHA, спрятанные, отключенные или readonly поля.
  • Поддерживает автозаполнение полей, проверяемых по регуляркам (круто!)
Потестировать можно на системе Users.

вторник, 23 апреля 2019 г.

Генераторы тестовых файлов с нужным весом

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


Online random file generator




https://pinetools.com/random-file-generator

Выбрали количество файлов, их вес, нажали снизу на кнопочку «Generate» — вуаля!
Генератор может создать даже большие файлы (2гб, 100 гб).

Группируем схожие проблемы в одной задаче

Один из подходов к описанию багов: Одна проблема = один баг. Даже если баги похожи, всегда ставим разные. Другой подход — принцип группировки похожих задач.

Плюсы подхода:
  • Все в одном месте — не надо бегать по десяти разным задачам
  • Отлично подходит для сбора небольших улучшалок или первого тестирования нового функционала

Минусы:
  • Надо внимательно отслеживать, что уже исправлено, а что еще нет
  • После исправления всего провести повторное тестирование всех пунктов (регрессия)
  • Название задачи слишком общее, сложно будет потом найти конкретную проблему

Мы применяем такой подход как раз в случае хочушек или первичного тестирования GUI.


пятница, 19 апреля 2019 г.

Мнемоники от Даши: КОМПАС, СТуПОР, ВОЛК и СПОРТ

На моем курсе «Школа для начинающих тестировщиков» есть творческое задание — придумать свою мнемонику по тестированию! Разумеется, оно необязательное ツ

Смотрите, что придумали ребята!

Даша 1: КОМПАС


Как только выбран тур,
Освоить его цели.
Момент засечь,
Пройти по туру смело.
А если надо - это повторить!
Словить все баги и про тур забыть))


вторник, 16 апреля 2019 г.

Лезем в java-код для локализации бага (видео и ДЗ)

Одна из тем моего курса по локализации багов — проверка по коду. Если разработчики заботятся о чистоте кода, то тестировщик с минимальными навыками ЯП может туда залезть, прочитать и даже внести исправления!

Я рассказываю на примере приложения folks, как можно "прочитать" объект, подсмотреть в схему создания БД и сделать какие-то выводы из этого. Сразу предупреждаю — программированию не учу! =)


Домашнее задание на просмотр кода на курсе необязательное — только для тех, кому это интересно. Но ребятам понравилось! Причем тем ребятам, которые впервые видят фолкс:

понедельник, 15 апреля 2019 г.

Mindmap для сайта IKEA

Когда мы рисуем mindmap, то:
  1. начинаем с основных сценариев (зачем пользователю наш продукт, что он там делает?), 
  2. потом детализируем их (как он это делает, какие есть способы это делать?)
  3. дополняем карту второстепенными сценариями.
Вот, например, ребята из школы для начинающих тестировщиков нарисовали интересную карту для сайта IKEA. Отличная работа, на мой взгляд!


PS — сохранила карту в работах студентов, теперь не потеряется!

PPS — также добавила ее в свою книгу в качестве примера


четверг, 11 апреля 2019 г.

TCP/IP: что это и зачем это тестировщику



Отличное видео от компьютерной школы Hillel. Эдуард Изотов на доступном языке объясняет:

  • как работает сеть;
  • что такое IP;
  • чем плохо, когда провайдер дает вам IP в 10 подсети;
  • что такое dhcp, dns, vpn и как это все работает;
  • чем TCP отличается от UDP;
  • чем OSI отличается от TCP/IP;
  • ...
Рекомендую! Smile :) 


PS — добавила на Testbase в навык тестирования web-приложений, теперь не потеряется!

четверг, 4 апреля 2019 г.

Скриншотер от Mail.ru


Ссылка — https://screenshot.mail.ru/

Это великолепно, я считаю! Маст хев для тестировщиков и аналитиков Smile :)
Скриншотер бесплатный. Он позволяет захватить нужную область экрана и наглядно показать свои мысли:
  • Поставить стрелочку.
  • Натыкать циферок «1», «2», «3» — так проще ссылаться в описании бага на проблемные зоны.
  • Ну и самый кайф — готовые стикеры типа «это левее, а это правее, а вот тут поехало». И даже котики в стикерах есть!
  • ...
А после того, как вы создали скриншот, можно одной кнопочкой создать на него ссылку. Удобно сразу скинуть разработчику!

На работе у нас есть главный тестировщик веба. Когда делаем новый функционал, у нее часто возникают претензии как раз в стиле «левее, правее». Все остальные обычно натыкаются на «вот тут поехало». Теперь оформлять такие баги будет удобнее!

Так что очень рекомендую. Простой, наглядный, бесплатный :)

PS — добавила его на Testbase в навык выбора инструментов. Теперь не потеряется!


пятница, 22 марта 2019 г.

Нестандартные мнемоники: колыбельная и расшифровка исследовательских туров

На моем курсе «Школа для начинающих тестировщиков» есть творческое задание — придумать свою мнемонику по тестированию! Разумеется, оно необязательное ツ

Смотрите, что придумали ребята!

Анна, колыбельная


На кратенькую мнемонику это не похоже, но Остапа понесло ))

Колыбельная (известная всем с детства, записанная на подкорке) – подходит для тестирования мобильных приложений. Чтобы не забыть что-нибудь важное.

Баю-баюшки-баю
Спящий режим. Выход из него. Реакция приложения.
Не ложись ты на краю
Проверяем горизонтальную и вертикальную ориентацию, а так же переход из других приложений из горизонтальной в вертикальную и наоборот. Сюда же можно UI.
Придёт серенький волчок
Валятся смски, пуши и прочее
И ухватит за бочок
Жрём память всеми способами
Он потащит во лесок
Авиарежим, wi-fi, 3G/LTE
Под ракитовый кусток
Геолокация
Там птички поют
Входящие звонки, звонки по скайпу и месенджерам, параллельно включенная музыка фоном в другом приложении
Детям спать не дают
Не даём девайсу выключаться максимально продолжительное время



четверг, 21 марта 2019 г.

Как отправить массив через Soap Ui

Рассмотренные в статье примеры вы можете опробовать и сами, так как запросы мы будем отправлять в бесплатное приложение Users.


Простой массив


Возьмем метод CreateCompany. У нас есть пример вызова в ТЗ для REST-запроса. Но мы знаем, что аналогичный запрос есть и в SOAP. А как его отправить, если бы примера в доке не было?

В SOAP хорошо то, что у нас всегда есть WSDL схема, по которой Soap Ui сам генерит заглушку запроса, остается только заполнить ее. Но это работает с простыми полями, а как нам заполнить этот массив?

Заглушка запроса — как заполнить массив?

Как назвать элементы внутри массива? Мы можем это проверить, вызвав метод getCompany! Проверим компанию, в которой есть сотрудники, посмотрим в ответе, как выглядит массив:

понедельник, 18 марта 2019 г.

А не поздно ли мне становиться тестировщиком?

Периодически сталкиваюсь с таким вопросом:
  • Мне 35, не поздно ли менять кардинально профессию и идти тестировать?
  • Мне 30, только вышла из декрета, не поздно ли мне?
Такие вопросы задают на форумах, мне в личку, в чатиках... Вроде и хочется попробовать, но всегда есть сдерживающий фактор:
  • а у меня образование гуманитарное;
  • не работала уже 3 года;
  • возраст же!
  • ...
Так поздно или нет? Стоит бросать все и уходить в тестирование? Смогу ли я, с таким то образованием?



Сможете! Если захотите Wink ;)

Да, тестирование — эта та отрасль, куда достаточно легко войти. От джуниора требуется голова на плечах, умение гуглить, да быстрая обучаемость. Разумеется, если он уже чему-то научился на курсах или самостоятельно, это будет плюсом в карму. Но устроиться на первую работу можно и без особых навыков.

Низкий порог входа не означает, что тестирование — это легко, просто сиди и тыкай в кнопочки. Тут можно постоянно развиваться! Но для Junior позиции нужна в основном голова на плечах. Сами искали джуниора недавно, знаю, о чем говорю.

Секрет успеха прост:

вторник, 12 марта 2019 г.

Панбагон. В мобильной версии дата ожидания товара — месяц назад

Присматриваю ребенку комбинезончик на весну, листаю вайлдберриз на телефоне. Попался симпатичный, да размера нет. Добавила в лист ожидания. Смотрю — а там даты планируемой поставки есть. О, интересненько, когда же он появится?

Мобилка

Все бы хорошо, только сейчас 12.03... Так что поставка ожидается «месяц назад» ¯\_(ツ)_/¯
Типичная ошибка документации:

  • или последняя поставка была 18.02, просто не убрали плашку
  • или поставка ожидается в 03 или 04 месяце, опечатались
По крайней мере, так я думала, пока не села писать этот пост и не открыла веб-версию, чтобы скопировать ссылку для оформления бага.

Рисуем алгоритм сложной процедуры из ТЗ

На одном из проектов сделали довольно хитрую схему импорта данных из буферной таблицы. Для пользователя написан вариант использования и там все просто:
  1. Исходная система выгрузила данные в буферные таблицы
  2. В таблице increment добавила номер выгруженного инкремента — это будет флаг для нашей системы начинать забор данных.

См также:
Как составлять вариант использования

А на нашей стороне надо проверить таблицу инкрементов, попробовать выбрать этот инкремент, проверить, создавать новые карточки или обновлять старые, и другие подробности. Если смотреть через админку, триггер запускал три задачи:
  1. Подготовка данных
  2. Загрузка
  3. Очистка буфера
Каждая задача выполняет внутри кода выполняет несколько действий. А мне надо подготовить набор автотестов на каждый этап. Значит, надо разобраться, что там происходит. Я сначала долго тупила над «пользовательской» докой, пытаясь понять, как оно устроено внутри, а потом пошла к разработчику и попросила объяснить «для блондинок».

Это было продуктивное общение! Пока он объяснял, я рисовала на бумажке схему и задавала по ней вопросы. После нескольких вопросов раработчик признал, что я молодец, он про «вот это и то» не думал. Не зря рисовала!! Без рисунка я бы просто не удержала все в голове и не обнаружила проблемные зоны.

По итогам обсуждения я создала в конфлюенсе раздел «Техническая сторона сценариев, алгоритмы» и переписала туда все со своего листочка, полученный алгоритм и рисунок (в visio накидала):
  1. null => 1. Выбираем все записи из таблицы INCREMENTS, где import_status is null и устанавливаем им значение import_status = 1.
  2. Удаляем неактуальные записи из буферных таблиц (физ лица и телефонов).
  3. Грузим физиков по условию in (id_increment, для которого import_status in 1).
  4. Грузим телефоны по условию in (import_status in 1).
  5. Создаем связи телефон - физик или телефон - юрик (тип контрагента смотрим по staging).
  6. Удаляем физиков из буфера, если не было ошибок на этапе загрузки.
  7. Удаляем те телефоны, у которых есть связи (проверяем наличие record_id физика/юрика в staging).
  8. 1 => 2. Выбираем все записи из таблицы INCREMENTS, где import_status = 1 и устанавливаем им значение import_status = 2.


понедельник, 11 марта 2019 г.

Мои 12 недель в году. Часть 8


Первый опытвторойтретийчетвертыйпятыйшестойседьмой

Что это за техника


Вы собираетесь с друзьями в группу и ставите себе цели на 12 недель (3 месяца). Это могут быть как рабочие, так и личные задачи. Такие, которые вы вроде как хотите сделать, но вечно откладываете, так как «некогда, потом, щас, вот только мелочевку разгребу и тот пожарчик потушу».

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

Я комбинирую с магией утра.


Результаты кратко


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

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

Основной план был такой:

— книга: закончить главу 6, половина главы 7
— курсы: запустить курс про локализации, доработать по отзывам
— курсы: начать делать новый курс (соап или автоматизация)
— фолкс: закрыть пару задачек в джире.

И ведь все успела! Даже перевыполнила план по книге:
  • закончила главу 6;
  • сделала главу 7 (41 стр);
  • и почти закончила главу 8 (ха, тоже 41 стр на текущий момент)! 
Курс по локализации запустила, сохраняю сейчас лучшие работы как шаблоны. Доработка по отзывам будет потом, потому что курс еще не закончился первый.

Выбрала новый курс, все-таки решила сначала закончить с REST-ом, а потом уже делать SOAP. Так что мой новый курс будет «Автоматизация на уровне Postman». Делать его начала, уже 3 урока записала.

И даже пару задачек в фолкс закрыла! Правда, на последней неделе, чисто чтобы поставить плюсик у этих целей и не писать о том, что "некогда было" =))) Да и то оказалось, что по двум задачкам я уже все сделала, осталось только кнопочку «закрыть» нажать, добавив завершающий комментарий. И вуаля, план 12 недель готов!

Главные приоритеты у меня не менялись — ребенок, книга, курс. Книгой удается позаниматься почти каждый день, пусть хоть по 5 минут. И это здорово! Ну и по курсу я много всего сделала. А остальное уже "как успею". Причем последние пару недель это было "почти не успеваю".

четверг, 7 марта 2019 г.

Пример карты сценариев для визуализации ТЗ

Когда мы рисуем S&T (State & Transition Diagramm), то ограничиваем себя. Надо выбрать именно объект. Стрелочки — это именно переходы, а кружочки — состояния. Никаких зарисовок интерфейса или чего-то такого.

Это не всегда удобно. Потому что зарисовка ТЗ в графическом виде может не удовлетворять требованиям составления S&T, но поможет лучше разобраться, "что тут происходит". Так почему бы и нет?

Вот, например, работа одного из моих студентов — функционал взаимодействия с конкретной книгой:


Да, это не S&T, скорее карта сценариев. Ну и что? Зато посмотрите, какая крутая! Если она будет в ТЗ, то сильно упростит его чтение. Любой новичок поймет, что тут происходит! Значит, проще подключать коллег из других проектов на регресс.

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

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


пятница, 1 марта 2019 г.

Мнемоника ПОКРОВ день

На моем курсе «Школа для начинающих тестировщиков» есть творческое задание — придумать свою мнемонику по тестированию! Разумеется, оно необязательное ツ

Смотрите, что придумала Аня!

ПОКРОВ день – народно-христианский праздник восточных славян. В этот день, среди прочего, молились Роману Сладкопевцу (Савину?) — о просвещении разума, научении духовной грамоте и о помощи в трудном учении.


Итак, древнеславянские заветы о борьбе с жуками*:

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

* Bug (англ.) – жук, клоп, жучок, насекомое, букашка

По-моему, круто!

PS — если у вас тоже есть интересные мнемоники, не стесняйтесь, присылайте на ok.molechka@gmail.com! Для этого необязательно быть моим студентом)))

PPS — добавила пост в копилку мнемоник моих студентов, где их еще больше! Читайте и вдохновляйтесь!

четверг, 28 февраля 2019 г.

Сколько вопросов задавать по ТЗ

Как можно меньше, но чтобы все узнать. Важно не переборщить.

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

— А сколько разделов будет на сайте?
— А что, если их будет больше 100?
— А что, если товаров в разделе нет?
— А что, если я захочу купить 1 предмет?
— А если 10?
— А если 50?
— А если мне нужно 2 одинаковых?
— А что, если я закажу доставку за МКАД?
— А внутри МКАД?
— А какого цвета будет кнопочка заказа?
— А в каком порядке пойдут разделы?
— А …


среда, 20 февраля 2019 г.

Визуальные заметки. Майк Роуди


Ссылка на OZON

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

Конечно, в быстроте чтения мне помогло то, что в книге мало текста. Зато много картинок! 200 страниц как никак. При этом она довольно приятна на ощупь, можно не бояться поранься о страницы. А это актуально, потому что читать мне помогал Влад )))


Сделай! Твой первый шаг. Ицхак Пинтосевич


Ссылка на OZON

Я купила эту книгу во время тренинга Ицхака, чтобы автограф поставить 

В целом, книга очень позитивная! Хотя для меня слишком эмоциональная. Странно, что это я пишу, правда?)) Это же я обычно супер-эмоциональная, предложения все со смайликами и всё такое )))

Но не знаю. Когда в книге постоянно заверения «Да давай, ты МОЖЕШЬ», вот так, с капсом, это слишком... слащаво, чтоли. В книге это странно читать. Вот на тренинге — да, огонь! На тренинге Ицхак говорит те же фразы, но там ты заряжаешься энергией этого человека и это очень круто. А через книгу энергия не передается, поэтому выглядит странновато. Может, это потому, что я сначала на тренинге была, не знаю. Может, просто стиль книги лично мне не подходит.

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

вторник, 19 февраля 2019 г.

Что такое ПО (программное обеспечение)

В моей книге мы будем говорить именно про тестирование ПО. Хотя на самом деле тестировать можно все, что угодно:
  • Еду — вкусно ли? Не отравлено? Почитайте историю Старбакс, как они выводили новый сорт кофе. Бариста создавал, тестировал, менял компоненты и так по кругу.
  • Одежду — красиво? Стильно? Как в носке? А если вот тут прибавить, там убрать? А если пробегать весь день по городу, не появятся следы?
  • Железяки — в конструкторских бюро тоже есть свои тестировщики. Нельзя просто создать подшипник скольжения, нужно проверить его на прочность и другие характеристики.
Представим ситуацию — вы встречаете на улицу знакомого и он спрашивает вас, сколько сейчас времени.

понедельник, 18 февраля 2019 г.

Тут можно потыкать Mantis

Mantis — довольно популярный баг-трекер, хотя бы потому, что он бесплатный. Конечно, есть свои минусы и он не супер удобный (особенно, если сравнивать с redmine)... Но тем не менее, знакомьтесь!


Если хотите попробовать «пощупать» инструмент, чтобы сравнить его с другими и сделать взвешенный выбор — welcome на нашу тестовую площадку Smile :)


Тестовая площадка


http://mantisbt.testbase.ru/my_view_page.php (версия 2.19.0)

Данные для входа:
  • логин — test_user
  • пароль — 12345678
Для вас создан проект Test, резвитесь в нем!

суббота, 16 февраля 2019 г.

Изучаем программирование на JavaScript. Эрик Фримен, Элизабет Робсон


Ссылка на OZON

Потрясающая книга! Еще один шедевр O`Really. Обожаю эту серию книг! Все настолько доступно и понятно описано... Даже если вы никогда не занимались программированием, но хотите все понять — вам сюда.

Это книга-тренинг, в ней есть масса «домашних заданий», где вам предстоит самостоятельно писать код. А если вы ленивая жопа не хотите писать код сами, то можно подсмотреть сразу в ответах. А еще скачать готовый код с сайта. Но лично я до последней главы честно выполняла все задания. Иначе как запомнится материал, без практики то?

В конце уже стала халтурить и подсматривать готовые ответы, но основы — только через блокнот и набор текста самостоятельно! Именно так вы набиваете шишки типа «забыл скобочку закрыть» или «точку с запятой в конце поставить».

пятница, 15 февраля 2019 г.

Одна проблема = один баг

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



Плюсы подхода:
  • Он помогает не продолбать какую-то ошибку (поставили баг на 15 пунктов — разработчик исправил только 13)
  • Проще отслеживать статус — сколько из 15 пунктов исправлено?
  • Проще искать — на точечный баг будет конкретное название, на комплексный — непонятно что.

Минусы:
  • Когда тестируем большую фичу — приходится бегать по 30 связанным задачам, хотя половину можно записать одной строкой
  • Если слишком увлечься, можно начать ставить разные баги на одну проблему (нелокализовали и пошли каждое проявление отдельно фиксировать)

Допустим, мы тестируем Дадату, которая умеет обрабатывать и стандартизировать данные. Туда можно грузить файлики с данными. И вот мы что-то заморочились и навыдумывали кучу ФИО, адресов, телефонов... Загрузили файл и огребли сразу несколько проблем:

— адрес из одних «ОоОоОо» рушит систему;
— телефон из всех девяток тоже все ломает;
— сложное ФИО не разобралось;
— более 1000 строк обработать нельзя, они просто удаляются;
— ...

Конечно, мы пока не знаем этих причин, у нас просто файлик рухнул из-за адреса. Что делать дальше? Я периодически сталкиваюсь с таким подходом:

— Ну вот ведь файлик есть, на нем падает! А дальше пусть разработчик разбирается, отчего.

Как будет выглядеть в таком случае баг? «Падает обработка файла». Отчего? Неизвестно, пока разработчик не посмотрит.

вторник, 12 февраля 2019 г.

Usability-кейс. Как я пыталась включить микрофон в скайпе и в итоге ушла в ватсап

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

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

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

Скайп

Это все хорошо, но инструкция явно написана под типичный Samsung или Apple, там я видела приложения в настройках. Однако увы, у меня Vivo и другой андроид. Минут 5 копалась в настройках, искала там эти самые приложения. Пальцы замерзли, но ничего не нашла.

четверг, 7 февраля 2019 г.

MagicSearch — реальный REST-метод с кучей логики


Требования 


Конфлюенс
Гуглодока

Где удобно, там и смотрите, сами требования одинаковые.


Описание


В рамках подготовки курса по тестированию REST API я добавила в Users несколько новых SOAP & REST методов.

Но на самом деле парочка простых методов типа регистрации у меня уже была. Хотелось чего-то настоящего! А то это примерно как тестировать на курсе «Hello, World!», а потом столкнуться с реальным фреймворком — небо и земля ведь!

Поэтому я откопала в рабочей документации один сложный с точки зрения тест-дизайна метод. Конечно, он назывался не MagicSearch, а просто Search, но за глаза мы его называли «мэджик». Очень уж мудреный получился!

вторник, 29 января 2019 г.

Эффект лентяя в локализации багов


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

Помните про правило 20 минут — сначала поисследовали баг сами. Если не получается, попробуйте спросить разработчика. Вполне возможно, что вы будете копать весь день, пытаясь уловить логику воспроизведения, а разработчик посмотрит в код и поймет все за 5 минут. Не усложняйте себе жизнь. Сопоставляйте усилия и полученный результат.

Панбагон. Опечатка на кнопке «Продолжить покупки»

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


Очень простой баг, его сложно не заметить. Ну разве что весь текст читать по диагонали 

Да и то такая опечатка сразу бросается в глаза. Разве что ты тестируешь сайт уже в 100 раз, глаз замылен, текст просто не читаешь, так как помнишь наизусть.

В любом случае помните, что текст на кнопках — это тоже документация, которую надо тестировать!

См также:
Сообщения об ошибках — тоже документация, тестируйте их!

PS — добавила пост в общую копилку багов. 

суббота, 26 января 2019 г.

Поздравляем Марию с её первой работой!



Одна из наших выпускниц школы для начинающих (сокращенно ШНАТ) поделилась в конце года своим успехом — она нашла первую работу!

Я попросила Марию рассказать, чем помог курс, и помог ли. На этой неделе она немного разгрузилась после праздников, новогодних дедлайнов и прочего, и рассказала свою историю. А я хочу поделиться ей с вами!


4 декабря 2018 года, Мария

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


5 декабря 2018 года, Тренер

Поздравляю! :) А расскажите подробнее, пожалуйста, сколько собеседований прошли? Что спрашивали? Как ШНАТ помог? :)


23 января 2019 года, Мария

Ой, только вылезла из своей саппортёрской берлоги, докладываю:

пятница, 25 января 2019 г.

Мнемоники КИТКАТ и ВЗВОТ

На моем курсе «Школа для начинающих тестировщиков» есть творческое задание — придумать свою мнемонику по тестированию! Разумеется, оно необязательное ツ

Смотрите, что придумали ребята!

Валерия: КитКат



К — когда
И — изобретаешь
Т — тест,
К — качественно
А — анализируй
Т — требования!

Все ругают самописные тестовые фреймворки. А мы своим довольны


Ссылка на Хабр

Коллеги с соседнего проекта написали статью про один из наших тестовых фреймворков. Очень круто все описали!

О том, как развивались автотесты продукта Фактор, где сейчас этих автотестов тысячи. Да, это бывает по тысяче строк в одном файле, казалось бы «фи, скукота, я то думал, тысяча строк юнит-тестов». Но нет, мы пришли к DDT и тому, чтобы один раз написать фреймворк, а потом получать «один тест = одна строка во входном и выходном файле».

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

Может, даже идеи для ваших автотестов появятся. Потому что с JIRA мы круто сделали, я считаю. Прикиньте, тест вроде заскипан (падение игнорируется при прогоне), но, если вдруг заработал сам по себе, система сигнализирует об этом. А то бывает же, что делаешь другую задачу и тут, опа-опа, что-то еще починил ¯\_(ツ)_/¯

Так что приятного чтения!

См также:
Автотесты на уровне API для Java-приложений — про тесты на моем проекте
Больно пилить автотесты? Проси улучшать! — и как мы их улучшали

четверг, 24 января 2019 г.

Аналитическая культура. Карл Андерсон


Ссылка на OZON

Толстый такой томик. Я всё откладывала ее чтение, боялась, что это будет нудно и долго. Оказалось — нет! Шрифт довольно крупный + много графиков и картинок, прочитала быстро. И даже довольно интересно, хотя и не всё.

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

Некоторые выдержки из книги:


Аспекты качества данных

Автор говорит о том, какими характеристиками должны обладать собранные данные:

  • Доступность
  • Точность
  • Взаимосвязанность
  • Полнота
  • Непротиворечивость
  • Однозначность
  • Релевантность
  • Надежность
  • Своевременность
Ничего не напоминает? Wink ;)
Это же как тестирование документации!

среда, 23 января 2019 г.

Expected «null», but was «null» в автотестах

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

Собрала несколько любимых примеров из жизни, зацените:


Null

Допустим, должна быть пустая строка, а ты туда текстом null вписал. Тест падает:

expected «null», but was «null»

Угадай, что не так ¯\_(ツ)_/¯



пятница, 18 января 2019 г.

Тур супермодели для Азбуки Вкуса

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

Я хочу показать вам отличную работу одного из студентов, Александра! Он протестировал Азбуку вкуса


Основной тур — тур супермодели. Саша отлично справился с ним, а еще очень круто описал!
Вот, смотрите:

КП 11. Тур супермодели для Азбуки Вкуса (ссылка работает без авторизации).

Сохранила его работу на конфлюенсе в разделе «работы студентов», показывать как эталон Smile :) 

См также: 
Тур супермодели. The Supermodel Tour — описание тура

Мнемоники Елены: ЛИФТ и ЗЛО

На моем курсе «Школа для начинающих тестировщиков» есть творческое задание — придумать свою мнемонику по тестированию! Разумеется, оно необязательное ツ

Смотрите, что придумала Елена!

ЛИФТ

Логика
Интерфейс
Функции
Техническое воплощение



ЗЛО

Оформление бага – это ЗЛО:

Заголовок
Локализация
Обоснование



PS — если у вас тоже есть интересные мнемоники, не стесняйтесь, присылайте на ok.molechka@gmail.com! Для этого необязательно быть моим студентом)))

PPS — добавила пост в копилку мнемоник моих студентов, где их еще больше! Читайте и вдохновляйтесь!

среда, 16 января 2019 г.

Тестирование производительности, нагрузочное и стресс

Это статья из серии «Теория в картинках». 

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


1. Производительность: как быстро машина разгонится до сотни



пятница, 11 января 2019 г.

Итоги 2018 года


С прошедшим новым годом!

Продолжу свою традицию подводить итоги года. Правда, это фактически агрегация моих постов про 12 недель. И все же. Приятно оглянуться назад и посмотреть, сколько всего ты сделал!

И, конечно, начать строить новые планы Wink ;)

Мои прошлые итоги: 20162017.


Семья


Самое главное достижение года — сын Владислав, разумеется ツ 
Я родила ребенка! Это моё счастье, и бессонные ночи, и большая часть моего времени...


А еще — я осталась жива! Мне говорили, что если я доношу ребенка, отказавшись от операции (которую малыш врядли переживет), то могу не дожить до нового года. Дожила! ツ 

четверг, 10 января 2019 г.

Курс: Техники локализации плавающих ошибок


За все время проведения курсов у меня накопилось несколько отличных, просто шикарных задачек на тест-дизайн, отлов и локализацию багов. Это и Семен, и Юань (кто выполнял эти задания, наверняка вспомнил, о чем идет речь), и интересные баги в коде Folks... Я подумала — а почему бы не собрать их все вместе? Как самое сочное и интересное. А заодно рассказать побольше про локализацию.

Ведь локализация — это очень важно для тестировшика! Чтобы не бегать к разработчику с каждым багом: «Вась, Вась, там упало, а я не знаю, почему, помоги!», а самому найти первопричину. Чтобы самому воспроизвести падение у пользователя. Чтобы грамотно оформить задачу.

Для воспроизведения и локализации нужны навыки тест-дизайна. Потому что самые крутые задачи на воспроизведение — про нетривиальные классы эквивалентности. О которых даже не подумаешь, пока не столкнешься!

А еще нужно уметь прочитать логи, проверить запрос с клиента на сервер, иногда даже код почитать! Бисекционное деление применить, опять же... Ну и где же этому всему научиться? Smile :)

понедельник, 7 января 2019 г.

Курс «Тестирование REST API»


В конце прошлого года я запустила новый курс — «Тестирование REST API».

Курс получился мощный! На 5 лекций — 23 обязательных домашних задания. То есть примерно штук по 6 в каждой теме. Начиная от простейших «повтори за тренером» и заканчивая «протестируй вот этот метод».

Также на курсе есть нулевая тема, которая преследует несколько целей:
  1. Знакомство с тренером — лекция выложена в открытый доступ. Можно скачать и посмотреть, подходит вам такая подача материала, или нет.
  2. К ней не нужно домашнее задание, кроме «отправь запрос через Postman и Soap Ui». И вроде надо рассказать, что вообще такое API, какие бывают интеграции и прочая... Но какой смысл выкладывать лекцию, после которой студенты неделю бьют баклуши, а потом у них внезапно сразу куча домашек?
  3. Эта лекция не имеет прямого отношения к курсу, так, подготовительная теория. А почему бы ее не выложить заранее?
Ради курса я доработала систему Users. Добавила туда новый функционал (компании), новые поля контрагентам, а также новые методы. В юзерс появились:

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

Готовила я курс около 3 месяцев, как раз успела закончить перед родами. Я писала об этом во втором блоге: «12 недель: закончить курс перед родами». 

Очень переживала насчет темы 4, автоматизации на уровне постмана — а ну как начнутся возмущения «Я не хочу автоматизировать, уберите эти ДЗ!». Но нет, тема всем понравилась, говорили, что хотят подробнее изучить этот вопрос, "дайте больше теории и практики". Так что будет у меня отдельный курс на автоматизацию на уровне Postman. Ждите =)) А в этом курсе останется на уровне одной темы, чтобы хотя бы базу заложить.

четверг, 3 января 2019 г.

Паттерны и антипаттерны обоснования задач

Ссылка на Хабр


Исходно статья опубликована на Хабре, там у нее есть удобное оглавление, чтобы не листать многабукафф, а сразу перейти куда надо. В блоггере такое сделать сложнее, увы и ах  ╮(︶︿︶)╭


Когда вы заводите задачу, ее нужно обосновать. Вы должны убедить разработчика, что:
  • это действительно баг;
  • его необходимо исправить;
  • его нужно исправить именно так, как мы сказали.
А то иногда читаешь баги (особенно баги новичков) и задаешься вопросом:

Когда обоснование бага не нужно

Внезапно, не правда ли? =)

Вроде всегда говорю о том, что обосновывать свои задачи нужно и важно. Что ничего не писать, потому что «это очевидно» — плохо...

Тем не менее у антипаттерна «очевидно же» есть исключения. Нам и правда НЕ нужно писать обоснование, если система:
  • зависла;
  • упала с необработанной ошибкой;
Особенно если это произошло на production. Если у нас сайт лежит, тут не до обоснований, надо бить в гонг и бежать к разработчику «срочно чини!». Можно вообще без бага. А можно с кратеньким «Ошибка 500 на главной», этого хватит.

Не надо высасывать обоснование из пальца, потому что «оно нужно всегда». Писать «система не должна падать» — текст ради текста.

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



Иногда кажется, что это излишне:

Шаги
Открыть сайт http://example.com/  
Результат
Ошибка 500 
Ожидаемый результат
Открылась главная страница

Тут вроде бы все просто — главная не открывается, а должна. Но есть примеры сложнее.