Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Раньше я выступал на конференциях. Для конференции HUSTEF 2020 я собирался сделать доклад "Что не так с ручным тестированием". В эпоху COVID все мы превратились в кинорежиссеров, поэтому вместо доклада я записал видео.
После того, как мой доклад был предложен и одобрен, я долго размышлял, в чем же на самом деле проблема. Люди годами говорят о "ручном" и "автоматизированном" тестировании. В чем проблема? Какой смысл это обсуждать? Я обдумал эти вопросы, и в видео есть ряд объяснений важности этой темы с моей точки зрения. Мне помогали талантливый музыкант, значимый социолог, проницательный журналист и системный мыслитель, уважаемый редактор и поэт, а также ряд тестировщиков.
Тренды – явление зыбкое, особенно если речь идет о разработке и тестировании программного обеспечения. В условиях быстрого развития трудно давать далекоидущие предсказания, поэтому важно хотя бы попытаться зафиксировать то, что происходит прямо сейчас. Это поможет определить, какие практики и методологии будут востребованы завтра. Опираясь на последние отчеты и опросы, рассказываем о наиболее актуальной статистике для вас и вашей команды QA.
Кому будет полезно: QA-лидам, тест-дизайнерам, тест-менеджерам, другим неравнодушным.
Говоря о качестве, обычно имеют ввиду некое соответствие требованиям. Часто под требованиями подразумевают те, что явно выдвинул заказчик, аналитик или кто-то другой, кто ставит задачи. Хуже, если они трактуются как неоспариваемые, и это неявно ведёт к самоцели — удовлетворить требования заказчика. Это часто происходит в аутсорсе, и такой фокус внимания негативно влияет на конечный результат — то, что видят и с чем работают пользователи.
Мы в SmartHead тоже занимаемся заказной разработкой, и я предлагаю рассматривать качество шире. Это не только про соответствие явно озвученным требованиям, но и про сами требования. Про дополнение явных требований своими, ориентированными не на потребности заказчика, а на удобство конечного пользователя. Пользовательский опыт, юзабилити, тексты в интерфейсе, отзывчивость, скорость релизов, их соответствие ожиданиям — всё это тоже относится к качеству.
Качество — это про «сделать классно» с точки зрения многих сторон: разработки, заказчика и конечного пользователя.
Как это сделать? Сложно. Начать стоит с формирования mindset на «встроенное» качество. Расскажу о принципах, которые могут помочь в этом.
Прежде всего, Impact Analysis (импакт анализ) - это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты.
Затронутые области требуют большего внимания во время проведения регрессионного тестирования.
Отмечу сразу, чтобы не пугать QA: импакт анализ не есть "чтение кода". Он включает в себя и иные способы исследования.
Тестировщики для контроля качества продуктов применяют средства автоматизации, анализаторы сетевого трафика, инструменты отладки… а также головной мозг для выполнения, так называемого, «ручного тестирования». Данное словосочетание неудачно по той причине, что процесс тестирования невозможно свести только к мышечной активности. Тем более руки в этом процессе задействованы незначительно. А вот от работы нервной системы в целом и зависит результат. В данной статье я постараюсь раскрыть то, как можно применять знания о высшей нервной деятельности человека для успешного решения задач по тестированию.
Автор: Алан Ричардсон (Alan Richardson) Оригинал статьи Перевод: Ольга Алифанова
Краткое содержание: вариация – полезная тактика для тестирования. Зачастую это случайная вариация внутри класса эквивалентности. Варьировать можно также и при исследовательском тестировании. Подумайте над варьированием порядка, данных, состояний, времени.
Наткнулся на ситуацию, похожую на потенциальный баг обработки хэштегов LinkedIn, и это заставило меня задуматься, как бы тут пригодилась тактика вариации.
Автор: Ян Бин (Iain Bean) Оригинал статьи Перевод: Ольга Алифанова
Выявление (и исправление) проблем доступности – важная часть навыков любого фронтэнд-разработчика, но зачастую сложно отделить полезные инструменты и техники от менее полезных. К тому же существует множество ложных представлений, поэтому я решил написать статью о тех инструментах и техниках, которыми пользуюсь сам, тестируя веб-доступность. Дабы извлечь из статьи максимум пользы, проделайте все это самостоятельно.
Начнем с начала: выберите сайт для тестирования. Если у вас есть свой сайт, или сайт вашей компании – можете использовать их, а если вы ищете что-то совсем ужасное – множество примеров можно найти на Awwwards и Product Hunt.
Автор: Мануэль Матюшович (Manuel Matuzovic) Оригинал статьи Перевод: Ольга Алифанова
Я работаю на компанию около года, и многое тут отличается от фриланса. В частности, мне регулярно нужно оценивать доступность различных сторонних инструментов. На полный аудит обычно нет времени, поэтому мне нужно получить хорошее представление о качестве продукта как можно быстрее.
Допустим, вам удалось набрать 100 в аудите доступности Lighthouse. Это необязательно значит, что у вашего сайта хорошая доступность – вы просто заложили основу для настоящего тестирования. Следующий шаг – убрать мышь и пройтись по вашему сайту при помощи клавиатуры.
Автор: Ли Хокинс (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Это третья часть из цикла статей, в котором я отвечу на самые распространенные вопросы о тестировании согласно результатам автодополнения в поисковых системах.
В этой статье я отвечу на вопрос "Когда должно начинаться тестирование?" (и связанный с ним вопрос "Когда тестировать?").
