среда, 12 мая 2021 г.

Приоритет в магазине и в баге

Понятное дело, что для своей задачи хочется всегда поставить высокий приоритет. Ведь это же такой страшный баг, надо срочно исправить! Особенно когда речь идет о новичках 

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

И вот тут начинается приоритезация. Что действительно важно купить? Кошке корм хотели, но он ещё есть, зато молока совсем нету, лучше взять его. Высокий приоритет получают те продукты, без которые важно купить именно сейчас. А всё, что можно отложить на потом (завтра / в среду / через неделю) — это уже не высокий приоритет.

суббота, 8 мая 2021 г.

Тестирование совместимости

Что может повлиять на работу приложения?

— Разные ОС (Windows, Linux, MAC)

— Разное железо (видеокарта, процессор, и т.д.)

— Разные браузеры (сhrome, firefox, mobile opera, safari, IE)

— Разный сторонний софт (в браузере могут мешать плагины, на самом компе — Касперский или другое ПО, которое, например, выжирает память)

Совместимо ли ваше приложение с разными браузерами? А разными операционными системами? Именно в этом заключается тестирование совместимости — проверить и предоставить информацию.


пятница, 7 мая 2021 г.

Панбагон. Отвлекся на звонок? Корзина больше недоступна

Делала заказ на OZON. Посылка получилась весом около 20 кг, поэтому я стала размышлять, как сделать лучше:

  1. Отправить брату на квартиру и попросить его потом припереть ко мне.
  2. Заказать на квартиру (там ремонт и никто не живет, то есть ради курьера придется ехать) и попросить брата встретить.
Так как в любом случае мне нагружать брата, решила проконсультироваться с ним =) 
В итоге в озоне:
  • стоял предварительно адрес брата (прошлый заказ был туда)
  • я поменяла на другой адрес, но "оформить" не нажала
  • свернула приложение для звонка.
Созвонились с братом и решили пойти по первому варианту, то есть прислать посылку ему. Возвращаюсь в приложение (прошло ну минут 5 от силы), снова меняю адрес доставки на тот, что стоял исходно, нажимаю «далее». Но ой... Что-то пошло не так:

Ошибка в checkout


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

Тур чашки кофе

Входит в «Туры по развлекательным районам», Tours Through the Entertainment District

Вольный перевод статьи Уиттакера из книги Exploratory Software testing. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!

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

Пора отдохнуть!

Обычно попить чай / кофе — это недолго, минут на 5. Именно это мы и делаем, уходим на 5 минут, оставив приложение на каком-то этапе. Желательно, чтобы это был один из N этапов, то есть не заключительный — например, начали оформлять заказ в интернет-магазине и не закончили, отвлеклись. А потом вернулись и пытаетесь продолжить.


четверг, 6 мая 2021 г.

Требования ACID на простом языке

Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.

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

Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?

См также:

Что такое транзакция

Давайте пройдемся по каждой букве ACID и посмотрим на примерах, чем архив лучше 10 разных файлов. И чем транзакция лучше 10 отдельных запросов.

Ссылка на ХАБР


Atomicity — Атомарность

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

Друг познается в беде, а база данных — в работе с ошибками. О, если бы всё всегда было хорошо и без ошибок! Тогда бы никакие ACID были бы не нужны. Но как только возникает ошибка, атомарность становится очень важна.

Допустим, вы решили отправить маме деньги. Когда вы делаете перевод внутри банка, что происходит:

  1. У вас деньги списались

  2. Маме поступили

И допустим, что у нас 2 отдельных запроса. А теперь посмотрим, что будет при возникновении ошибок:


понедельник, 3 мая 2021 г.

Ресурсы и инструменты для практики с базами данных | SQL (видео)

 


У Дениса Безтужева на канале «All about QA» вышло классное для новичков видео — «Ресурсы и инструменты для обучения и практической работы с базами данных | SQL».

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

И мне видео в тему, у меня есть статья «Как изучить основы SQL за 2 дня», но там примеры на тяжеловесной БД, не все могут её установить, а мне и помочь то нечем, я сама эту базу лет 10 не поднимала уже... Всё хочу переписать примеры под XAMPP сервер, но это слишком низкий приоритет, уж извините)) А теперь есть куда послать потыкать!

См также:

Изучаем SQL. Линн Бейли — книга, очень её рекомендую

SQL. Полезные запросы — моя шпаргалка

Курсы по SQL, моя подборка

Что такое JSON

 Если вы тестируете API, то должны знать про два основных формата передачи данных:

  • XML — используется в SOAP (всегда) и REST-запросах (реже);

  • JSON — используется в REST-запросах.

Сегодня я расскажу вам про JSON. И расскажу в основном с точки зрения «послать запрос в Postman или прочитать ответ», потому что статья рассчитана на студентов, впервые работающих с Postman.


Ссылка на Хабр (там содержание кликабельное)


JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.

JSON используется в REST API. По крайней мере, тестировщик скорее всего столкнется с ним именно там.

См также:

Что такое API — общее знакомство с API

Что такое XML — второй популярный формат

Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST

В SOAP API возможен только формат XML, а вот REST API поддерживает как XML, так и JSON. Разработчики предпочитают JSON — он легче читается человеком и меньше весит. Так что давайте разберемся, как он выглядит, как его читать, и как ломать!


Как устроен JSON

В качестве значений в JSON могут быть использованы:

  • JSON-объект

  • Массив

  • Число (целое или вещественное)

  • Литералы true (логическое значение «истина»), false (логическое значение «ложь») и null

  • Строка

Я думаю, с простыми значениями вопросов не возникнет, поэтому разберем массивы и объекты. Ведь если говорить про REST API, то обычно вы будете отправлять / получать именно json-объекты.

 

JSON-массив — что это и как он устроен

Давайте начнем с примера. Это массив:

"MALE""FEMALE" ]

Массив заключен в квадратные скобки []


JSON-объект — что это и как он устроен

Возьмем пример из документации подсказок Дадаты по ФИО:

{
  "query": "Виктор Иван",
  "count": 7
}

И разберемся, что означает эта запись.

Объект заключен в фигурные скобки {}

JSON-объект — это неупорядоченное множество пар «ключ:значение».

Ключ — это название параметра, который мы передаем серверу. Он служит маркером для принимающей запрос системы: «смотри, здесь у меня значение такого-то параметра!». А иначе как система поймет, где что? Ей нужна подсказка!


Правила Well Formed JSON

Это выдержка из моей статьи «Что такое JSON»

Разработчик сам решает, какой JSON будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. Наш JSON должен быть well formed, то есть синтаксически корректный.

Чтобы проверить JSON на синтаксис, можно использовать любой JSON Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

Но учтите, что парсеры внутри кода работают не по википедии или w3schools, а по RFC, стандарту. Так что если хотите изучить «каким должен быть JSON», то правильнее открывать RFC и искать там JSON Grammar. Однако простому тестировщику хватит набора типовых правил с w3schools, их и разберем.

Правила well formed JSON:

  1. Данные написаны в виде пар «ключ:значение»

  2. Данные разделены запятыми

  3. Объект находится внутри фигурных скобок {}

  4. Массив — внутри квадратных []

 

среда, 21 апреля 2021 г.

Правила Well Formed XML

Это выдержка из моей статьи «Что такое XML»

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.




Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

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

Что такое VCS (система контроля версий)

Система контроля версий (от англ. Version Control System, VCS) — это место хранения кода. Как dropbox, только для разработчиков!

Она заточена именно на разработку продуктов. То есть на хранение кода, синхронизацию работы нескольких человек, создание релизов (бранчей)... Но давайте я лучше расскажу на примере, чем она лучше дропбокса. Всё как всегда, история с кучей картиночек для наглядности ))

А потом я подробнее расскажу, как VCS работает — что значит "создать репозиторий", "закоммитить и смерджить изменения", и другие страшные слова. В конце мы пощупаем одну из систем VCS руками, скачаем код из открытого репозитория.


Что это такое и зачем она нужна


Допустим, что мы делаем калькулятор на Java (язык программирования). У нас есть несколько разработчиков — Вася, Петя и Иван. Через неделю нужно показывать результат заказчику, так что распределяем работу:

  • Вася делает сложение;

  • Петя — вычитание;

  • Иван — начинает умножение, но оно сложное, поэтому переедет в следующий релиз.

Исходный код калькулятора хранится в обычной папке на сетевом диске, к которому все трое имеют доступ. Разработчик копирует этот код к себе на машину, вносит изменения и проверяет. Если всё хорошо — кладет обратно. Так что код в общей папке всегда рабочий!


Что такое бранч (отдельная ветка в коде) и зачем она нужна

Это выдержка из моей статьи «Что такое VCS (система контроля версий)». Нужна именно как напоминание «что такое бранч», если с самой системой контроля версий вы уже знакомы

— Бранч — это отдельная ветка в коде. Вот смотрите, мы сейчас работаем в trunk-е, основной ветке.

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

Потом разработчик добавляет новый функционал и коммитит его — это версия 1 кода.


вторник, 20 апреля 2021 г.

воскресенье, 18 апреля 2021 г.

Мои 12 недель в году. Часть 15 (костная пластика и Консоль)


Первый опытвторойтретий4567891011121314

 

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

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

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

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



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

У нас появилась кошка!! Знакомьтесь, это (на фото чуть выше) — Консоль =))) Главная радость цикла )))

А вообще, бомбический получился цикл по содержанию бесплатных полезняшек! Я написала 11 хабра-постов. 11 !!!! Это вместо запланированной ОДНОЙ, максимум двух =))) И столько же видео опубликовала на ютубе. Вообще стремлюсь к «1 видео в неделю», но где-то не срослось.. Ну и ладно, всё равно много!


Основные цели:

— книга: найти еще художников

— курсы: сделать 1 урок курса по регуляркам

— статья на ХАБР!


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

Так что план по книге и статьям выполнен и перевыполнен! А вот с курсами не срослось. У меня всё время занимали статьи... Думала отложить на конец цикла и там уже сделать хоть что-то, ну чтобы в результатах написать. В этом фишка циклов на 12 недель, когда маячит дедлайн, берешься за продолбанные цели Широкая улыбка :D

Но в этот раз ближе к концу цикла я решила вновь заняться своими зубами (у меня 2 дырки, вырвали 2 года назад последние молочные, коренных под ними нет). Врач сказал, что десна тонкая и нужна костная пластика. Что же, сделала её. Лицо попухло и пару недель о записи вебинара и речи быть не могло. А потом заболели с ребенком, а запись "в нос" тоже не ахти. Так что курс переехал в летний цикл!

Но зато вон сколько всего получилось:
  1. Сделали 400 картинок к книге \(〇_o)/ 
  2. Посты из книги, пополняя бесплатный онлайн-вариант —  15 штук ٩(◕‿◕。)۶
  3. Улучшалки по текущим курсам — они небольшие, но набирается прилично! 
    1. Улучшалки по ШНАТ — 30 штук
    2. Постман  — 11 штук
    3. Рест —  6 штук
    4. Логи — 3 штуки
    5. Локализация — 1
  4. Пополняю раздел «работы студентов» — 2 штуки
  5. Пополнила свой youtube-канал — 11 штук! \(〇_o)/ 
  6. Статьи на Хабр — 11 штук! \(〇_o)/ \(〇_o)/ \(〇_o)/ 
  7. Testbase — 7 улучшалок
  8. Прочитала 3 книги ¯\_(ツ)_/¯
  9. Прошла курс по фидбеку
  10. Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто
  11. Завели кошку!!
  12. Купила Владу санки с колесиками, очень удачно, катались всю зиму
  13. Отказались от соски!!!
  14. Ходила в кино — в том числе в 4дх!
  15. Играли в настолочки )))
  16. Выбралась на ДР компании!
  17. Встретилась с Юлечкой (1.5 года не виделись)
  18. Встречалась с друзьями другими
  19. Ходила в СПА 3 раза ^_^
  20. Занималась ремонтом
  21. Забрала исполнительный лист и отнесла в банк (зря, надо было приставам)
  22. Сделала костную пластику на деснах
  23. Мне сорвало батарею на новой квартире, жестокий опыт)))

суббота, 3 апреля 2021 г.

Визуализация ТЗ — диаграммы, схемы, картинки

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

Как же сделать ТЗ понятнее? Можно улучшить текст — вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...

Причем сделать это может не только аналитик, но и любой член команды. Тестировщикам особенно полезно визуализировать ТЗ, потому что это помогает сразу увидеть проблемные места и уточнить их ещё до реализации. Раннее тестирование и всё такое.

воскресенье, 28 марта 2021 г.

State & Transition Diagram — что это и как применять

 State & Transition Diagram (сокращенно S&T) — схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.

Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.

Что такое bash / shell

 И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:

cd /home

То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.

Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls… (в винде эти команды немного другие)

среда, 24 марта 2021 г.

Сила мгновенных решений. Малкольм Гладуэлл

 


Ссылка на OZON

Исходно купила книгу из-за серии Psychology. Я прочитала «Хватит мечтать, займись делом!», мне понравилось ))) Так что по интересным названиям заказала ещё несколько книг из этой серии. Вот одну уже прочитала. Ну а что, это книги карманного варианта, маленькая, интересно написанная. Самое то!

Начинает книгу автор с рассказа о куросе Гетти (курос — это статуя юноши). В музей Гетти продали курос. Якобы он прекрасно сохранился, поэтому очень ценная находка. Курос обследовали около года разные специалисты, никаких изъянов они не нашли, поэтому статую купили. 

Но несколько специалистов, едва взглянув на курос, сразу определяли подделку. Кто-то сочувствовал музею, который её купил. Кто-то говорил "слишком молодая". Фишка в том, что специалисты моментально чуяли фальш. Потом провели кучу консилиумов и осознали, что да, таки подделка. Но почему её не обнаружили ученые в течение года, зато другие поняли за доли секунды?

пятница, 19 марта 2021 г.

Почему вам не дают подробный фидбек после собеседования

 Зашла вчера в чат тестировщиков и вижу знакомый диалог:


— Мне в фирме 1 обещали фидбек через пару дней. В итоге неделя прошла, сам им пишу, а меня игнорят...


— Ага, я вот тоже собеседование в фирме 2 прошел, мне обещали ответ дать. А прислали просто отписку! «Вы нам не подходите», и всё.





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

Мнемоники ПРЁТ и ВРЁТ

Мне на почту прислали мнемоники для регулярных выражений. Тут небольшой спойлер: регулярка [а-я] найдет все буквы от «а» до «я», кроме буквы «ё». На эту тему и мнемоники. 

Автор — ЛяДиезМажор



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

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

пятница, 12 марта 2021 г.

Лайфхаки: как получить больше обратной связи после собеседования

Когда человек проходит собеседование или выполняет тестовое задание, компания даёт ему обратную связь: «вы красавчик, вот оффер / извините, вы нам не подходите». В случае отказа обычно примерно так и пишут: «извините, вы не подошли». А вот что именно было плохо и какие навыки нужно прокачать — непонятно!

Я хочу дать вам пару лайфхаков, как можно получить чуть больше обратной связи:

  • Лайфхак 1. Просто попросите!
  • Лайфхак 2. После фидбека исправьте тестовое 

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


Лайфхак 1. Просто попросите!


Да-да, всё так просто! Попросите более подробный фидбек. За спрос не бьют!

Если вы сидите на собеседовании и решаете тестовое «здесь и сейчас», то после окончания задачи спросите: 

— А что я еще пропустил? О чем не подумал? Насколько вообще все хорошо или плохо? Что можно почитать / погуглить?

четверг, 11 марта 2021 г.

Decision Table — что это и как применять

Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинаторику условий из ТЗ.

Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям ))




Ссылка на ХАБР

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

вторник, 9 марта 2021 г.

Лайфхак для HR: как дать более подробный фидбек кандидату

Как обычно проходит техническое собеседование в ИТ-фирме, в которой есть HR:

  1. HR организует встречу
  2. Технический специалист проводит собеседование (тестировщик, разработчик, PM)
  3. Этот спец говорит HR «да / нет»
  4. HR даёт ответ кандидату.
Сам по себе HR не может дать вам подробный фидбек. Он ведь не разбирается в тестировании. Да и на собеседовании не был, он его только организовал. 

Поэтому фидбек дает тестировщик, который проверял ваше тестовое задание. Или проводил собеседование. А у него свои дела! Так и отмахивается: 

— Этому откажи, всё, у меня релиз горит!


Ну а что HR остается? Написать отказ без подробностей… Или действовать хитрее :)

суббота, 6 марта 2021 г.

Регулярные выражения (regexp) — основы

Регулярные выражения (их еще называют regexp, или regex) — это механизм для поиска и замены текста. В строке, файле, нескольких файлах... Их используют разработчики в коде приложения, тестировщики в автотестах, да просто при работе в командной строке!

Ссылка на ХАБР


Чем это лучше простого поиска? Тем, что позволяет задать шаблон.

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


А регулярное выражение позволяет задать шаблон «найди мне цифры в таком-то формате».

Для чего применяют регулярные выражения?

  1. Удалить все файлы, начинающиеся на test (чистим за собой тестовые данные)
  2. Найти все логи
  3. grep-нуть логи
  4. Найти все даты
  5. ...

А еще для замены — например, чтобы изменить формат всех дат в файле. Если дата одна, можно изменить вручную. А если их 200, проще написать регулярку и подменить автоматически. Тем более что регулярные выражения поддерживаются даже простым блокнотом (в Notepad++ они точно есть).


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

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

Тестировщик usability — книги и курсы

О профессии

Основные задачи тестировщика юзабилити:

  1. Проверять документацию на «понятность» простому пользователю
  2. Проверять тексты на сайте на понятность
  3. Проверять продукт на интуитивность, понятность, обучаемость



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

Response body was not logged в Postman, что делать

Допустим, что вы запустили в Postman коллекцию и хотите посмотреть, какой ответ вернул сервер на запрос. Но ой, ответ не логируется:

Response body was not logged


Что делать?

вторник, 23 февраля 2021 г.

Почему заставить подумать лучше, чем разжевать ответ

Сегодня в группе телеграмма по обсуждению курсов затронули тему ШНАТ (это моя школа для начинающих тестировщиков), в том числе фидбек от тренера.

У моего курса есть особенность — вместо готового ответа тренер задает наводящие вопросы, чтобы помочь студенту дойти до ответа самому. Но это часто раздражает, особенно новичков:

— Ну не видишь что ли, я не понимаю! Просто возьми и объясни! Мне больше подходит прямой ответ.


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

Собственно, у меня было два репетитора с кардинально разным подходом. И я хочу рассказать о них:

Как я дала подробный фидбек кандидату и пожалела об этом :)

Как то раз HR сделала мне forward тестового задания. А я была в отпуске, ну и пришла отбивка «я в отпуске» человеку. С моей рабочей почты, где в подписи указан личный телефон.

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

— Алло, Ольга?

— Да.

— Я такой-то, присылал вам такое-то тестовое задание. 

— Эээээ, а разве Настя вам не ответила?

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

— Нет, ошибки тут нет. Я ваше решение видела и попросила ее прислать отказ.

— Но почему??!! Расскажите, что не так было??

суббота, 20 февраля 2021 г.

Чек-лист тестирования требований

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

Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:

  1. Полнота
  2. Однозначность
  3. Непротиворечивость
  4. Необходимость
  5. Осуществимость
  6. Тестируемость

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

В этой статье я расскажу о каждой из них поподробнее, с картиночками и примерами из жизни.


Ссылка на ХАБР


1. Полнота

Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода?

пятница, 19 февраля 2021 г.

Отдаю книги-8 (Москва)

Люблю бумажные издания, но не хочу захламлять квартиру, так что периодами отдаю свои книжки. Вот текущие (не все):

Приехать забрать книги надо будет в офис ХФЛабс, это около метро на кольце. Парк Культуры, с 10 до 19 в будние дни.

Чтобы забрать книжку:

  1. Напишите мне на почту — ok.molechka@gmail.com. Укажите имя, какие хотите книги и когда приедете (в указанный выше интервал времени)
  2. Я дам вам номер моей коллеги Кати (я в декрете, меня в офисе нет). 
  3. Приезжаете в указанное время, звоните, забираете книжки — профит!


Книги


1. Доставляя счастье. Тони Шей. 



четверг, 18 февраля 2021 г.

Какая бывает документация

Когда мы говорим о тестировании документации, то обычно подразумеваем тестирование требований, ТЗ. И это тестирование на полноту, однозначность и прочая. Смотрим, как новый функционал будет коррелировать со старым, не будет ли проблем. Заранее продумываем свои тесты, обсуждаем реализацию...



Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Эта статья — как чек-лист, «что еще нужно найти и проверить».

Итак, давайте посмотрим, какая бывает документация:

Ссылка на ХАБР



1. ТЗ — требования


ТЗ — техническое задание. Это основной тип документации для тестировщика. Если ТЗ есть, его всегда надо тестировать. Как само ТЗ, так и систему на соответствие этому ТЗ. Помните самые простейшие баги? Когда есть четкие требования, но система работает по-другому.


Виды требований

В каком виде могут быть требования? Есть разные варианты.

Как тестировать pop-up сообщения

 Pop-up — это всплывающее окошко, как навязчивое «а вы уже лайкнули нас в фейсбуке?».


В веб приложениях это обычно:

  • уведомление о регистрации;
  • акционное предложение;
  • мини-версия корзины с покупками;
  • ...

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

В мобильных игрушках:

  • реклама новой игрушки;
  • временная акция;
  • поздравляшка с успешным окончанием уровня;
  • не-поздравляшка «ты провалил уровень»;
  • ...

Что тут стоит проверить? Влезает ли текст в отведенное ему место =))

Каким должно быть сообщение об ошибке

Каким должно быть сообщение об ошибке?

— Коротким, иначе пользователь заснет, читая его.

— Понятным, иначе как понять, что я сделала не так?


Из сообщения должно быть понятно:

— В чем моя ошибка?

— Что мне сделать, чтобы исправить ее?


При этом сообщение должно быть в мире пользователя. Мне будут одинаково непонятны тексты:

— Извините, что-то сломалось.

— Error 38759245, see line 333 in code

— Неправильно введены данные.


Особенно на форме из 100 полей. Какие именно данные я ввела неверно? И даже если их подсветили красным, а что неверно то? Как верно будет? Вы мне скажите, что делать то надо.

Как тестировать письма от системы

Сейчас многие системы присылают приветствия, напоминания, уведомления... Так вот эти письма — это часть документации системы. Ведь там могут быть описаны правила поведения на сайте, порядок процесса покупки, или что-то другое.

С другой стороны, письмо — это часть функционала системы. Потому что разработчик программирует:

  1. В какой момент письмо должно быть отправлено (после регистрации на сайте, при нажатии на конкретную кнопку, за сутки до даты билеты...);
  2. Что находится внутри него (статичный текст, переменные).
Именно это и надо проверять! Что письмо отправляется тогда, когда нужно, и что внутри всё верно. А что может быть не так внутри? Некий статичный текст, вычитали на опечатки, и всё... Да, если текст статичный, достаточно проверить один раз. А вот если нет...

Типичные проблемы писем — плейсхолдеры, которые:

  • не разименовались;
  • разименовались, но неправильно.

Что такое плейсхолдер? Это заглушка, которая меняется на нужное значение при отправке письма. Разработчик же не знает заранее, как вас зовут. Но допустим, что он хочет сделать именное письмо:


Привет, Ольга! Спасибо за регистрацию на нашем сайте...

Привет, Андрей! Спасибо за регистрацию на нашем сайте...

Привет, Сладкий пупсик! Спасибо за регистрацию на нашем сайте...

 

Примеры всегда тестируем!

Всегда проверяйте примеры. Просто ВСЕГДА!

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

И если этот пример не работает — вот где эпик фейл. Зачем работать с системой, если она на собственных данных обламывается? Так что примеры тестируем в обязательном порядке.

Но давайте разберемся, где эти самые примеры искать. Что к ним относится? Пройдемся по основным типам. 

среда, 17 февраля 2021 г.

Фидбэк. Практический онлайн-интенсив


Ссылка на курс — https://productmindset.net/feedback

Проходит — онлайн-созвоны в зуме (лучше присутствовать, а не смотреть в записи)

Цена — 12 000 (на февраль 2021)


Шикарный курс! Вот всем менеджерам и руководителям в ИТ прям очень рекомендую )))

Тут будут учить давать фидбек. Такой, к которому человек прислушается, а не просто отмахнется «опять он придирается». Фидбек — это когда вы хотите изменить поведение человека. А чтобы он тоже захотел что-то изменить, вы должны показать ему ЕГО профит от изменений.

Ведет курс Алексей Кулаков, генеральный директор JetStyle и директор по продукту издательского сервиса Rideró. Вот тут можно почитать его статьи — https://jetstyle.ru/articles/.

Обучение в формате интенсива, каждый день нужно находить 1-2ч времени на созвоны и общение. Один день Алексей проводит вебинар, второй день вы с группой делаете домашку. На вебинаре теория + практика, кто готов сразу пробовать, тренируется на Алексее. Потом отрабатываем в своих группах.

воскресенье, 7 февраля 2021 г.

Топ-3 плагина для автозаполнения полей


Ссылка на ХАБР


Сегодня я расскажу про плагины, которые помогают быстро заполнить поля тестируемой формы. Рассказ также доступен и в виде видео. Мой топ-3:

  • 3 место — Bug magnet
  • 2 место — Web developer toolbar
  • 1 место — Form Filler

Применять плагины мы будем на бесплатной системе Users

Если авторизоваться в системе, можно добавить новую компанию. Из обязательных полей только «название» и «тип», но есть еще 6 дополнительных — ИНН, ОГРН, КПП, телефон, адрес, сотрудники.


Для тестирования обычно нужно иметь хотя бы одну полностью заполненную карточку. И именно это вызывает тоску — сидеть и прописывать все поля формы. Даже когда все эти поля — простые строки, всё равно скучно. А уж если они ещё и с ограничениями…