пятница, 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 
Ожидаемый результат
Открылась главная страница

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

Проблема как обоснование бага

Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть?

Иногда обоснование вообще не пишут, так как «это же очевидно!». Или говорят: «Так правильно, мамой клянусь!». Или упирают на эмоции (зайчики обиделись). Но это все — плохие обоснования.

Лучше расскажите о какой-то реальной проблеме пользователя.

Потому что мы с вами – тестировщики. Наша задача — крушить и ломать, вводить «Войну и мир» в короткое поле, редактировать одну запись в двух вкладках браузера и прочая, прочая. И даже если у нас что-то не работает, это не значит, что пользователь тоже будет так поступать.

И иногда баги не исправляют просто потому, что «да никто так не делает!». И это нормально. Зачем тратить силы и ресурсы на проблему, которая никогда не возникнет?

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

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



Единообразие как обоснование бага

Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть?

Иногда обоснование вообще не пишут, так как «это же очевидно!». Или говорят: «Так правильно, мамой клянусь!». Или упирают на эмоции (зайчики обиделись). Но это все — плохие обоснования.

Вместо голосновных утверждений надо использовать факты. И пруфлинк в этом плане — отличное обоснование!

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



Например, если наша система работает как пунтосвитчер (это когда я печатаю на русском, забыв переключить раскладку, а система переключает ее сама). Я могу набрать «Ольга», а могу «Jkmuf», система второй вариант сама превратит в первый.

Пруфлинк как обоснование бага

Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть?

Иногда обоснование вообще не пишут, так как «это же очевидно!». Или говорят: «Так правильно, мамой клянусь!». Или упирают на эмоции (зайчики обиделись). Но это все — плохие обоснования.

Вместо голосновных утверждений надо использовать факты. И пруфлинк в этом плане — отличное обоснование!



Это может быть:
  • Ссылка на требования
  • Сами требования (ворд файл, презенташка...)
  • Ссылка в интернет
  • Подсчитанный ROI
  • Письмо заказчика
  • Статистика

Ссылка на требования

Самый простой баг — когда есть ТЗ и система работает не так, как там описано.

Так и пишем в ожидаемом результате: «57,9, потому что так в ТЗ». Хм, хм... Погодите-ка. Это звучит как «мамой клянусь»…

Да, в такой формулировке так и звучит. Поэтому подтвердите свои слова ссылкой. Иначе разработчик читает баг, и ему надо:
  • осознать, про какое ТЗ идет речь;
  • найти само ТЗ;
  • найти конкретное место, о котором речь;
  • вчитаться…

Зайчики обиделись (антипаттерн обоснования бага)



Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть?

Иногда результат вообще не пишут, так как «это же очевидно!». Особенно это любят студенты писать ))) Если «очевидно» не срабатывает, они используют паттерн «Мамой клянусь!». Но и это не вариант, нужны факты.

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

Я пытаюсь зарегистрироваться с именем Ктулху, а система не дает. Должна давать, а иначе.. Я обиделся и ушел, а ВЫ! Потеряли клиента! 
И обязательно все такие же как я, так что вы растеряли ВСЕХ клиентов, а они еще и в суд подали за оскорбление и все деньги отняли! 
И прочие кары...

Конечно, когда лично мне что-то не нравится, то очень злит игнорирование моей проблемы. Что значит «Нормальные люди не регистрируются с таким именем?» Я что, ненормальная?! Как хочу, так и называюсь, как вы можете мне что-то запрещать?!

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

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

Эмоций в баге быть не должно!



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

Поэтому если уж очень хочется — выскажите все устно. Обсудите с разработчиком задачу в курилке, яро отстаивая свою поцизию. Но как только дошли до компьютера — эмоции убираем, пишем лишь факты. Без «если да кабы» и без «а ВЫ! Потеряли клиента!»

Когда я только начинала работать в HFLabs, в моем личном KPI появился пункт «не ругаться и не наезжать» :-) 

Мамой клянусь, это баг!

Когда вы заводите баг, нужно обосновать свой ожидаемый результат. Почему именно так должно быть? Иногда результат вообще не пишут, так как «это же очевидно!»

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



То есть обоснование выглядит примерно так:

Очевидно же, что это баг!

Почему тестировщики не пишут обоснование в баге? Да потому, что им кажется это очевидным. И они проецируют свои мысли на всех: «Мне очевидно = всем очевидно, зачем что-то писать?»


Но на самом деле это не так, потому что каждый человек находится в каком-то своем контексте. И то, что очевидно вам, совсем не факт, что очевидно кому-то другому, потому что контекст у всех разный.

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