Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Недавно я встречалась с коллегами, намеренными улучшить наши практики непрерывной поставки. Они размышляли над способами измерения прогресса автоматизации, и одним из первых предложений было измерение покрытия кода.
"Нет", сказала я. "Измерение покрытия кода ничем не поможет, потому что оно не говорит о том, хороши ли наши тесты – оно только показывает, что наши тесты затрагивают определенные части кода".
Следующим предложением был подсчет строк кода. "Нет", сказала я. "Это тоже не поможет. Количество страниц в книге ничего не говорит о ее качестве, а количество строк кода ничего не говорит о качестве тестов".
"ОК", сказали они. "Как насчет количества тестов? Ну уж это-то покажет наш прогресс".
"Нет, и это не поможет", ответила я. "У вас могут быть сотни тестов, и каждый из них может быть ненадежным, или тестировать не то, что нужно".
Тут они спросили "Так как же тогда выглядит ХОРОШИЙ тест?" Ответ на этот вопрос – тема этой статьи! Ниже – шесть признаков хорошего автотеста.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Web-доступность означает простоту использования сайта и его понимания людьми, имеющими визуальные, аудиальные, физические или когнитивные особенности. Знаете ли вы, что существуют специальные гайдлайны доступности для сайтов? Эти гайдлайны называются "Гайдлайны доступности веб-контента", или WCAG. Они были созданы Web Accessibility Initiative, частью Консорциума World Wide Web (W3C). Эти гайдлайны можно увидеть в этом кратком руководстве.
Тестировать можно по-разному, и у каждого инженера со временем вырабатываются свои предпочтения и стиль работы. Однако в рабочее время иногда требуется применять определенный вид тестирования, поэтому всегда полезно разобраться, к чему именно у вас лежит душа. А если и не лежит, то познакомиться с чем-то новым. Поэтому сегодня мы поговорим об исследовательском тестировании, а также его отличии от скриптового.
Что же такое исследовательское тестирование? Это вид тестирования, при котором мы одновременно и тестируем, и придумываем тест, опираясь на поведение продукта.
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Видеоверсию моих ответов можно посмотреть и послушать тут.
Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.
Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Краткое содержание: код Cypress выполняется блоками. Чтобы использовать данные оттуда, можно использовать команду then(), mocha-алиасы, объекты окна или переменные окружения. Я создал паттерн с использованием переменных окружения, и покажу его во второй части этой статьи. Мое приложение и этот паттерн можно найти на GitHub. Для обсуждения присоединяйтесь к серверу Discord.
Дело обстоит так: в начале вашего теста вы вызываете конечную точку API. Она даст вам ответ, который нужно использовать в ходе теста. Что вам делать?
Автор: Ли Хокинс (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Это восьмая часть серии статей, в которой я отвечаю на самые распространенные вопросы о тестировании, согласно результатам автодополнения поисковых систем.
В этой статье я отвечаю на вопрос, можно ли научиться тестировать самостоятельно (и связанные с ним вопросы, можно ли выучить тестирование онлайн, и каждый ли может научиться тестировать).
Автор: Пол Гриззафи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
В рекламе 70-х мальчик спросил мудрую сову, сколько раз надо лизнуть леденец с начинкой, чтобы добраться до сердцевины. Сова – очевидно, тестировщик, размышляла, сколько раз для этого понадобится; в юмористическом повороте сюжета она решила, что три. Но на третьем "лизе" она хрустнула конфеткой и съела начинку.
Как и этот леденец, тест-автоматизация имеет сердцевину, только состоящую из трех частей – стимул, ответ и некоторое количество проверок. Вот что вам нужно понимать о каждой из них, чтобы создавать стеки и смежные стеки, добавляющие гибкости вашей автоматизации.
Docker — это контейнер для приложения. В котором уже всё настроено — и операционная система, и сервер приложения, и вся инфраструктура. Бери да используй!
Докер активно используют разработчики и тестировщики для проверки приложений. Его используют и для поставок клиентам готового продукта. В нем поднимают приложения, гоняют автотесты... А также упоминают в вакансиях и спрашивают на собеседованиях =))
Поэтому в этой статье я расскажу на простом языке и с картиночками, что это вообще такое. А за кровавыми техническими подробностями идите в раздел «статьи и видео по теме».
База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов... Вы делаете заказ, а система сохраняет ваши данные в базе.
В этот статье я на простых примерах расскажу, что такое база данных и как она выглядит. А потом поясню некоторые термины из конкретной (реляционной) базы. Те, с которыми вы почти наверняка столкнетесь на работу.
Статья рассчитана на начинающих тестировщиков или аналитиков, то есть тех, кто будет работать с базой, но не на супер-глубоком уровне. Она для тех, кто только входит в мир ИТ, и многого не знает. Она объясняет, что это за звено в клиент-серверной архитектуре такое, и зачем оно нужно.
