Home

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

Вступление

Тестировщики для контроля качества продуктов применяют средства автоматизации, анализаторы сетевого трафика, инструменты отладки… а также головной мозг для выполнения, так называемого, «ручного тестирования». Данное словосочетание неудачно по той причине, что процесс тестирования невозможно свести только к мышечной активности. Тем более руки в этом процессе задействованы незначительно. А вот от работы нервной системы в целом и зависит результат. В данной статье я постараюсь раскрыть то, как можно применять знания о высшей нервной деятельности человека для успешного решения задач по тестированию.

Автор: Алан Ричардсон (Alan Richardson)
Оригинал статьи
Перевод: Ольга Алифанова

Краткое содержание: вариация – полезная тактика для тестирования. Зачастую это случайная вариация внутри класса эквивалентности. Варьировать можно также и при исследовательском тестировании. Подумайте над варьированием порядка, данных, состояний, времени.

Наткнулся на ситуацию, похожую на потенциальный баг обработки хэштегов LinkedIn, и это заставило меня задуматься, как бы тут пригодилась тактика вариации.

Автор: Ян Бин (Iain Bean)
Оригинал статьи
Перевод: Ольга Алифанова

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

Начнем с начала: выберите сайт для тестирования. Если у вас есть свой сайт, или сайт вашей компании – можете использовать их, а если вы ищете что-то совсем ужасное – множество примеров можно найти на Awwwards и Product Hunt.

Автор: Мануэль Матюшович (Manuel Matuzovic)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Допустим, вам удалось набрать 100 в аудите доступности Lighthouse. Это необязательно значит, что у вашего сайта хорошая доступность – вы просто заложили основу для настоящего тестирования. Следующий шаг – убрать мышь и пройтись по вашему сайту при помощи клавиатуры.

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

Это третья часть из цикла статей, в котором я отвечу на самые распространенные вопросы о тестировании согласно результатам автодополнения в поисковых системах.

В этой статье я отвечу на вопрос "Когда должно начинаться тестирование?" (и связанный с ним вопрос "Когда тестировать?").

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

Это вторая часть из цикла статей, в котором я отвечу на самые распространенные вопросы о тестировании согласно результатам автодополнения в поисковых системах.

В этот раз я отвечу на вопрос "Как тестирование влияет на качество ПО?" (и связанный с ним вопрос, "Как связаны тестирование и качество ПО?").

Тут надо сделать отступление и прояснить, что я имею в виду под "качеством" при помощи определения от Джерри Вайнберга и Кема Кейнера:

Качество – это ценность для значимого человека.

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

Это первая часть из цикла статей, в котором я отвечу на самые распространенные вопросы о тестировании согласно результатам автодополнения в поисковых системах.

Первый по популярности запрос – "Почему тестирование значимо?" (вместе с похожими запросами "почему тестирование необходимо", "почему тестирование нужно", "почему тестирование важно для разработки ПО", и "почему тестирование значимо в жизненном цикле разработки ПО").

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

Год назад произошло интересное – придумали необычный способ тестировать наш продукт. Подход повлиял на все процессы в компании и сказался на росте клиентской базы. Сейчас проведено уже более 50 тестов, и есть чем поделиться.

Метод скорее относится к инструментам Customer Development и затягивает в анализ всю команду разработки. Каждый тест с интересом смотрят и программисты, и дизайнеры. Мгновенно разгораются споры и обсуждения, как пофиксить баг или UX-проблему.

График роста числа активных пользователей системы в день

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

Автор: Пол Симан (PaulSeaman)
Оригинал статьи
Перевод: Ольга Алифанова

В моей прошлой статье "Не все могут тестировать" я отметил важность способности рассказывать о своем тестировании. Если вы хотите, чтобы люди понимали вклад тестировщика и ценность, которую привносят в разработку хорошие тестировщики и тестирования, вам нужно уметь рассказывать ясные, основанные на фактах, увлекательные истории. Если вы хотите возвысить тестирование в восприятии далеких от него людей, убрать слово "ручное" из термина "ручное тестирование", провести четкую грань между тестированием и автоматизацией тестирования – рассказывайте соответствующие истории. Рассказывайте истории с внятным контекстом, внятными сообщениями, истории, нацеленные на вашу аудиторию (да, это значит, что одна и та же история не сработает на разные аудитории). Возможно, кто-то удивится, что я использую термин "истории" вместо того, чтобы просто сказать "расскажите", и это логичный вопрос. Использование этого термина – намеренный выбор, потому что истории – хорошие истории – это мощный способ коммуникации с людьми. См., например, отрывок из Harvard Business Publishing.

Автор: Татьяна Рыжова — преподаватель английского языка в компании Лаборатория Качества, тренер курса Английский язык для тестировщиков.

Каждый тестировщик сталкивается с формулировками, которые по своей длине могут состязаться с железнодорожным составом. Чего только стоят «check storage procedures», «passenger view function».

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

В чем же все-таки тайна этих фраз, где есть только существительные? Этим я поделюсь в своей статье на примерах терминов, которые используют тестировщики в своей повседневной деятельности.