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

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

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

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

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

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

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

Как то раз 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 полей. Какие именно данные я ввела неверно? И даже если их подсветили красным, а что неверно то? Как верно будет? Вы мне скажите, что делать то надо.