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

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

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 должен понимать как работает проект и каждый его компонент изнутри и как это выглядит для обычного пользователя снаружи. Эти знания нужны нам, чтобы создавать адекватные тесты и понимать результаты проводимого тестирования, эти знания нужны нам чтобы с легкостью общаться с командой разработчиков, менеджерами и командой поддержки.

Баги-рекодсмены

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

Вот, например, недавно обнаружили баг в библиотеке OpenSSL: 

http://mashable.com/2014/04/09/heartbleed-bug-websites-affected

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

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

Но больше интересно как такие баги появляются и как попадают в "продакшн", как становятся частью сервисов, которыми пользуются люди и как и почему их находят и исправляют.

Кроссбраузерное тестирование: бесплатно и быстро

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

Есть множество онлайн-сервисов для кроссбраузерного тестирования веб приложений. Если выбирать из бесплатных, то мне больше всего нравится сервис Modern IE: http://loc.modern.ie/ru

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

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

Партизанский баг

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

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

Всё бы ничего, но это баг на сайте сервиса кроссбраузерного тестирования. И воспроизвёлся он в обычном Firefox 27.0.1.

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