Основные задачи тестировщика юзабилити:
Все мы немного тестировщики юзабилити. Ведь такой тестировщик должен думать о конечном пользователе — что будет ему неудобно или непонятно? А все мы являемся пользователями: интернет-магазин, оплата картой, банк онлайн...
Допустим, что вы запустили в Postman коллекцию и хотите посмотреть, какой ответ вернул сервер на запрос. Но ой, ответ не логируется:
Response body was not logged
Что делать?
Сегодня в группе телеграмма по обсуждению курсов затронули тему ШНАТ (это моя школа для начинающих тестировщиков), в том числе фидбек от тренера.
У моего курса есть особенность — вместо готового ответа тренер задает наводящие вопросы, чтобы помочь студенту дойти до ответа самому. Но это часто раздражает, особенно новичков:
— Ну не видишь что ли, я не понимаю! Просто возьми и объясни! Мне больше подходит прямой ответ.
Если вы думаете, что я не понимаю такую реакцию, то вы заблуждаетесь ))) Выше вообще приведены мои мысли (кроме последнего предложения) — с того далекого времени, когда я поступала в институт.
Собственно, у меня было два репетитора с кардинально разным подходом. И я хочу рассказать о них:
Как то раз HR сделала мне forward тестового задания. А я была в отпуске, ну и пришла отбивка «я в отпуске» человеку. С моей рабочей почты, где в подписи указан личный телефон.
Тестовое было слабое, так что я попросила HR отказать кандидату. Допустим, HR звали Настя. Выхожу из отпуска, мне звонок с неизвестного номера:
— Алло, Ольга?
— Да.
— Я такой-то, присылал вам такое-то тестовое задание.
— Эээээ, а разве Настя вам не ответила?
— Ответила, но она прислала мне отказ. Я думаю, что она просто некомпетентна и просто не поняла, что мое решение правильное (я уже тут слегка прифигела, взял и «опустил» Настю). Я бы хотел, чтобы на него взглянул тестировщик.
— Нет, ошибки тут нет. Я ваше решение видела и попросила ее прислать отказ.
— Но почему??!! Расскажите, что не так было??
Когда разрабатывается новая функциональность системы, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
Конечно, их может быть и больше. Кто-то использует мнемонику CIRCUS MATTA, кто-то расширяет список под себя и команду. Но эти шесть характеристик — основные. О них и в книгах по тестированию пишут, и в самых разных статьях.
В этой статье я расскажу о каждой из них поподробнее, с картиночками и примерами из жизни.
Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода?
Люблю бумажные издания, но не хочу захламлять квартиру, так что периодами отдаю свои книжки. Вот текущие (не все):
Приехать забрать книги надо будет в офис ХФЛабс, это около метро на кольце. Парк Культуры, с 10 до 19 в будние дни.
Чтобы забрать книжку:
Когда мы говорим о тестировании документации, то обычно подразумеваем тестирование требований, ТЗ. И это тестирование на полноту, однозначность и прочая. Смотрим, как новый функционал будет коррелировать со старым, не будет ли проблем. Заранее продумываем свои тесты, обсуждаем реализацию...
Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Эта статья — как чек-лист, «что еще нужно найти и проверить».
Итак, давайте посмотрим, какая бывает документация:
ТЗ — техническое задание. Это основной тип документации для тестировщика. Если ТЗ есть, его всегда надо тестировать. Как само ТЗ, так и систему на соответствие этому ТЗ. Помните самые простейшие баги? Когда есть четкие требования, но система работает по-другому.
Виды требований
В каком виде могут быть требования? Есть разные варианты.
