Home

Автор: Боков Максим
Оригинальная публикация

Мы, команда автоматизации Страхового Дома ВСК, подготовили небольшой рассказ о нашей инфраструктуре. Эта статья может быть входной точкой для специалистов, желающих внедрить автотестирование у себя в компании. Расскажем, какие системы, паттерны и фреймворки можно использовать, а также как интегрировать это в релизный цикл. Материал подойдёт как юным автоматизаторам, так и тем, кто желает поближе познакомиться с темой. Большое внимание уделим не только абстрактным вопросам, но и организации кода проекта. Добро пожаловать под кат.

Автор: Лобанов Святослав (Менеджер бета-тестирования IVI.ru)

Снижаем нагрузку на отдел тестирования, расширяем парк устройств и географию тестов, не разоряясь при этом.

Меня зовут Святослав, в IVI я отвечаю за бета-тестирование. Хочу рассказать вам про то, как пользователи могут сделать мир лучше.

У нас в компании есть практика random coffee: сотрудники разных отделов получают приглашение и встречаются в офисе или в Slack, заваривают себе капучино или ванильный макиато и рассказывают друг другу, чем они занимаются. Так мы создаём взаимосвязи и делимся знаниями. И на таких встречах, услышав про бета-тестирование, мне часто задают вопросы: «В смысле? Как? Почему?» Так за многими выпитыми чашками кофе и родился подробный рассказ о нашей работе, про которую, оказывается, не знает никто, кроме нашего клуба бета-тестировщиков и сотрудников тех. отдела. Усаживайтесь поудобнее, наливайте чай, кофе, смузи или апероль шприц.

Автор: Адам Найт (Adam Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Большинство занятых в разработке ПО рано или поздно сталкиваются с гнетущим страхом, что все вокруг работают гораздо лучше. Очень легко попасть в ловушку убеждения, что все остальные тщательно внедряют последние методы и техники, а вы топчетесь на месте, сражаясь с рутинными задачами, отнимающими все ваше время. Spotify – отличный пример компании, чьи статьи и контент рассказывают о райски отлаженных гибких процессах, в то время как донесения из окопов гласят о куда более практичных методах, а также всем знакомых проблемах, с которыми внедрение этих методов сталкивается.

Наиболее эффективная, по моему мнению, тактика работы с риском подобной паранойи – это общение с коллегами. Если вы соберетесь вместе в одной комнате с теми, кто занимает равную вам позицию, то быстро узнаете, что ваши сложности не хуже, чем у других, и мало кто может позволить себе роскошь применения идеалистических книжных и маркетинговых техник. Давным-давно я ощутил это на себе во время конференции по продуктовому маркетингу в ходе обсуждения тестирования гипотез.

Автор Нина Агеева – тренер курса “Первый Онлайн ИНститут Тестировщиков”  (ПОИНТ).

Сегодня поговорим с вами про исследовательское тестирование. Причём про такое исследование продукта, которое никто не назовёт обезьяньей работой.

Бытует мнение, что исследовательское тестирование – удел молодых специалистов, якобы думать там совсем не нужно, тыкай себе хаотично всё подряд – авось и баги найдутся. Ан нет. Исследовательское тестирование – это целая наука со своими методологиями и техниками.

Давайте обратимся к теории, что же такое исследовательское тестирование? Что значит “мы исследуем”? Исследовать – значит изучать, знакомиться, смотреть на продукт и на то, как он будет реагировать на ваши действия.

Исследовательское тестирование – это одновременное создание тестов, их прохождение и корректировка в зависимости от поведения вашего  продукта.

Авторы: Мария Гуцук (Mariia Hutsuk), Шиваморти Бос (Sivamoorthy Bose)
Оригинал статьи
Перевод: Ольга Алифанова

Исследовательское тестирование – это подход к тестированию, при котором тестировщики динамически проектируют и выполняют тесты на основании своих знаний, исследования тест-объекта и результатов предыдущих тестов (согласно глоссарию ISTQB).

Исследовательское тестирование часто путают с ad-hoc тестированием, которое проводится по запросу без заранее составленных тест-кейсов, и манки-тестированием, которое заключается в рандомных действиях пользователя. Исследовательское тестирование – это изучение продукта путем небольших экспериментов и адаптация новых экспериментов в ходе тест-сессии. Этот тип тестирования отлично подходит для Agile– у него такая же логика, как и у Agile-экспериментов.

Автор: Симкин Алексей, Lead QA Enginner

Сегодня я хочу осветить и обсудить тему локализации (L10N) и интернационализации (I18N). В интернете и, в том числе и на Хабре уже есть полезные и интересные статьи, но часто они дают более-менее общую информацию о подходах, без углубленной информации о том, что и как можно проверить. Я бы хотел с вами поделиться своим опытом, просуммировать кое что из статей, которые вы можете найти в интернете, а также постараюсь описать большой checklist с самыми распространёнными кейсами как для локализации, так и для интернационализации. В чеклистах я буду стараться упоминать только те проверки, которые вы можете сделать сами, без (глубоких) знаний языка новой для вас локали.

Автор: Майкл Болтон (MichaelBolton)
Оригинал статьи
Перевод: Ольга Алифанова

Тестировщик из "Agile"-команды жалуется на объем регрессионного тестирования, который, по его словам, должен выполняться в конце каждого скрипта.

Почему ряд компаний, разрабатывающих ПО, так зациклен на регрессионном тестировании? Нет, не почему они это делают (это может быть разумным), а почему они зациклены на нем. У меня есть теория на этот счет.

Очевидно, что любое изменение в продукте или системе несет риск проблем, которые могут в какой-то степени ухудшить качество. Это регресс – откат назад к предположительно менее продвинутому состоянию. Регресс – антоним прогресса.

Изменения несут риск регресса, поэтому разумно сосредоточить часть тестирования на этом риске. Но разве тестирование – это безотказный, надежный способ решить вопрос с риском регресса?

Оригинальная публикация

Когда мы говорим о веб-валидаторах и оптимизации сайта под них, мы чаще всего имеем ввиду Lighthouse/Pagespeed Insights от Google, который давно стал де-факто стандартом для оценки производительности сайта. Кто-то стремится к заветным 100 баллам даже на прототипах и шаблонных приложениях в две кнопки, кто-то в шутку создает абсолютно недоступный сайт с идеальным рейтингом, но для всех фронтендеров лайтхаус предоставляет вменяемую, хоть и довольно поверхностную, аналитику производительности сайта и поиск бутылочных горлышек. Однако скорость загрузки — лишь один из множества параметров, которые стоит проверять на своём сайте, и для большинства других есть свои валидаторы и скоринговые алгоритмы. Мы рассмотрим инструменты для каждого из значимых направлений и составим список, по которому стоит прогонять свой сайт, чтобы в дальнейшем не отлавливать проблемы вручную.

Автор: Мэтт Хойссер (Matt Heusser)
Оригинал статьи
Перевод: Ольга Алифанова

"Не можем ли мы в сообществе разделять функциональное/исследовательское/юзабилити-тестирование и регрессионные проверки?"

(твиттер Мэтта Хойссера)

Недавно я побывал на SauceCon, ежегодной конференции Sauce Labs. Sauce предоставляет платформу (и облачные мобильные устройства при необходимости) для запуска скриптов Selenium. Слушая, как докладчик говорил о "тестировании", не проводя черту между регрессом и функциональным тестированием, я написал об этом твит.

Знаю, знаю, есть множество типов тестирования, а не только эти два, как мог я забыть про тестирование производительности, безопасности, и так далее, и тому подобное! Вот он, ужасный я, "всего лишь" упоминающий "функциональное" тестирование. Ладно, хорошо, но я так-то не об этом.

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

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

В популярной культуре США снежный человек – это легендарное, скрытное создание, изредка наблюдаемое  на тихоокеанском северо-западе. В мире разработки ПО у нас есть своя версия снежного человека – раздражающие и иногда катастрофичные баги, которые трудно воспроизвести.