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

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

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

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

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

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

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

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

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

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

— Да.

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

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

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

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

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

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

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

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

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

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

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

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

1. Полнота

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

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

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

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

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

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

Книги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Error 38759245, see line 333 in code

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

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

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

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

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

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

Именно это и надо проверять! Что письмо отправляется тогда, когда нужно, и что внутри всё верно. А что может быть не так внутри? Некий статичный текст, вычитали на опечатки, и всё... Да, если текст статичный, достаточно проверить один раз. А вот если нет...

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Февраль начался продуктивно. В прошлом посте я писала о выпускнице Наталье, которая с 1 февраля выходит на работу. А сегодня там в комментариях отметилась Мария, она же продублировала свою историю успеха в группе в ВК:

********************************************

Появился и у меня повод написать отзыв (многобукв). Сегодня был мой ПЕРВЫЙ РАБОЧИЙ ДЕНЬ в качестве тестировщика!

Проходила курс с сентября по ноябрь 2020. Главный тренер в нашей группе был Олег. И когда я училась на курсах, я очень злилась на себя, когда не с 1 и не с 4го!! раза сдавала некоторые домашки, но сейчас понимаю, что это ещё как пошло на пользу! Олег Москаленко, спасибо вам отдельное за терпение, особенно когда нервы были у студентов на пределе, за ответы в выходные и поздними вечерами, за кучу перепроверенных по миллиону раз домашек. 

А когда я только читала отзывы про ШНАТ, я глазам не верила и не понимала откуда столько положительных отзывов, да еще и со скорейшим трудоустройством — теперь, конечно, всё ясно)) Курс был очень интересный, интенсивный с самого первого дня (ах, задание про стул...).