Поиск неправильных ссылок на сайтах

   Посещая различные сайты я постоянно сталкиваюсь с тем, что на них встречаются устаревшие ссылки, ведущие на уже несуществующие страницы, либо на страницы, возвращающие различные ошибки, например, "ошибку № 500" (она же Internal Server Error, внутренняя ошибка сервера) - я как раз описывал пример недавно.

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

   Иногда даже приходится сталкиваться с просьбой "проверить быстренько новую версию сайта" - когда заходишь на новую демо версию сайта и через 10 секунд уже идёшь заводить баги.

   После очередного такого запроса я решил написать скрипт, который будет такое "тестирование" делать автоматически и для любого сайта. Посидев пол часа над ним месяца два назад я понял что работать будет, но публиковать код ещё рано. Так и оставил его лежать у себя на рабочей машинке до сегодняшнего дня. Сегодня доработал этот скрипт, и пусть он ещё и не во всём хорош и есть что туда добавить (например, авторизацию) - в остальном он уже работает и может быть применён для "тестирования" сайтов.

   Вот ссылка на скрипт (осторожно, Python): ссылка на github.

QA аура: ещё один баг в коллекцию

Только сегодня узнал о новом портале для обучения (https://stepic.org/), куда можно отправлять свои собственные курсы - утром ещё работал их сайт, а вечером уже возвращает 500 код, хорошо хоть без трейсов.

Ok Google, where is Hangouts OnAir?

  До недавнего времени у Google был отличный сервис онлайн трансляций, доступный по этому адресу:

http://www.google.com/%2B/learnmore/hangouts/onair.html

  Я даже готовил статью в блог чтобы о нём рассказать.

  Это очень удобный сервис для проведения презентаций, когда количество участников велико и обычные сервисы для проведения конференций не справляются. Во время презентации все участники могут видеть трансляцию с веб камеры или рабочего стола в формате HD, с неплохим качеством звука, после трансляции запись всего митинга/презентации будет сразу же доступна на youtube в виде ролика, так же в формате HD.

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

  Теперь можно воспользоваться чем-то очень похожим на Hangouts On Air, это "живые" трансляции на YouTube:

https://www.youtube.com/live_dashboard

  Сервис классный и спасибо Google что они делают такие продукты бесплатными. Но можно было бы сделать перенаправление со старой ссылки на новую или хотя бы разместить страницу-заглушку, сообщающую о том, что сервис был перенесён на YouTube.

Автоматизированная проверка синтаксиса, грамматики и сложности предложений

Можно проверять свой "английский" перед отправкой важных писем на этих ресурсах:

http://spellcheckplus.com/
http://www.hemingwayapp.com/
https://www.languagetool.org/ru/

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

С одной стороны, пост не совсем о тестировании, с другой стороны - почему же нет? Часто за собой замечаю опечатки в русской и английской письменной речи - то поторопился и не проверил, то вообще нажал не на ту кнопку, а то и не знаешь каких-нибудь правил (над этим, конечно, работаем, тут синтаксическими проверками не отделаешься). И сегодня у нас есть множество сервисов проверки орфографии, авто-дополнения текста, даже набора текста голосом (что меня не перестает поражать) - что, несомненно, помогает делать меньше ошибок и писать быстрее. Одновременно с этим речь людей упрощается (здесь, безусловно, нельзя винить только эру компьютеров и виртуальное общение) и допущение ошибок не считается чем-то вопиющим - люди не делают над собой больших усилий (в частности, замечаю за собой и обобщаю на всех) чтобы исключить ошибки из своей устной и письменной речи.

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

Вот ещё один пример. Есть некий ресурс в Интернете, посвящённый самообразованию и онлайн обучению, авторы которого очень стараются и предоставляют реально полезный материал, причём часть этого материала публикуется бесплатно. Они постоянно допускают ошибки и опечатки в этих материалах. При чём регулярно - это может быть какая-то статья на их сайте, или PDF версия какой-то полезной лекции или книги, или рассылка в электронной почте. Мы с ними на эту тему уже не раз списывались и я им посоветовал:
1. Проверять орфографию автоматическими программами, например, встроенными проверками в Google Docs или Microsoft Word, а так же встроенными плагинами для браузера.
2. Прочитывать текст несколько раз перед отправкой.
3. Добавить возможность на сайте выделять фрагменты текста и отправлять отчёт об ошибке если ошибка всё равно была обнаружена пользователями (т.к. до этого приходилось искать адрес их электронной почты и писать письмо со скриншотами).

Ошибок стало меньше, но они не ушли ;)

Я иногда задумываюсь над такими вещами и вот какая мысль приходит мне в голову в этом случае и не дает покоя: а что если бы человек, печатающий для них тексты, обладал бы высоким уровнем грамотности, перепроверял каждое написанное предложение и не допускал бы ни единой ошибки (конечно, на уровне русского языка, а не излагаемого материала)? Что если бы они не допускали ошибок? Совсем.
Тогда бы и все средства проверок были бы не нужны. И ошибок бы не было.
Эта мысль не дает мне покоя :)

Как не надо проводить нагрузочное тестирование

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

Прежде, чем мы начнём рассматривать ошибки, нам нужно определиться с тем что такое нагрузочное тестирование и зачем оно нужно. Я всегда задаю себе вопросы, прежде чем начать что-то проверять - а какой вид тестирования я хочу провести? Что именно я хочу проверить? Что должно быть результатом этой работы?

Ошибка первая: Непонимание цели

И вот уже на этом шаге многие, даже опытные инженеры, ошибаются, просто пропуская его и торопясь выбрать/попробовать инструмент и "нагрузить" своё приложение.

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

Совет №1:

Прежде, чем мы приступим к нагрузочному тестированию, задайте себе вопрос - какая у нас цель? Зачем мы проводим нагрузочное тестирование?

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

Когда нужна тестовая документация?

Сегодня утром пересматривал ссылки с интересными заголовками на http://mmm.software-testing.ru/library/testing и наткнулся на статью.

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

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

Другой пример - на проектах, где из тестовой документации есть только чек листы, каждый инженер трактует тест кейсы "по-своему" (потому что нет описания того что именно надо проверить, есть только название фичи), в результате чего нет полной уверенности, что тест кейс будет выполнен так, как себе представлял тест аналитик, который его написал (даже если тест аналитиком был один из инженеров этой же команды). И от версии к версии у нас нет повторяемости проводимых тестовых испытаний, как нет и видения что на самом деле было проверено.

Так какая тестовая документация нужна и почему?

Размышления о миссии QA инженера

  Недавно мы сидели с коллегами вечером в каком-то ресторанчике в Париже и обсуждали миссию DevOps и QA инженеров на проектах.

  "QA должен так описать багу, чтобы, прочитав это описание, разработчик не только сразу понял в чем проблема, но и захотел это тут же исправить" (С) Я.

  Чтобы так описывать баги, QA инженер должен отлично понимать как работает проект, чтобы разработчик проникся описанной проблемой, а не тратил время и силы на "перевод" с языка QA на язык разработчика и многочасовые попытки воспроизвести описанную проблему.

  Миссия QA инженера на проекте - это обеспечить создание качественного программного обеспечения, всеми средствами. Сюда относится и наличие правильного CI/CD, и создание особой культуры разработки (как, например, "не релизим в пятницу вечером" или "изменения в коде должны пройти ревью как минимум двух инженеров кроме самого автора кода") и многое другое, но вот о чем многие из нас частенько забывают - QA должен понимать как работает проект и каждый его компонент изнутри и как это выглядит для обычного пользователя снаружи. Эти знания нужны нам, чтобы создавать адекватные тесты и понимать результаты проводимого тестирования, эти знания нужны нам чтобы с легкостью общаться с командой разработчиков, менеджерами и командой поддержки.