7 СЕРВИСОВ ДЛЯ РАБОТЫ С ТЕКСТАМИ

Заимствовано отсюда:
http://www.edutainme.ru/post/apps-text/

Писать тексты не так-то просто, особенно если тебя не одарили врожденной грамотностью, а вдобавок подстерегает боязнь чистого листа. В новой подборке Edutainme – добродушные роботы, которые бесплатно проверяют орфографию, пунктуацию и даже стиль.

Орфограммка

  • Орфограммка
    Орфограммка
Одно дело – просто подчеркнуть опечатки, другое – проверить орфографию, грамматику, пунктуацию и стилистику. В Новосибирском Академгородке придумали робота нового поколения: онлайн-сервис Орфограммка за несколько минут анализирует текст, выделяет ошибки и дает объяснения со ссылками на нужный параграф учебника. Кроме того, программа проверяет курсовые и дипломные работы на соответствие требованиям ГОСТа, а в библиотеке есть подробный раздел с рекомендациями по оформлению. Документы с исправлениями можно смотреть прямо на сайте или загрузить на компьютер и открыть в Word.

Grammar.ly

Grammar.ly, англоговорящий брат Орфограммки, проделывает почти все те же самые операции, но с текстами на другом языке. Сервис умеет исправлять грамматические ошибки, помогает следить за правописанием и предлагает более удачные синонимы. Для работы нужно просто зарегистрироваться на сайте (например, через соцсети) и загрузить готовые работы. Если установить расширение в браузер, Grammar.ly будет подчеркивать сомнительные места даже в ваших письмах или постах. Как отмечают сами создатели, сервис способен найти в 10 раз больше ошибок и неточностей, чем обычный текстовый редактор.

Главред

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

Test the Text

Test The Text – более простая программка для проверки текстов в информационном стиле. Сервис выделяет в тексте слова нехарактерные для информационного стиля и объясняет что с ними делать. Как и Главред, программа умеет искать в материалах «стоп-слова».

Антиплагиат

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

Readability.io

Сервис Readability.io проверяет читаемость русских текстов: можно вставить в форму любую статью или ссылку и получить оценку по шкале. Результат выдается в баллах или в их пересчете на приблизительный возраст аудитории: «7-9 класс; 12-14 лет», «10-11 класс; 15-16 лет», «1-3 курсы ВУЗа; 17-19 лет», «4-6 курсы ВУЗа; 20-22 лет» и «Аспирантура, второе высшее образование, PhD». Кроме того, инструмент считает число знаков, процент сложных слов и другие количественные показатели.

Hemingway

  • Hemingway
    Hemingway
Англоязычный сервис предлагает писать как Хемингуэй – четко, коротко и по делу. Hemingway помогает обработать тексты на английском так, чтобы они стали более удобными для чтения. Можно, например, подобрать материал по сложности для любого класса. Зачеркивать программа ничего не будет, просто бережно выделит цветом: желтым - предложения, которые нужно укоротить, красным - нечитаемые фразы с нагромождением придаточных, сиреневым - сложные слова, зеленым - выражения в пассивном залоге. Кстати, по некоторым пунктам Hemingway сам предложит варианты для замены. По итогам проверки выставляется оценка по десятибалльной шкале.

Ошибокнет.ru – сообщество живых корректоров проверит ваши тексты на грамотность

Взято здесь:
https://te-st.ru/2015/09/16/oshiboknet-ru/


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

Ошибокнет.ru – новый веб-сервис проверит любые тексты на грамотность в течение 24 часов. А на полученные от проверки средства поддержит создание социальных IT сервисов и приложений для благотворительных организаций.

Поделитесь этим сервисом с друзьями

Ошибокнет.ru – сообщество живых корректоров проверит ваши тексты на грамотность
Отчеты, письма, пособия, книги, руководства – все проверяется живыми корректорами, которые объединились в сообщество на сайте oshiboknet.ru и проверяют работы на грамотность по строгим правилам русского языка.
Сервис обещает проверить любой документ в течении 24 часов. Но как правило, небольшие документы проверяются быстрее.
Работа с сервисом проста. Сайт минималистичен и на нем ничто не отвлекает внимания от отправки текста на проверку. Заполняете короткую форму, прикрепляете документ с текстом для проверки. И все. Оплата производится в любой удобной форме – цифровыми деньгами или с помощью карточки.
Ошибокнет.ru – сообщество живых корректоров проверит ваши тексты на грамотность
Фрагмент сайта http://oshiboknet.ru
Проверенный текст будет отправлен вам на указанные при заказе e-mail.
Сервис не только проверит ваши документы. На полученные доходы авторы проекта поддерживают разработку веб-сервисов и мобильных приложений для благотворительных и общественных организаций.

Сервис корректорской проверки текстов Ошибок нет.

Как аналитику писать документы, которые потом читает тестировщик?

Статья подготовлена по результатам Мирового кафе на встрече наших замечательных выпускников! Некоторые из них уже успели поработать тестировщиками, некоторые только столкнулись с тестированием документации на практике.

Что же интересного мы выявили в ходе деловой игры?

1) Документы должны быть

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

К обязательным документам, понятным разработчикам и тестировщикам, отнесли:
 -  Documents flow (от PM к ВА)
 -  Possible cases (от ВА к QA)
 -  Прототип (с текстовым описанием функций и элементов)
 -  Глоссарий

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

2) Документы должны быть актуальны

В целом, документы должны быть актуальными. И это, как оказалось, на практике серьезная проблема.

Проблема состоит из нескольких частей.

2.1) Часто требования и ограничения возникают в беседах (телефон, skype, email, разные чаты). Но не переносятся в документацию (или переносятся с запозданием).

В итоге - документацию не читают (ведь в ней все равно неполная и недостоверная информация). Проще додумать или напрямую спросить ВА.
В итоге - ВА тратит тучу времени на объяснения, выдает информацию, иногда несогласованную, неполную, обрывочную.

Было предложено несколько разных вариантов выхода из проблемы:
 - запретить любые утверждения и принятия решений вне документации (оставить только email для подтверждения изменений и информирования);

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

 - ВА оперативно (по ходу беседы) вносить изменения в документацию: создавать резервную копию, вносить отметки с выделением маркерами или документировать в электронном Блокноте (потом из него проще скопировать документ, перенести сведения в основную версию требований и решений).


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

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

Для тех, кто сталкивается с подобными проблемами, было предложено следующее:
 - "мапинг" изменений документов (актуальный документ, навигатор по актуальным документам проекта)

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

 - делить проект на небольшие части и отдавать в тестирование (как правило в маленьком кусочке изменений происходит немного, их проще отследить)

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

3) Соблюдать требования к требованиям

Это простое утверждение тестировщики скромно повторили несколько раз. В частности указали, что "понятно" слово весьма относительное.

Сюда же снова добавился Глоссарий. Как оказалось, говорим на одном языке, но одинаковые слова понимаем по-разному. А также в среде разработчиков и тестировщиков есть ряд "зарезервированных" слов. Без дополнительных пояснений, эти слова тестировщик поймет так, как привык понимать, а не как ожидает ВА.

4) Общаться с тестировщиком 

Удивительное открытие: есть команды, где общение тестировщика и ВА происходит в конце проекта (когда всё, аут, проект провален или тестировщик не может понять, то ли сделал разработчик, что хотелось Заказчику, или намудрил).

При неполных требованиях (или простом игнорировании документации из-за п.2), тестировщик и разработчик становятся перед выбором:
 - делать, как понял, и сэкономить время и силы;
 - отправить документы на доработку и, возможно, сорвать сроки проекта;
 - устно уточнить, что нужно делать, и, возможно, получить потом расхождение документов и результата.

Ребята посоветовали сделать следующее:
 - при наличии второго ВА в компании, дать ему прочесть документацию и показать прототип (чтобы был "свежий" "незамыленный" взгляд на проект);

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

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

5) На запросы тестировщика к ВА нужно реагировать молниеносно

Тестировщику часто не остается времени на доскональное изучение документации (если она сложная, не имеет удобных для тестировщика cases). Просто потому, что ему приходит документ уже тогда, когда сроки "горят" и нужно срочно проверять и сдавать Заказчику продукт. Любые баги, выявленные тестировщиком, часто оттягивают сдачу проекта и даже, бывает, раздражают команду.

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

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

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


Ребята, если есть еще что ценного добавить, пишите :)
Еще раз благодарим за интересную встречу!