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