#тест_дизайн #стратегия_тестирования
Проверь, везде ли пароли передаются в зашифрованном виде. Стоит обратить внимание не только на очевидные регистрацию и авторизацию, но и на страницы смены/подтверждения пароля, изменения логина и тд.
Проверь, везде ли пароли передаются в зашифрованном виде. Стоит обратить внимание не только на очевидные регистрацию и авторизацию, но и на страницы смены/подтверждения пароля, изменения логина и тд.
#тест_дизайн #стратегия_тестирования
Задача со звёздочкой: обязательно проверьте, что ваши приватные запросы (например, на переиндексацию базы данных или сброс кешей) закрыты для внешних ip или иным способом защищены от использования извне (за исключением интеграций, конечно)
Задача со звёздочкой: обязательно проверьте, что ваши приватные запросы (например, на переиндексацию базы данных или сброс кешей) закрыты для внешних ip или иным способом защищены от использования извне (за исключением интеграций, конечно)
#тест_дизайн #стратегия_тестирования
Тестирование вёрстки и viewport
Для тестирования вёрстки принципиально важно отличать viewport устройства от его физических высоты и ширины экрана, диагонали.
Для целей проверки вёрстки мы смотрим именно на viewport.
Устройства с разными физическими высотой и шириной могут иметь одинаковые вьюпорты, и наоборот.
Параметры, которые вы выставляете в device toolbar в ДевТулзах (или любом аналоге) - это именно вьюпорт.
Как узнать вьюпорт устройства? Самое простое подсмотреть в интернетах. Я часто пользуюсь этим источником.
Но не забывайте проверить инфу в нескольких источниках или (если есть реальное устройство под рукой) зайти на сайт проверки разрешения вашего окна браузера, например этот.
Тестирование вёрстки и viewport
Для тестирования вёрстки принципиально важно отличать viewport устройства от его физических высоты и ширины экрана, диагонали.
Для целей проверки вёрстки мы смотрим именно на viewport.
Устройства с разными физическими высотой и шириной могут иметь одинаковые вьюпорты, и наоборот.
Параметры, которые вы выставляете в device toolbar в ДевТулзах (или любом аналоге) - это именно вьюпорт.
Как узнать вьюпорт устройства? Самое простое подсмотреть в интернетах. Я часто пользуюсь этим источником.
Но не забывайте проверить инфу в нескольких источниках или (если есть реальное устройство под рукой) зайти на сайт проверки разрешения вашего окна браузера, например этот.
#тест_дизайн #стратегия_тестирования
Исследовательское тестирование
Искренне верю в силу исследовательского тестирования как одного из этапов тестирования продукта.
Как по мне, лучше всего проводить его, когда уже знаешь требования, но ещё не протестировал фичу вдоль и поперёк. Получается эффективный способ познакомиться с фичей, пройти основные пользовательские флоу, "незамыленным" взглядом посмотреть на фичу и задаться вопросами относительно юзабилити.
Лучше статьи по теме, чем эта, я пока не встречала. Если коротко там о:
- теории и разнице между исследовательским и ad hoc тестированием
- том, почему автотесты и регресс не заменят исследовательское тестирование
- том, как сделать исследовательское тестирование на проекте полезным и разнообразным
- концепции тестирования, тестовых турах, эвристических методах
Всё это с оч крутыми примерами
Исследовательское тестирование
Искренне верю в силу исследовательского тестирования как одного из этапов тестирования продукта.
Как по мне, лучше всего проводить его, когда уже знаешь требования, но ещё не протестировал фичу вдоль и поперёк. Получается эффективный способ познакомиться с фичей, пройти основные пользовательские флоу, "незамыленным" взглядом посмотреть на фичу и задаться вопросами относительно юзабилити.
Лучше статьи по теме, чем эта, я пока не встречала. Если коротко там о:
- теории и разнице между исследовательским и ad hoc тестированием
- том, почему автотесты и регресс не заменят исследовательское тестирование
- том, как сделать исследовательское тестирование на проекте полезным и разнообразным
- концепции тестирования, тестовых турах, эвристических методах
Всё это с оч крутыми примерами
#тест_дизайн #стратегия_тестирования
Про тестовые аккаунты на проде
Это точно не всё, что нужно делать, но хотя бы это:
- веди учёт тестовых аккаунтов (их можно переиспользовать, а не плодить при каждом тесте)
- используй шаблон логина, например Ivanov_qa_031121 (так тебя можно будет опознать)
- используй разные и безопасные пароли
- если тестовые аккаунты создаются часто и в большом количестве, полезно иметь возможность их отсортировать (в этом помогает шаблон), деактивировать и/или удалить
Про тестовые аккаунты на проде
Это точно не всё, что нужно делать, но хотя бы это:
- веди учёт тестовых аккаунтов (их можно переиспользовать, а не плодить при каждом тесте)
- используй шаблон логина, например Ivanov_qa_031121 (так тебя можно будет опознать)
- используй разные и безопасные пароли
- если тестовые аккаунты создаются часто и в большом количестве, полезно иметь возможность их отсортировать (в этом помогает шаблон), деактивировать и/или удалить
#тест_дизайн #стратегия_тестирования
CRUD
Техника CRUD отлично подходит не только для работы с базами данных, но и для проведения базовых функциональных проверок.
За акронимом CRUD скрываются create (создание) - read (чтение) - update (модификация) - delete (удаление).
В любой непонятной ситуации вспомни про CRUD и проверь функционал.
На примере функциональности "новый пользователь":
C - создать пользователя
R - открыть карточку пользователя на чтение
U - внести изменения в данные пользователя, сохранить
D - удалить пользователя
CRUD
Техника CRUD отлично подходит не только для работы с базами данных, но и для проведения базовых функциональных проверок.
За акронимом CRUD скрываются create (создание) - read (чтение) - update (модификация) - delete (удаление).
В любой непонятной ситуации вспомни про CRUD и проверь функционал.
На примере функциональности "новый пользователь":
C - создать пользователя
R - открыть карточку пользователя на чтение
U - внести изменения в данные пользователя, сохранить
D - удалить пользователя
#тест_дизайн #стратегия_тестирования #артефакты
Ревью тест-кейсов
Тест-кейсы (и чек-листы) можно не только писать, но лучше ещё и ревьюить.
Вот тут можно послушать, как это сделали другие.
Что полезного там услышала я (но вы лучше сами послушайте):
- ревью - это проверка с целью выявления и дальнейшего исправления ошибок, недочётов, расхождения в стиле написания, несоответствий написанного в тест-кейсе/чек-листе и постановленной задаче
- проблемы подхода: самый активный ревьюит всех, быстро все ревью станут успешны, не всё ревьюили, ручной режим
- когда отдавать на ревью? перед началом тестирования. когда тесты готовы, но тестирование не начато
- кто ревьюит? дежурный, закрепленная пара, любой по очереди
- что отдавать? кейсы по багам, новый функционал, регресс
- что не отдавать? самое простое
- что смотреть? заголовок, описание задачи, комментарии, коммиты
- полнота покрытия/избыточность. проблемы: пропускали много негативных сценариев, учтены ли все зависимости, наличие лишних проверок
- нужны регламент и проверка оформления
- 2 цели хорошего тест-кейса: 1. определить, что ПО соответствует требованиям 2. выявить ситуации, когда ПО ведёт себя нежелательным образом
- заголовки: отвечает на вопрос, что проверяем? не использовать лишние слова "проверить", "убедиться, что...". сущности называем с Большой буквы
- внутри кейса: 1 проверка = 1 результат
- понятность != подробность понятность = информативность
- автоматизация статистики ревью: по статусу, добавили оповещения о смене этапа ревью (реализовано в testrail)
- итоги: ревью улучшает качество, вводить постепенно, улучшать по обратной связи, автоматизировать процесс
- на практике: обычно в течение часа успевают поревьюить полученные на ревью кейсы, ревьюят все у всех - убирает bus factor, в планируемом времени тестирования учитывается; у разрабов есть доступ к тестрейлу, они видят проверки заранее.
Саммери написано по мотивам доклада: На страже качества: test case review. Руслан Остропольский. Comaqa Spring 2019
Ревью тест-кейсов
Тест-кейсы (и чек-листы) можно не только писать, но лучше ещё и ревьюить.
Вот тут можно послушать, как это сделали другие.
Что полезного там услышала я (но вы лучше сами послушайте):
- ревью - это проверка с целью выявления и дальнейшего исправления ошибок, недочётов, расхождения в стиле написания, несоответствий написанного в тест-кейсе/чек-листе и постановленной задаче
- проблемы подхода: самый активный ревьюит всех, быстро все ревью станут успешны, не всё ревьюили, ручной режим
- когда отдавать на ревью? перед началом тестирования. когда тесты готовы, но тестирование не начато
- кто ревьюит? дежурный, закрепленная пара, любой по очереди
- что отдавать? кейсы по багам, новый функционал, регресс
- что не отдавать? самое простое
- что смотреть? заголовок, описание задачи, комментарии, коммиты
- полнота покрытия/избыточность. проблемы: пропускали много негативных сценариев, учтены ли все зависимости, наличие лишних проверок
- нужны регламент и проверка оформления
- 2 цели хорошего тест-кейса: 1. определить, что ПО соответствует требованиям 2. выявить ситуации, когда ПО ведёт себя нежелательным образом
- заголовки: отвечает на вопрос, что проверяем? не использовать лишние слова "проверить", "убедиться, что...". сущности называем с Большой буквы
- внутри кейса: 1 проверка = 1 результат
- понятность != подробность понятность = информативность
- автоматизация статистики ревью: по статусу, добавили оповещения о смене этапа ревью (реализовано в testrail)
- итоги: ревью улучшает качество, вводить постепенно, улучшать по обратной связи, автоматизировать процесс
- на практике: обычно в течение часа успевают поревьюить полученные на ревью кейсы, ревьюят все у всех - убирает bus factor, в планируемом времени тестирования учитывается; у разрабов есть доступ к тестрейлу, они видят проверки заранее.
Саммери написано по мотивам доклада: На страже качества: test case review. Руслан Остропольский. Comaqa Spring 2019
🍄 Чтобы было удобнее тут ориентироваться, ловите хэштеги:
#devtools - девтулзы в различных браузерах (не только Хром)
#charles
#proxyman
#postman
#плагины
#инструменты - про все инструменты, которые могут помочь с тестированием
#git
#sql
#confluence
#тест_дизайн
#стратегия_тестирования
#артефакты - баг-репорты, тест-кейсы, чек-листы, тест-планы и прочая писанина
#познавательно_развлекательное
#почитать - статьи и книги про тестирование
#англ - на английском
#devtools - девтулзы в различных браузерах (не только Хром)
#charles
#proxyman
#postman
#плагины
#инструменты - про все инструменты, которые могут помочь с тестированием
#git
#sql
#confluence
#тест_дизайн
#стратегия_тестирования
#артефакты - баг-репорты, тест-кейсы, чек-листы, тест-планы и прочая писанина
#познавательно_развлекательное
#почитать - статьи и книги про тестирование
#англ - на английском
#тест_дизайн #стратегия_тестирования
Тестовые туры
Я уже писала про то, что начинать тестировать фичи с исследовательского тестирования считаю оч полезным.
Но иногда возникают вопросы "а с чего начать?", "а как не скатиться в детальные проверки всего?", "как не растянуть исследовательское тестирование на неделю?", "как не перейти на ad hoc?". Для меня ответом являются тестовые туры.
Но их же оч много, скажете вы. В связи с этим, вслед за статьёй, предлагаю взять несколько стандартных и понятных туров и начать с них:
The Money Tour - проверить то, за что пользователь платит деньги (что в этой фиче для клиента самое ценное?).
The All-Nighter Tour - некоторые баги воспроизводятся, когда приложение работает долгое время. Протухающие токены, приостановка запросов при длительном бездействии пользака - это всё тут.
The Saboteur Tour - ломайте приложение всеми возможными способами.
Intellectual Tour - "хитросделанные" сценарии. Из серии "откройте в двух соседних вкладках пеймент формы, оплатите, разлогиньтесь, оплатите на второй". Тут очень важно понимать, насколько такие сценарии реальны и опасны.
Garbage Collector Tour - "поднимаем каждую бумажку и открываем каждую дверцу", т.е. протыкиваем кнопки, инпуты, чек-боксы, открываем дропдауны и тд. Детальное тестирование каждого элемента тут не проводим.
Obsessive Compulsive Tour - каждое действие повторяем несколько раз. Например, при оплате тыкаем кнопку оплаты несколько раз, часто такое приводит к повторным списаниям.
Выбор конкретных туров для фичи зависит от самой фичи. Например, если её работа никак не связана с длительностью использования, то вряд ли есть смысл в The All-Nighter Tour.
А ещё больше всяких разных сценариев можно найти тут.
Тестовые туры
Я уже писала про то, что начинать тестировать фичи с исследовательского тестирования считаю оч полезным.
Но иногда возникают вопросы "а с чего начать?", "а как не скатиться в детальные проверки всего?", "как не растянуть исследовательское тестирование на неделю?", "как не перейти на ad hoc?". Для меня ответом являются тестовые туры.
Но их же оч много, скажете вы. В связи с этим, вслед за статьёй, предлагаю взять несколько стандартных и понятных туров и начать с них:
The Money Tour - проверить то, за что пользователь платит деньги (что в этой фиче для клиента самое ценное?).
The All-Nighter Tour - некоторые баги воспроизводятся, когда приложение работает долгое время. Протухающие токены, приостановка запросов при длительном бездействии пользака - это всё тут.
The Saboteur Tour - ломайте приложение всеми возможными способами.
Intellectual Tour - "хитросделанные" сценарии. Из серии "откройте в двух соседних вкладках пеймент формы, оплатите, разлогиньтесь, оплатите на второй". Тут очень важно понимать, насколько такие сценарии реальны и опасны.
Garbage Collector Tour - "поднимаем каждую бумажку и открываем каждую дверцу", т.е. протыкиваем кнопки, инпуты, чек-боксы, открываем дропдауны и тд. Детальное тестирование каждого элемента тут не проводим.
Obsessive Compulsive Tour - каждое действие повторяем несколько раз. Например, при оплате тыкаем кнопку оплаты несколько раз, часто такое приводит к повторным списаниям.
Выбор конкретных туров для фичи зависит от самой фичи. Например, если её работа никак не связана с длительностью использования, то вряд ли есть смысл в The All-Nighter Tour.
А ещё больше всяких разных сценариев можно найти тут.
#тест_дизайн #стратегия_тестирования
Что стоит (и нет) указывать в комментарии к задаче?
Недавно обсуждали, что стоит (не стоит и когда) указывать в комментариях к задачам. Возможно, кому-то пригодится (не принимать за конечную истину, а лишь как отправную точку для раздумий).
Итак, что стоит/не стоит писать в комментах к задачам по итогам выполненного тестирования:
1) если есть TMS и там есть пройденный тест-ран, то прикладываем ссылку на него. Если есть только кейсы/сьюты, то ссылку на них. Важно: ссылка должна быть постоянной, а источник долговечным.
2) если проведённые проверки есть только в голове/на бумажке, то можно указать в следующем формате.
Проверено:
- валидация (пустота, невалидная почта, валидная и тд)
- вёрстка на соответствие макетам
- ...
3) тестовые данные: если есть тестовые данные, на которых проверялась задача (кейсы/скрипты/запросы), то их тоже лучше приложить (так будет проще пройти аналогичные шаги тому, кто придёт читать коммент)
4) крайне не рекомендую писать что-то вроде "протестировано в соответствии с требованиями", это ничего не говорит о проведённом тестировании.
5) если есть примеры комментариев коллег, то лучше с ними ознакомиться, и/или спросить у лида (местного мудреца), как принято/ожидается
6) когда задача в проде, хорошо бы писать об этом в коммент что-то вроде "проверено на проде" и, например, прикладывать тестовый аккаунт, на котором проведены проверки, и/или скрин новой кнопки/ссылки.
Зачем это всё делать?
Когда что-то (всё) сломается, будет трудно вспомнить, проверялось ли это, на каком кейсе, с какими данными. Если в комменте это будет описано, будет легче сориентироваться.
Кроме того, рано или поздно фичу захотят переделать/доделать/выпилить, а может по ней понадобится провести регресс, и тогда можно будет взять старые проверки/данные и доработать их, а не писать с нуля.
Как ускорить данный процесс?
Можно записывать проверки/данные/скрипты в комментарий по ходу выполнения тестирования.
А можно завести шаблон и дополнять его лишь специфичными для данной задачи фрагментами.
Что стоит (и нет) указывать в комментарии к задаче?
Недавно обсуждали, что стоит (не стоит и когда) указывать в комментариях к задачам. Возможно, кому-то пригодится (не принимать за конечную истину, а лишь как отправную точку для раздумий).
Итак, что стоит/не стоит писать в комментах к задачам по итогам выполненного тестирования:
1) если есть TMS и там есть пройденный тест-ран, то прикладываем ссылку на него. Если есть только кейсы/сьюты, то ссылку на них. Важно: ссылка должна быть постоянной, а источник долговечным.
2) если проведённые проверки есть только в голове/на бумажке, то можно указать в следующем формате.
Проверено:
- валидация (пустота, невалидная почта, валидная и тд)
- вёрстка на соответствие макетам
- ...
3) тестовые данные: если есть тестовые данные, на которых проверялась задача (кейсы/скрипты/запросы), то их тоже лучше приложить (так будет проще пройти аналогичные шаги тому, кто придёт читать коммент)
4) крайне не рекомендую писать что-то вроде "протестировано в соответствии с требованиями", это ничего не говорит о проведённом тестировании.
5) если есть примеры комментариев коллег, то лучше с ними ознакомиться, и/или спросить у лида (местного мудреца), как принято/ожидается
6) когда задача в проде, хорошо бы писать об этом в коммент что-то вроде "проверено на проде" и, например, прикладывать тестовый аккаунт, на котором проведены проверки, и/или скрин новой кнопки/ссылки.
Зачем это всё делать?
Когда что-то (всё) сломается, будет трудно вспомнить, проверялось ли это, на каком кейсе, с какими данными. Если в комменте это будет описано, будет легче сориентироваться.
Кроме того, рано или поздно фичу захотят переделать/доделать/выпилить, а может по ней понадобится провести регресс, и тогда можно будет взять старые проверки/данные и доработать их, а не писать с нуля.
Как ускорить данный процесс?
Можно записывать проверки/данные/скрипты в комментарий по ходу выполнения тестирования.
А можно завести шаблон и дополнять его лишь специфичными для данной задачи фрагментами.