2013-03-18

Cамотренинг по автоматизации. Подходы: данные правят(data-driven).


Тесты управляемые данными (data-driven).
Представьте, что пишете тест для странички входа в систему. Какие шаги в этом тесте? Скорее всего что-то в духе:
1. Open Login Page;     
2. Type in %username% in the @usernamField     
3. Type in %password% in the @passwordField     
4. {Verify} Current page is the expected one.

Это обобщённое описание, т.е. на шаге 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

ОбКа

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

Об английском и переписке или с какой буквы писать слово F... .

В силу неизвестного списка исторических причин английский в ИТ востребован практически до затёртости и обветшалости. Документация, переписка, голосовое общение и даже (кто бы мог такое вообразить в 1930-х) написание исходного кода в подавляющем большинстве случаев происходит с использованием ещё одного варианта бритско-норманно-саксонского суржика. Желаете быть начальником — учите английский, разговаривайте на английском, улыбайтесь по-английски и вообще, всячески упражняйте, тренируйте и совершенствуйте язык, дабы был он в меру шершавым и без меры выносливым. Но даже при наличии отсутствия тяги к заветному портфельчику и скамеечке для поплёвывания вниз — английский нужен, например, для выражения благодарности индийскому псевдо-коллеге на языке оригинала. Более того, английский ещё и помогает добыть и, возможно, усвоить знания, столь необходимые для придания этой благодарности технической весомости и инженерной обоснованности.

В целом — без английского тяжко, ибо простого человеческого мата буржуи не понимают, а уж до смысловых тонкостей перлов навроде двойного утверждения «да конечно» им так же далече как нам до всестороннего вникания в «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 (две) книжки по деловой переписке. По мере прочтения — используйте!


Ссылки:

  1. Карепина Саша. «Искусство делового письма». Изд. Манн, Иванов и Фербер. http://mann-ivanov-ferber.ru/books/mif/idp/

  2. Emmerson P. «E-mail English». Изд. Macmillan.

2011-11-14

Предрелизное.

Распевать на мотив известной песни.


Релиз нечаянно нагрянет, когда его совсем не ждёшь,

И каждый вечер резко станет,

Так утомительно хорош,

Что ты поёшь:

Баги, как вам не хочется покоя,

Баги, как может так паршиво быть,

Баги, не убежать от геморроя,

Спасибо багги, что в предрелизе так нескучно жить!

2010-12-13

О терминологии.

Терминология в тестировщицком деле – вещь спорная, а вопрос больной. Кое-какие вехи есть, только, кто ж их чтит и зачем? Обычная ситуация, когда спор может завести до Зелёных Отрогов-предвестников драки и лишь тогда выясняется, что кричали люди о разных вещах, называли лишь одинаково. Другая сторона – называть одно и то же разными терминами, мало задумываясь о причинах такой разницы. Любимый и ненавидимый пример – автоматические и автоматизированные тесты. Для затравки, Лингво подсказывает:

Автоматический = Самодействующий.

Автоматизированный = Осуществляющийся с помощью автоматов, заменяющих ручной труд.

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

- «автоматические тесты» означает, что код написан и отправлен на сборку в процессе которой как чёртик из коробки выскакивают некие тесты, обладающие собственным разумом (возможно когда-то и созданным человеком), и начинают тестировать этот код по полной, причём как они это делают – фактически известно только им, они сами решают какие где классы эквивалентности, граничные значения, точки ветвлений, сколько каких записей должно быть в БД в данном конкретном случае и т.д. Одним словом – мечта. Нажал кнопку, через час получи распечатку со списком всех дефектов. И всё, и никаких затрат на поддержку в актуальном состоянии (разе что ОЗУ увеличить и НЖМД обновить), никаких упавших по неизвестной причине тестов, никакой головной боли с настройкой окружений и т.д. Ещё раз – мечта. Либо пару тысяч индусов и мешок риса.

- «автоматизированные тесты» - это когда есть код приложения и есть код тестов и кто-то эти тесты наваял бессонными ночами с 08:00 до 17:00. Более того, тесты эти делают одно и то же, реализуют одни и те же сценарии и уж никак не определяют что ввести, куда ввести и какой должен быть результат – всё это определил их создатель. А до этого - разработчик сценариев, аналитик и т.д. (тут речь о ролях, физически это может быть один и тот же сумрачный гений). В итоге внешнее проявлении почти как и в первом случае – нажал кнопку, через час получил список дефектов, только найденных по предопределённым, замороженным сценариям. И никакой мечты, куча времени и ресурсов.

Возможно «автоматические» употребляется вместо «автоматизированные» просто потому, что так немного быстрее произносить. Есть вариант – «авто-тесты» - и коротко и быстро и нет досадной разницы в окончаниях. Только желательно помнить, что «авто-» это в 99,9% случаев «автоматизированные», так же как «Э» в ЭВМ это «электронная», а вовсе не «электрическая».

2010-12-10

Вечный разговор.

- Да мы, да мы такие хорошие, мы всегда пишем красивый код, который компилируется, а вот вы ... .

2009-07-15

"Зоопарковый" Скрам...

...один из видов местной "живности", закономерная мутация в условиях ослабленного контроля и наличия творческих способностей.
Основные особенности: РП нет (как теоритически и не должно быть), где-то там есть висящий вниз головой псевдо-владелец-продукта, команда самоорганизующаяся до жути, чуть ли не читающая мысли друг друга и с минимальной "звездатостью" каждого в ней. Контроль есть, но умышлено ослаблен со стороны всех, аудиторы не бегают с дикими криками "А что это у вас Скрам не по CMMI-N?" и "Какие метрики и где?". И вообще - практически всюду зеленоватый свет, правда без Mac Air каждому. Есть ощущение, что ты в зоопарке по ту сторону ограждения, но еду приносят по расписанию, вольер весь твой, а от тебя требуется производить впечатление.

В довесок ещё кучка тонкостей и оговорок, но это уже детали.