2013-10-20
Cамотренинг по автоматизации. Подходы: объектный.
Объектный подход.
ООП уже многие годы стандарт де-факто в разработке ПО. Объекты в программировании служат отражением объектов реального мира, а объекты в автоматизации отражают элементы тестируемого приложения: формы, страницы, т.е. части графического интерфейса. Однако "отражают" означает не только наличие таких же полей, но предоставление неких сервисных методов, например logout(). "This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place."
Пример: класс LoginPage моделирует(отражает) страницу входа в систему. Соответственно этот класс должен обеспечивать доступ к полям "имя" и "пароль" или даже предоставлять метод по авторизации в системе. Очень наглядный пример объектного подхода это шаблон "PageObject".
"За".
+ Структурированное и расширяемое решение, что ведёт к снижению стоимости поддержки;
+ Все "плюшки" ООП.
"Против".
- Надо знать и применять ООП;
- Чрезмерное увлечение программированием может привести к "коду ради кода".
2013-10-15
Yet another traffic lights - CI status indicator.
2013-03-23
Cамотренинг по автоматизации. Подходы: ключесловный и поведенческий(keyword-driven, behaviour-driven).
Тесты на основе ключевых слов(кeyword-driven).
Практически всегда автоматизированное тестирование это штука дорогая и сложная, а "экономика должна быть экономной". Автотесты на основе ключеслов (keyword-driven testing) это как раз та техника, что призвана снизить стоимость за счёт привлечения к написанию собственно тестов технически слабоподготовленных лиц разнообразной национальности.
Ключесловное тестирование (называемое також "чрезтабличное", "на основе действий", "деесловное"(table-driven, action-driven or action-word)) очень схоже с тестированием управляемым данными, является в какой-то степени его продолжением и расширением. Основная идея - разделить автоматизацию тестирования на две неравные по времени и стоимости части: написание собственно тестов в виде последовательности ключевых действий и реализацию(создание инфраструктуры).
Написание тестов подразумевает описание тестовых сценариев в табличном виде, где каждая строка состоит из ключевого слова описывающего некое действие и каких-либо данных. Возможны, естественно, вариации: нет данных, добавлены комментарии и пр.. Такую задачу могут выполнять технически слабые специалисты, знакомые с предметной областью тестируемого приложения. За счёт этого написание собственно тестов становится относительно недорогим.
Создание инфраструктуры заключается в
1. написании реальных классов, методов, скриптов тестирующих приложение;
2. трансляции ключевых слов из просто текста в вызовы тех методов, запуск нужных скриптов и т.д. .
Эта часть подхода требует технически грамотных (читаем "дорогих") сотрудников. Зато таких "грамотеев" нужно много меньше, чем писателей тестов.
Таким образом получаются две условно независимые части: тесты в виде таблиц и код, который собственно "нажимает кнопки" и проверяет результаты.
Тесты на основе поведений (behaviour-driven).
Дальнейшее развитие это техники, которое всё больше набирает популярность это тестирование на основе поведений(behaviour-driven). Всё практически то же самое, только тесты не только в виде таблиц, но и в виде структурированного текста. Например:
Test Case
Valid Login
Step
Given login page is open
When valid username and password are inserted
and credentials are submitted
Then welcome page should be open [9]
Given, When, Then - фактически зарезервированные слова, определяющие структуру, описывающее то самое поведение.
Тесты теперь могут писать вообще кто угодно, например аналитики, главное чтоб соблюдали структуру.
"За".
+ Можно быстро создавать новые тесты(при наличии инфраструктуры);
+ "Не-технари" могу писать тесты, что снижает стоимость и теоретически ускоряет процесс;
+ благодаря популярности этих подходов появилось приличное количество практически готовых к немедленному использованию инструментов. С ними создание инфраструктуры упрощается на порядки.
"Против".
- Создание гибких решений может быть трудным;
- Те немногие технари, пишущие инфраструктуру, должны быть достаточно сильны в программировании.
С помощью чего?
1. FitNesse - уже ветеран ключесловного тестирования от ветеранов же тестирования и разработки.
2. RobotFramework - каркас для ключесловного, на основе поведений и т.д. тестирования. Рождён на сумрачных берегах не менее снежной Финляндии.
3. Cucumber - подозрительно пафосный каркас для тестов на основе поведений.
4. JBehave - ещё один поведенческий каркас.
Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects
[8] В поисках качества кода: Знакомство с Behavior Driven Development (BDD)
[9] Пример поведенческого теста: http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html?r=2.7.6#different-test-case-styles
Содержание.
2013-03-18
Cамотренинг по автоматизации. Подходы: данные правят(data-driven).
Это обобщённое описание, т.е. на шаге 4 ожидаемой может быть домашняя страница(если имя/пароль были верными) или страница с ошибкой, если имя/пароль были неверны. Шаги одни и те же, только вводимые символы и ожидаемые результаты разные - разница в данных. Логично разделить код (шаги) и данные, чтобы можно было один и тот же тестовый скрипт прогонять для разных входных и выходных значений - тест будет управляться данными.
Для таких тестов (data-driven tests) обычно существует некий источник данных (Экселевский файл, БД, CSV-шный файл и т.д.) и параметризованный скрипт/тест, которому данные из источника "скармливаются" строчка за строчкой (по факту 1 строка = 1 тест ).
Самый яркий пример использования этой техник - в модульной тестировании. Например, есть метод, делящий одно число на другое. Модульный тест рационально написать "ведомым", подавая на вход 3 значения: делитель, делимое и ожидаемый результат.
"За".
+ один и тот же код для множества случаев - легко поддерживать;
+ легко изменить(увеличить или уменьшить) покрытие, надо лишь изменить таблицу с данными, обычно не требуется даже компилировать код тестов.
"Против".
- прогон лишь части всего набора данных может быть невозможен;
- обнаружение конкретной строчки, приводящей к ошибке может быть трудным;
С помощью чего?
1. TestNG и JUnit: http://blog.varunin.com/2011/10/data-driven-testing-using-junit-and.html
2. NUnit начиная с версии 2.5.0 поддерживает некоторое количество полезных атрибутов: http://nunit.org/index.php?p=testCaseSource&r=2.6.1
Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects
Содержание.
Cамотренинг по автоматизации. Подходы: функциональная декомпозиция.
Функциональная декомпозиция.
"Термин 'функциональная декомпозиция' описывает процесс выделения модульных компонентов(функций определяемых пользователем) при котором авто-тесты создаются преимущественно комбинированием уже существующих компонентов."[1].
Функции-модули это строительные блоки, "кирпичики", из которых собираются новые тесты. Т.е. не стоит в каждый скрипт, класс и т.д. "напихивать" один и тот же код(да, да, любимый шаблон разработки "скопировать/вставить" использовать вредно). А стоит выделять переиспользуемые функции/процедуры(registerAUser(), login()) которые напрямую соотносятся с функциями тестируемого приложения. А уже авто-тесты будут состоять из вызовов этих процедур в требуемой последовательности.
- Утилитные(вспомогательные) функции/скрипты - повторно используемые подпроцедуры, используемые более чем одним авто-тестом. Например процедура login() скорее всего будет использоваться большинством тестов;
- Навигационные скрипты - набор подпроцедур вида “goToPage/Screen()”. По большому счёту это те же вспомогательные функции, только узкоспециализированные;
- Процедуры проверки(верификации) - содержат код для проверки(верификации) бизнес-логики;
- "Водители"(Driver scripts) - вспомогательные функции, которые не относятся к тестированию напрямую, но обеспечивают собственно прогон тестов: инициализацию, выполнение пред- и пост-условий, выполнение других скриптов/шагов в требуемом порядке.
"За" и "против":
+ повторно используемый код;
+ независимость скриптов (сами тесты независимы и не переиспользуются).
- технически сложнее, чем "записал/выполнил";
- смешиваются данные и код.
Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects
Содержание.
2013-03-09
Cамотренинг по автоматизации. Подходы, техники и каркасы.
Подходы.
Два основных глобальных подхода к автоматизации тестирования:
- На уровне кода/Программного интерфейса приложения (Code-driven/API based);
- Посредством ГИП (GUI-based).
Первое (тестирование на уровне кода) подразумевает использование того или иного вида доступа к классам, модулям, сервисам и т.д. для ввода исходных данных и получения результатов с последующей их проверкой. Примером может служить модульное тестирование (unit testing), позволяющее "определить работают ли различные части исходного кода так как ожидается в различных условиях.". Другой пример - тестирование веб-сервисов путём вызова открыто доступных методов этих сервисов.
Второе (тестирование через графический интерфейс) предполагает имитирование действий пользователя в максимально возможной степени. Что означает, что тест нажимает кнопки, щелкает кнопками мыши, вводит что-то с клавиатуры, т.е. генерирует такие же (в идеальном случае) системные события, что и реальный пользователь. Действия эти приводят к изменениям в пользовательском интерфейсе (тестируемое приложение реагирует на входные воздействия). Изменения затем проверяются тестом(соответствуют ли ожиданиям). Например: "появляется ли сообщение об ошибке при вводе неверных значений?".
Автоматизированное тестирование через графический интерфейс часто "легколомаемо" и чувствительно к изменениям в самом графическом интерфейсе. Недостаточно хорошо спроектированный тест может потребовать полной переделки при казалось бы пустяковом изменении названия кнопки.
Каркасы.
В историческом разрезе множество вещей в технике проходит путь от хаоса к какой-либо системности. Разработка ПО идёт той же тропой - от хаоса первых попыток к более-менее логически и практически обусловленной системе. Каркасы (frameworks) широко применяются в разработке собственно ПО и имеет смысл следовать этому же подходу в автоматизации тестирования, так как по сути последняя есть разработка программного обеспечения особого сорта. Что такое "каркас"? Согласно педевикии: “...a software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API).”. Далее, "каркас автоматизированного тестирования это набор концепций, предположений и инструментов который обеспечивает поддержку автоматизированного тестирования.". Также, каркас в автоматизации позволяет ускорить и/или упростить разработку новых тестов и поддержание уже существующих в актуальном состоянии.
Каракас должен обеспечивать:
- механизм для организации и структурирования тестов: пред- и пост-условия, зависимости и прочее;
- механизм контроля тестируемого приложения или механизм доступа к этому приложению (запуск, останов и т.д.);
- механизм выполнения самих тестов;
- механизм проверки полученных результатов;
- механизм логирования/журналирования и генерации отчётов.
Известны несколько методологий автоматизации тестирования и построения каркаса:
- Запись-и-Воспроизведение (Record & Playback) - НИКОГДА не используйте на реальных проектах;
- Функциональная декомпозиция (или Разбиение на модули);
- На основе данных (Data-driven);
- На основе ключевых слов (Keyword-driven);
- Объектный подход;
- На основе моделей;
- Смешанный подход.
Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects
Содержание.
2013-03-03
Cамотренинг по автоматизации. Что, почему, зачем, где, когда и как.
Что.
Автоматизация тестирования это "...использование ПО для управления выполнением тестов, сравнения ожидаемых и реальных результатов, создания предусловий для выполнения тестов, а также других действий связанных с контролем и отчётностью по тестированию.". На практике об автоматизации часто говорится в узком смысле - автоматизация ручных функциональных тестовых случаев, что обычно означает использование ГИП (графического интерфейса пользователя), т.е. автоматизированные тесты имитируют действия пользователя путём генерирования таких событий как движение "мышью", нажатия, щелчки, ввод с клавиатуры. В широком смысле автоматизация тестирования включает такие вещи как например генерация ежедневных отчётов, рассылка их по электронной почте, наполнение БД тестовыми данными и т.д. .
Некоторые разновидности автоматизации:
Почему.
Будем честны - люди ленивы и склонны становится всё менее внимательными при выполнении одних и тех же действий изо дня в день, снова и снова. Таким образом идея сделать некоего "робота", который будет делать всю нудную и рутинную работу вместо человека - такая идея звучит очень и очень привлекательно.
Зачем.
Успешная автоматизация тестирования решает сразу несколько задач:
- Уменьшение времени на тестирование (чаще всего речь идёт о регрессионном тестировании);
- Делает тестирование более заметным и прозрачным (например можно легко получать замечательно оформленные отчёты по прогону тестов каждый день и таким образом постоянно "держать руку на пульсе" качества продукта);
- Увеличение тестового покрытия (авто-тесты позволяют покрыть большее количество комбинаций за то же время и с возможностью одновременно отслеживать такие параметры как потребление памяти, процессорного времени, дискового пространства и пр.);
- Тестировщики уделяют больше времени сложным сценариям и исследовательскому тестированию;
- Исключение некоторых человеческих ошибок при прогоне тестов.
Где и когда.
Об автоматизации стоит задуматься когда:
- процесс тестирования включает строго определённые последовательности часто повторяемых действий, которые выполняются шаг за шагом без особых изменений и при этом требуют относительно много времени;
- у вас огромное количество сборок и версий для тестирования (например планируется выпустить 64 версии в течении 10 лет);
- необходимо протестировать/изучить поведение системы при определённых условиях(например при 100 000 активных пользовательских сессиях);
- у вас нет ГИПа.
Автоматизация может принести нулевой результат когда:
- процессы тестирования неопределенны и/или хаотичны;
- бизнес-логика недостаточно определена или выверена;
- ГИП нестабилен;
- набор функций системы ещё не определён(разработка прототипа);
- лица принимающие финансово-технические решения до конца не понимают структуру стоимости автоматизации и какие ресурсы для неё необходимы.
Как.
По определению, автоматизация тестирования производится с помощью ПО. Это могут быть внешние библиотеки, компоненты и инструменты или инструменты разработанные внутри проекта или фирмы. Говоря о непосредственно тестировании в рамках автоматизации, существует два больших класса: специализированные инструменты (такие как QTP, TestComplete, LoadRunner) и коммерческие или открытокодовые библиотеки/компоненты(xUnit-ы, Selenium, JMeter). Каждый из классов имеет свои "за" и "против".
Специализированные инструменты:
- в большинстве случаев крайне дороги;
- требуют специального обучения;
- разработанные тесты может быть трудно поддерживать и развивать из-за отсутствия у всех членов команды нужного опыта (например разработчикам может быть трудно быстро начать писать авто-тесты по причине незнакомого языка, среды и т.д.);
- возможны трудности в обновлении/расширении функций таких инструментов (отдельные лицензии например).
+ обычно отличная тех. поддержка со стороны производителя;
+ обученным людям необязательно иметь навыки программирования.
Библиотеки/компоненты:
- требуют навыков программирования;
- документация часто плохая или отсутствует;
+ очень расширяемы - почти всегда можно дописать недостающую функциональность самостоятельно;
+ могут использоваться практически всеми членами проектной команды;
+ часто с открытым кодом и бесплатны.
Ссылки:
[1] http://en.wikipedia.org/wiki/Automated_testing
[2] http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
[3] http://openquality.ru/software-testing/automation.php
[4] http://automated-testing.info/
Содержание.
Вводная. Самотренинг по автоматизации функционального тестирования.
1. Cамотренинг по автоматизации. Что, почему, зачем, где, когда и как.
2. Cамотренинг по автоматизации. Подходы, техники и каркасы.
3. Cамотренинг по автоматизации. Подходы: функциональная декомпозиция.
4. Cамотренинг по автоматизации. Подходы: данные правят(data-driven).
5. Cамотренинг по автоматизации. Подходы: ключесловный и поведенческий(keyword-driven, behaviour-driven).
6. Cамотренинг по автоматизации. Подходы: объектный.
7. Самотренинг по автоматизации. Подходы: Модельный и гибридный.
8. Практические заметки.
9. Типовая структура проекта.
10. Самотренинг по автоматизации. Локаторы элементов.
11. Самотренинг по автоматизации. Введение в Луний.
12. Практические задания.
О чём и для чего?
Число желающих что-нибудь заавтоматизировать в тестировании растёт, а с чего начать и куда копать чаще всего неясно. Огромное количество платных тренингов порождает проблему выбора и не даёт уверенности в результатах. Данный самотренинг это набор "выучись сам" - желающему предоставляются набор материалов для самостоятельного изучения, выполнения заданий и т.д. . Никаких разжёвывания и сверх-детальных объяснений, расчёт на инженерный подход, способность мыслить и самообучаться. Ожидается, что после выучивания инженер сможет участвовать в реальном проекте по автоматизации тестирования в качестве младшего специалиста.
Самотренинг состоит из краткой теоретической части(конспекты), набора указаний для практики, а также простого веб-приложения для тестирования и зародыша проекта автоматизации на базе Selenium 2.0 WebDriver.
Материалы(как текст, так и исходный код) предоставляются "как есть" и бесплатно для личного обучения. При цитировании или использовании в любых проектах по разработке ПО (открытых, коммерческих, некоммерческих и т.д.) - имейте совесть и ставьте ссылки на источник. Если есть желание попользоваться материалами как-то ещё или улучшить код - добро пожаловать в комментарии.
Предположения.
Изучающий - человек, желающий узнать что-то новое и готовый использовать данные материалы для этого.
Предполагается, что изучающий имеет/знает:
- 2-4 года опыта в ручном тестировании ПО;
- принципы и концепции тестирования;
- знания и опыт применения базовых техник тест-дизайна (классы эквивалентности, граничные значения и т.д.);
- начальные навыки в программировании. Желательно ООП.
Ссылки.
Исходники проекта автотестов +"варка" тестируемого приложения
[1] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1093&Itemid=76
2012-01-03
Об английском и переписке или с какой буквы писать слово F... .
В целом — без английского тяжко, ибо простого человеческого мата буржуи не понимают, а уж до смысловых тонкостей перлов навроде двойного утверждения «да конечно» им так же далече как нам до всестороннего вникания в «He's a bit of a Battle-cruiser» или до «marriage» в контексте ремонта двигателей. К тому же, плохо разговаривающих детей считают недоразвитыми, а бекающие и мекающие взрослые вызывают внутреннее отторжение и сомнение в их компетентности.
И вот возникает стандартная ситуация, характерная не только для ИТ и английского, но и для деловой переписки вообще — молодой специалист становится чуть менее молодым и ему доверяют (хруст клавиш в фоне) написание письма с просьбой или вопросом кому-то «на той стороне». И вот он, краса и надежда половины проекта, пишет и, промурыжив всё это дело четыре часа, отсылает... А ответа что-то нету, а и есть, так не прочесть. Ибо чаще всего первые полмиллиона писем содержат либо все, либо хоть одну из стандартных «отморочек» (см. ниже). Редко какую птицу действительно учат в школе или высшем учебном техникуме писать деловые письма, задавать вопросы так, чтобы получать внятные ответы и просто извергать из себя более пяти связных предложений. И уж совсем редчайшие соколы долетают до прочтения книжек-методичек о вкусной и здоровой переписке.
Книг, книжек, статей о том как и что надо писать, какие типичные ошибки, как их избегать и заводить друзей - великое множество есть, горка ссылок приведена в конце. Здесь же хочется в 7,4 слова перечислить то, с чем сталкивался «в живую».
Отморочки:
Нет темы письма. В пылу работы бывает. Хуже когда каждое второе письмо такое. В результате «Входящие» всех людей в переписке забиваются письмами-безымянками и их потомками «На: », «Re: » и «Fwd: ». Пара-тройка таких подборок, и быстро что-то найти, глянув на тему, уже невозможно. Зато вполне вероятно сломать чей-то автофильтр. Главное, чтобы не было другого фильтра, отправляющего безымянки в корзину;
В теле письма вписано find enclosed («всё как учили в той синей книжке»), да вот только никакого прицепа нет, забыли прикрепить. Хотя, если пользоваться почтой от Корпорации Добра и не выпендриваясь писать see attached, то при отправке такого письма выскочит диаложек «А не забыли ли вы чего прицепить, уважаемый?»;
В связи с повышением градуса интимности уже можно писать вместо «Dear Sir» — «Dear Bill» или даже «Hello Billy». Можно-то можно, да вот предательская клавиша не нажалась и вышло «Hell Bil». Мелочь, а человек может не понять;
Письмо написано, но ни «Hello» в начале, ни «Bill», а прямо сразу — стремительным домкратом слова и выражения изливаются на ошарашенного Билли. Пожалейте его, ему ж потом вам отвечать;
Hello bill. Неуважительно как-то. А вдруг он комплексует из-за малого роста, так к нему теперь ещё и со строчной буквы обращаются;
В копии письма(писем) никто не поставлен или поставлены совсем не те люди. Скользкая ситуация. Наличие правильных людей в копии повышает шансы на успех как с письмом, так и при последующем разбирательстве. Неправильные люди в копии могут загубить всё и всех;
Отличное письмо, толково описана проблема, подробнейше выписаны варианты, слог изыскан до жути. Только забыто одно предложение, одна строчка — к чему это всё? Какие действия ожидаются от получателя? Что сделать, кому помочь, причём он тут вообще?
Не письмо — роман. Три страницы убористого шрифта, море деталей, океан пояснений. Смысла только нет, получатель теряется в этом накате слов, в этом сумбуре.
И т.д. и т.п. Читайте книжки, там ещё и не такое написано.
А как можно было бы:
Составьте хороший шаблон письма: с «Dear/Hello» в начале, «Best Regards» и т.д. в конце. А ещё лучше — несколько шаблонов, в зависимости от уровня формальности письма или дня недели;
Перечитывайте письма перед отправкой, стараясь представить себя на месте получателя: всё ли чётко, все ли детали есть, ясно ли, что требуется сделать?
Перечитывая — замечайте ошибки, описки, которые не заметила проверка орфографии (doe вместо does и т.д.);
Хорошо если почтовая система позволяет отменить отправку письма в течение 30-60 секунд. Чтоб было ещё лучше - перечитывайте письма сразу после отправки;
Заведите привычку проверять основные пункты перед отправкой письма: получатели, тема, прицепы, имена. Со временем такая проверка должна стать рефлекторной;
Если проблема сложная, слов много, то смело бейте на части, используйте нумерованные списки, выделение жирным, разбивку на абзацы. Никто никогда даже не попытается вникнуть в смысл «Анны Карениной» набранной в один абзац;
Меньше сложных предложений и слов XIII-го века. Короче фразы, слова из справочника по допросу пленных — и вас поймут с большей вероятностью;
Знайте разницу между «Could you please» и «Can you please». Знайте и пользуйтесь;
Прочитайте в конце концов 2 (две) книжки по деловой переписке. По мере прочтения — используйте!
Ссылки:
Карепина Саша. «Искусство делового письма». Изд. Манн, Иванов и Фербер. http://mann-ivanov-ferber.ru/books/mif/idp/
Emmerson P. «E-mail English». Изд. Macmillan.
2011-11-14
Предрелизное.
Распевать на мотив известной песни.
Релиз нечаянно нагрянет, когда его совсем не ждёшь,
И каждый вечер резко станет,
Так утомительно хорош,
Что ты поёшь:
Баги, как вам не хочется покоя,
Баги, как может так паршиво быть,
Баги, не убежать от геморроя,
Спасибо багги, что в предрелизе так нескучно жить!





