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

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

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

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


Null

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

expected «null», but was «null»

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



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

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

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

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


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

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

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


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

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

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

ЛИФТ

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



ЗЛО

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

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



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 появился пункт «не ругаться и не наезжать» :-) 

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

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

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



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

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

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


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

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