Что такое прототип и для чего он нужен?

Я продолжаю цикл "Интересные цитаты из книги Карла Вигерса". Все статьи по книге:
[1] [2] [3] [4]

В последнее время все чаще и чаще речь заходит о так называемых прототипах ПО. Вот и на confetQA (онлайн конференция для тестировщиков) о них говорят. Но что же это все-таки такое - прототипы?

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

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

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

Какие бывают прототипы?

Горизонтальный прототип (Horizontal prototype).

Когда люди говорят "прототип ПО", они обычно имеют в виду именно горизонтальный прототип. предполагаемого интерфейса пользователя. Его также именуют поведенческим прототипом или моделью. Горизонтальным прототип называется потому, что в нем не реализуются все слои архитектуры и нюансы системы, но воплощаются некоторые особенности интерфейса пользователя.

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

Вертикальный прототип (vertical prototype).

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

Одноразовые прототипы.

Прежде чем создать прототип, примите четкое и ясное решение, прекратите ли вы работать с ним после оценки или сделаете его частью выпускаемого продукта. Создайте одноразовый прототип (throwaway prototype), или исследовательский прототип (exploratory prototype), чтобы ответить на вопросы, разрешить неясности и улучшить требования.

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

Эволюционные прототипы.

В отличие от одноразового прототипа, эволюционный прототип (evolution prototype) представляет собой прочный архитектурный "фундамент"для постепенного создания окончательного продукта - по мере прояснения требований. Эволюционное прототипирование - один из компонентов модели спирального цикла разработки ПО.

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

Бумажные и электронные прототипы.

Не всегда для разрешения неопределенностей в требованиях нужен прототип в виде исполняемого кода. Бумажный прототип (paper prototype), иногда его называют низкокачественным прототипом - это дешевый, быстрый и низкотехнологичныйспособ выяснить, как может выглядеть некий фрагмент системы. Он помогает установить, действительно ли пользователи и разработчики одинаково понимают требования. Похожий метод, называемый методом раскадровки (storyboard), показывает предлагаемый интерфейс пользователя, без привлечения пользователей к работе с ним.

Вот такие бывают прототипы. Конечно, на одном только создании прототипа дело не заканчивается, его еще надо оценить, а тут есть свои ловушки и подводные камни... Но тем не менее - чем раньше вы получите feed-back от конечного пользователя, тем больше у вас шансов сделать именно такую систему, которая ему и нужна.

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

Oracle JDBC driver - выделение буферной области под запрос

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

Официальная документация и написанный по ней отзыв.

Документ описывает, например, почему мы вообще "переезжаем" с одной версии Oracle JDBC driver на другую.

The 7.3.4, 8i, and 9i Oracle JDBC drivers used more or less the minimal amount of

memory possible. Unfortunately this resulted in an unacceptable performance penalty.

The drivers were rearchitected in 10g to improve performance. One of the most important

changes in that rearchitecture was how the drivers used memory. The development team

made a specific decision to trade memory footprint for performance. As a result the 10g

drivers were on average about 30% faster than the 9i drivers.

В версиях 7.3.4, 8i и 9i драйвер поглощал больше или меньше минимального числа доступной памяти. Что приводило к плачевным результатам производительности. Однако! В 10 версии разработчики сделали одно очень важное изменение - рефакторинг способо испорльзования памяти драйвером.  Благодаря этому драйвер версии 10g работает на 30% быстрее, чем 9 драйвер! Вы все еще на 9 Oracle JDBC driver? Тогда мы идем к вам!

Что это дает с точки зрения тестирования? Ну да, мало что... Можно, конечно, узнав, что у Заказчика стоит 7-9 версия, попрыгать вокруг с бубном, проверив производительность... Но меня больше заинтересовала другая часть документации.

Как происходит буферизация области для запроса к БД?

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

Each Statement (including PreparedStatement and CallableStatement) holds two

buffers, one byte[] and one char[]. The char[] stores all the row data of character type: CHAR,VARCHAR2, NCHAR, etc. The byte[] stores all the rest. These buffers are allocated when theSQL string is parsed, generally the first time the Statement is executed. The Statement holdsthese two buffers until it is closed

Каждый  Statement захватывает 2 буфера, один byte[], один char[].

• В буфере char[] хранятся все символьные типы - CHAR,  VARCHAR2, NCHAR и прочие.
• В буфере byte[] содержатся все остальные типы.

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

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

The driver also has the fetchSize, the number of rows to retrieve on each fetch. With the size of each

column and the number of rows, the driver can compute the absolute maximum size of the data

returned in a single fetch. That is the size of the buffers.

Some types such as LONG and LONG RAW are too large to store in line in the buffers and are

handled differently. If the query result contains a LONG or LONG RAW, the fetch size is set to

1, which addresses most memory problems as will become clear further on. These types will not

be discussed further.

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

Некоторые типы, такие как LONG - слишком большие для хранения в буффере. Если в запросе есть такой тип, значение fetchSize устанавливается равным 1, но все равно приводит к большим проблемам с памятью. Поэтому такие типы далее не рассматриваются.

И, конечно же, с примерами и цифрами:

Character data is stored in the char[] buffer. Java chars take up two bytes per character. A VARCHAR2(10) column will contain a maximum of ten characters, or ten Java chars or 20 bytes per row. A VARCHAR2(4000) column will take 8K bytes per row. What matters is the defined size of the column, not the size of the actual data. A VARCHAR2(4000) column that contains all NULLs will still take 8K bytes per row. The buffers are allocated before the driver sees the query results so the driver must allocate enough memory for the largest possible result. A column defined as VARCHAR2(4000) can contain up to 4000 characters. The buffer must be allocated large enough to hold 4000 chars, even if the actual result data is not so large.

BFILE, BLOB, and CLOB values are stored as locators. The locators can be up to 4K bytes, so for each BFILE, BLOB, and CLOB column, the byte[] must have at least 4K bytes per row. RAW columns can contain up to 4K bytes. Other types take substantially less. A reasonable approximation is to assume 22 bytes per column per row for all other types.

Example:

CREATE TABLE TAB (ID NUMBER(10), NAME VARCHAR2(40), DOB DATE)

ResultSet r = stmt.executeQuery(“SELECT * FROM TAB”);

When the driver executes the executeQuery method, the database will parse the SQL. The database will report that the result will have three columns: a NUMBER(10), a VARCHAR2(40), and a DATE. The first column needs (approximately) 22 bytes per row. The second column needs 40 chars per row. The third column needs (approximately) 22 bytes per row. So one row needs 22 + (40 * 2) + 22 = 124 bytes per row. Remember that each character needs two bytes.

The default fetchSize is 10 rows, so the driver will allocate a char[] of 10 * 40 = 400 chars (800 bytes) and a byte[] of 10 * (22 + 22) = 440 bytes, total of 1240 bytes. 1240 bytes is not going to cause a memory problem. Some query results are bigger.

In the worst case, consider a query that returns 255 VARCHAR2(4000) columns. Each column takes 8k bytes per row. Times 255 columns is 2040K bytes or 2MB per row. If the fetchSize is set to 1000 rows, then the driver will try to allocate a 2GB char[]. This would be bad.

Вольный перевод:

Символьные значения хранятся в буферной области типа char[]. Колонка типа VARCHAR2(10) может содержать максимум 10 символов, или 10 Java символов, или 20 байт для каждой (!) строчки. Строчек, напомню, ровно столько, сколько указано в настройке fetchSize драйвера. Колонка типа VARCHAR2(4000) занимает уже 8 Кб на каждую строчку!

Ну и самое главное - нас волнует только размер колонки, а размер актуальных данных вообще не колышет. Колонка типа VARCHAR2(4000) может содержать все значения, равные NULL - неважно! Все равно выделяем ей 8 Кб. Буферная область выделяет ДО того, как драйвер увидит результаты запроса. Именно поэтому он должен выделить количество памяти, достаточное для выполнения самого большого запроса.

Это, имхо, самая основная мысль данной статьи. Но едем дальше. Колонка типа VARCHAR2(4000) может содержать до 4000 символов - а значит, буферная область ей выделяется под 4000 символов, даже если реальные данные намного меньше.

BFILE, BLOD, CLOB значения хранятся как локаторы. Локаторы занимают 4 Кб, соответственно, под каждую колонку такого типа выделяет по 4 Кб буферной области на каждую строку. Тип RAW может содержать также до 4 Кб. Другим типам требуется значительно меньше памяти, Разумное приближение - принимать по 22 байта за колонку (в каждой строке) для всех остальных типов.

Пример!

CREATE TABLE TAB (ID NUMBER(10), NAME VARCHAR2(40), DOB DATE)

ResultSet r = stmt.executeQuery(“SELECT * FROM TAB”);

Когда драйвер выполняет executeQuery метод, БД парсит SQL. БД сообщает, что результато запроса являются 3 колонки: NUMBER(10), VARCHAR2(40) и DATE. Для первой колонки необходимо (приблизительно) 22 байта на каждую строчку. Второй колонке необходимо 40 символов на каждую строку (по 2 байта на символ). Третьей колонке необходимо (приблизительно) 22 байта на строчку.

Таким образом, на одну строчку нам необходимо 22 + (40 * 2) + 22 = 124 байта.

Помните, что каждый символ занимает 2 байта! Стандартное значение fetchSize = 10 строк, таким образом, драйвер выделяет для символьной колонки char[] 10 * 40 = 400 символов (800 байт) и для byte[] колонок, которых две - 10 * (22 + 22) = 440 байт, всего 1240 байт.

1240 байт не приводит к проблемам с памятью, правда? Но некоторые результаты запросов побольше.

В худшем случае, представим, что запрос возвращает 255 колонок типа VARCHAR2(4000). Каждая колонка забирает по 8 Кб на строку. На 255 колонок необходимо уже 2040 Кб или же 2 Мб на строку! Если fetchSize = 1000 строк, то драйвер будет пытаться выделить 2 Гб char[]. И ему станет плохо

Что же мы выносим из данной статьи? А то, что следить за размерами БД все-таки стоит. Это тестовые примерчики, на которых мы учимся писать запросы - все такие милые и простые. И БД тестовые у нас маааленькие. А реальные побольше будут.

И когда Заказчик хочет, чтобы у него колонка была рассчитана на 4000 символов по принципу, "ну а на всякий случай!", то, прочитав эту статью, поневоле задумаешься... А так ли уже это просто? А, фигня вопрос - пошел изменил скрипт создания БД и добавил скрипт миграции. Но правда ли все так просто? Может, все-таки стоит выяснить причину, почему Заказчику надо так много места и даже, возможно, убедить его, что и сотни символов будет достаточно?

А еще мне очень нравится вывод, сделанный из вышесказанного:

There are several things a user can do to manage the size of these buffers.

1 Define tables carefully

2 Code queries carefully

3 Set the fetchSize carefully

Чтобы разумно управлять размеров буферной области:

1. Определяйте размеры колонок аккуратно.
2. Кодируйте запросы к БД аккуратно.
3. Устанавливайте fetchSize значение аккуратно.

И будет Вам счастье

Ну а про всякие страшные настройки драйвера аля:

• oracle.jdbc.freeMemoryOnEnterImplicitCache
• oracle.jdbc.maxCachedBufferSize
• oracle.jdbc.useThreadLocalBufferCache
• oracle.jdbc.implicitStatementCacheSize

Советую почитать в блоге Ромы, если не хочется читать в оригинале. В конце концов, это мнение разработчика, что бывает очень и очень полезно узнать
 

Верите ли вы в карму тестировщика?

Как по мне, так никакой кармы не существует. И более того, я также негативно отношусь к распространенной истории "проводил я собеседование... И в итоге взяли мы парня, которые сломал нам email, стол, стул, занавески... Вот с ним мы точно не пропадем, настоящий тестировщик!!!"

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

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

Ну, может, кто-то и скажет спасибо и исправит косяк... Но большинство скажут "нехрен было так делать, сам дурак, деньги не вернем". И... И все :) И сидит себе наш клевый тестировщик в разломанной квартире и продолжает звонить в надежде отремонтировать свои вещи... Бррр, страшная картинка :) В общем, не верю!

Правда, коллеги мои верят... Особенно админ

Вот например, пару дней назад... Но по порядку! Как я уже говорила, я переехала в новый домен. Огребла кое-каких проблем, но вроде уже все хорошо. Было.

В начале недели у меня развалился jboss и, так как thread dump весит приличненько, я положила его в специальную папочку "C:\Share". И убежала - домой, готовиться к выступлению на Auto ConfetQA. Разработчик (Р1) совершенно спокойно открыл мою папку (мы уже больше месяца как в разных доменах, он в старом, я в новом), забрал оттуда дамп, отписался мне по результатам анализа...

Потом мы повторили эту процедуру в среду. А в четверг я уже переключилась на другую задачу. Нашла багу. Обсудили с разработчицей (Р2), решили подебажить у меня. Настроили немного другой уровень логирования и рестартанули сервер. Посмотрели... Стало понятно, что на на быструю руку мы эту проблему не решим. А, чтобы разработчице не пришлось собирать билд, а потом перенастраивать там логирование - я положила свой war-файл в небезизвестную папочку "C:\Share".

Увы и ах. Доступа у разработчицы к ней не было. Тогда она пошарила мне свою - без пароля. Я туда лезу - "Введите логин/пароль". Иду к админу, так и так, перестало работать

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

Как не сможет? Ведь Р1 еще вчера оттуда файлы забирал! Тут Р1 нас услышал, похихикал над моей кармой и решил проверить, а работает ли у него. Не работает! Вчера работало, сегодня не работает...

Разработчица уходит, я выкладываю файл в дропбокс :)
Через какое-то время она возвращается, хитро улыбаясь: "Оля... У меня не воспроизводится". Смотрим у меня - воспроизводится о_О

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

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

Не заражай коллег!

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

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

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

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

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

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

Да, так вот. Приболела я в прошлый четверг. Но чувствовала то себя хорошо! В целом... Да, вечером немного голова поболит, ну и что? Хотя, конечно, все равно была немного раздасадована фактом, что вместо того, чтобы в пятницу поболеть, мне еще и субботу надо выйти (собственное решение, конечно, но так было надо).

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

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

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

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

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

Какой смысл сидеть на работе по 12 часов, трудоголить, когда в итоге эффективность понижается до той же работоспособности, которую можно в 8 уложить? Аналогично и с болезнью, вот вроде кажется, что нельзя, релизы, планы, все дела, а будет ли лучше работать?

Я вон, лучше из дома что-нибудь полезное в рабочую вики напишу (а ручки то чешутся и идеи есть, сил нет), отдохну, а потом приду на работу и все разломаю :)

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

PPS - а может, я этим постом просто сама перед собой оправдываюсь... Не люблю болеть!

Работать рядом или удаленно - есть ли разница?

Я продолжу раззадоривать любопытство тех, кто еще не читал Карла Вигерса, приводя любопытные цитаты из его книжки. Все статьи по книжке:

[1] [2] [3] [4]

Когда Карл Вигерс рассказывает о проблемах при разработке специальных требований, он пишет, что:

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

А потом он приводит такой интересный пример из жизни:

Клиент в поле зрения.

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

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

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

Чем мне нравится эта история? Да тем, что это действительно правда - ничто не заменит реальное общение. Когда-то, на прошлой работе, наша команда попробовала работать удаленно. В итоге все вернулись в офис

Точнее, я и так оставалась в офисе, потому что дома работать лениво =) И скучно, сидишь там один одинешенек... А в офисе пошел, налил чайку, поболтал с коллегами... Все лучше. Ведь от этого и из декрета бегут, устают сидеть дома в 4 стенах (не все, конечно). Начальник мой по долгу службы все равно в офисе сидел. А разработчики поработали-поработали дома, и вернулись. Соскучились :) Ну и еще у одного жена и ребенок... Особо не поработаешь - ребенок папу видит и усе, "поиграй со мной"!

А сейчас у нас на работе разработчики решили помечтать на одном из обедов... А как было бы хорошо работать из дома. Совсем из дома. То есть одна - из Калининграда, второй - из Новосибирска... Ну а что? Жизнь дешевле, а деньги те же. "Эх, как хорошо бы было!!!" (с)

На мои возмущения они отвечали, что работа продолжится нормально. А общение? Да подумаешь! Через какой-нибудь скайп или team viewer... Чем плохо? Вот как им объяснишь - чем?

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

Ну конечно, ребятки, скайп - прекрасная замена живому общению, ага 

Auto ConfetQA. День третий!

Вот она и закончилась, наша вкусная, сладкая и насыщенная знаниями #confetQA :((

Сегодня был последний день. Содержащий еще 4 полезнейших доклада!

Начать должен был Александр Баглай с рассказом про Testing Dojo. Но тестировщики - на то и тестировщики, чтобы все у себя разломать. У Саши возникла какая-то фигня со звуком и пришлось срочно переключаться на следующего докладчика.

Управление передали Дмитрию Жарию. И пошел рассказ о том, как можно делать красивые красивые отчетики. Для аналитиков, ну и себе глаз порадовать. Доклад был очень клевый, но, к сожалению, машина явно была слабая и периодически звук у докладчика начинал прерываться... Это немного подпортило впечатление. Но, заметочку на поля я себе вынесла - хочешь отчетик на C# - используй Gallio Automation Platform + MbUnit!

Потом выступал Михаил Бондарчук. Это автор замечательного проекта Codeception. Было очень интересно послушать непосредственно автора  Правда, сейчас, глядя на аннота
цию доклада, я заметила там "покажу на практике установку Codeception", а я что-то этого не припомню, вроде сразу нам строку ввода кода показали...

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

И вот наконец, слово перешло к Александру Баглаю. Его выступления очень ждали в твиттере, так как далеко не все знают, что же это такое - Testing Dojo. Я про него уже не раз читала, поэтому надеялась узнать что-то новенькое от разработчиков. Узнала, что эту программу можно получить бесплатно и применить у себя в команде / в региональном клубе тестировщиков. Очень и очень заманчиво! Почитаю еще на форуме ответы на вопросы, а потом подумаю, как его применить будет лучше...

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

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

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

Auto ConfetQA. День второй!

А вот и второй день #confetQA прошел! Немного грустно, ведь осталось всего 4 доклада, всего 1 вечер... Но! С другой стороны. скоро будет Fun ConfetQA! Так что не отчаиваемся, не плачем, а просто ждем завтра и наслаждаемся тем, что есть :)

Сегодня был девчачий день (да простит меня Коля). Что само по себе странно - обычно от автоматизаторов сплошные мужчины выступают, а тут - сразу 3 девушки! Две из которых - Оли, а еще две рассказывают о том, как писать тесты в Microsoft Visual Studio на русском языке с использованием C#! Вот оно как, Михалыч...

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

Но... Репетиции - наше все  Больше не буду просто вообще без репитиций что-то устраивать... И все будет хорошо)

Я рассказывала о том, как написать робота на Watin и C# в среде разработки Microsoft Visual Studio. Некоторые, наверное, подметили, что я об этом уже говорила. Точнее, писала. Ну да, я решила, что статью ту уже все забыли, а во т если взять и за 20 минут быстренько робота накромсать в live-режиме - будет круто! И наглядно. Статья не так наглядна... Но если что и нужна подробная инстрцкция - вот она, в ссылке выше.

Причем не обошлось и без казусов, написала я вместо "=" знак "-" и в упор не видела своей ошибки. Спасибо Мише, подключился и подсказал... А то я уже подозревать нехорошее стала, как это, студия и не может определить, что такое "var", охохо... Ну да ладно! Оплошность нашли и устранили. Я об этом даже рассказала в докладе, что чаще всего на первых этапах именно такие ошибки и бывают - забыл copy local в true поставить или фремйворк проекта не сменил.... Или "-" вместо "=" напечатал

Ладно, рассказала, отключила запись - фух! Теперь можно и передохнуть. Твиттер включить, других послушать :) А там как раз Николая Алименкова подключили, с его докладом про "Грамотные функциональные тесты с WebDriver и Thucydides.". Коля как всегда на высоте!

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

Так что, пишите на java и хотите попробовать BDD - прямая дорога вам к этому инструменту :) Ну а если вы пишите на C# - то вам прямая дорога к следующему докладу...

Лена Фалилеева продолжила тему "почему BDD это хорошо и как это делать на языке..." - но она уже рассказывала о C# и о том, как писать сценарии на нем. У Лены в докладе было больше кода, чем у Коли, хотя и огорчило немного отсутствие live-coding.

Доклады бывают двух типов - показать, как это сделать с нуля. Или просто подать идею - вот у Лены была идея. Чем хорошо, чем плохо, какие подводные камни, как их обойти... Ну а дальше, ребятки, сами - все сами!

В общем. еще один продуктивный день. Ждем завтра, что же оно нам покажет? Завтра снова выступают сильные докладчики, уже знакомые многим имена... Так что обязательно приходите!

Auto ConfetQA. День первый!

И вот она опять пришла - наша славная #confetQA. Как сказала Ира в твиттере "у меня опять эти дни... Дни confetQA...". Куча самых разнообразных конфеток, на любой вкус и цвет!

Честно говоря, прошлую Auto ConfetQA я слушала вполуха. Ну, потому что сама была докладчиком, присутствовала на репетициях, которые мне не очень понравились. Однако непосредственно на конференции все ребята выступили так хорошо! Они проделали огромную работу и это здорово!

В этот раз докладчики репетировали отдельно, поэтому я решила послушать конференцию. Вдруг чего инетересненькое и вдохновляюoее услышу? И вы знаете, не прогадала!

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

Но тут у Ольги пропал звук, а мои коллеги решили вынести обсуждение проблемы за пределы комнаты :) Поэтому я готова была вернуться к докладу - но увы. Оля попросила ее заменить из-за проблем с компьютером. Ок, тогда мы решили послушать про groovy - но и тут вышел облом. Вот они! Настоящие тестировщики!! GoToWebinar - и тот разломают!

На помощь пришел последний докладчик сегодняшнего дня - Михаил Поляруш. Отличный, четкий голос уверенно ворвался в наушники! Миша решил показать нам все прелести Sikuli, устроив небольшое демо! Это было очень и очень увлекательно. Хотя и немного быстро. Мне наука перед завтрашним выступлением - довольно тяжело воспринимать информацию так быстро. Ее же еще и осмыслить надо :)

Но докладчиков винить тут не в чем. столько времени ушло на организационные моменты, что скорость была всем только на руку. Да и кому нравятся заунывные лекции? А вот живые, да еще и "с огоньком" - самое то! Миша, спасибо за увлекательный доклад! Теперь мы будем знать, что применять, когда надо протестить десктоп :)

После Миши вернулся на сцену второй докладчик - Константин Пермяков. Он рассказывал нам о прелестях groovy. Но, честно говоря, я так и не уловила, чем же он настолько хорош :(
Докладу не хватало прозрачной структуры и четкого изложения... К тому же мы так и не смогли увидеть многообещающее видео - опять проблемы с GoToWebinar, ничего не было видно на видео. Чтож, подождем, когда материалы выложат на форум и посмотрим еще раз, с первого раза доклад было очень тяжело воспринять...

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

Доклад получился очень и очень спорным! Потому что у Ольги автоматизация на проекте не пошла и вывод был сделан крайне оригинальный "Это потому, что мы выбрали Selenium - бесплатный инструмент". А дальше барабанная дробь - "Надо было брать нормальный, дорогой инструмент, а не дешевый". о_О

Вот это вывод! Я думаю, это будет одна из самых обсуждаемых тем на закрытом форуме! Я с таким выводом категорически не согласна, тем более, что, судя по Олиному же докладу, проблемы у них были вовсе не из-за выбора неправильного инструмента. А из-за неправильно написанного и сложноподдерживаемого кода.

Это две абсолютно разные проблемы :) Но, с другой стороны, я абсолютно согласна с Олей в других аспектах - автоматизация бывает невыгодна, когда проект маленький и с небольшим сроком. Или когда вы ограничены в бюджете (ну еще бы я несогласная была, сама об этом говорила на chief confetQA ). А вот со слайдом про дешевые инструменты я категорически не согласна! Дело не в деньгах )))

В общем, доклад такой... Заставляющий высказаться :))) Прекрасная тема для обсуждения! Ведь на самом деле, если у нас что-то не получается, мы копаемся, ищем причины... Но можем найти неправильные причины! И даже можем в них искренне верить... И вот для этого то и существуют конференции - для обмена мнениями! И знаниями! Так что спасибо Оле за такой интересный доклад! Когда можно увидеть автоматизацию с другой стороны... Как оно оттуда, со стороны черного ящика?

А завтра... Завтра будет новый день, новый день ConfetQA. Две докладчицы будут агитировать писать тесты на C# на русском языке, так что готовьте попкорн! Будет здорово! Ну а разбавит нас Николай Алименков, показав грамотные тесты, но уже на английском!

Компромиссы для атрибутов качества.

Продолжаю делать интересные выдержки из книг, соблазняя читателей купить оригинал и узреть полную версию. Сегодня пример будет из книги Карла Вигерса "Разработчка требований к программному обеспечению". Все статьи по книжке:

[1] [2] [3] [4]

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

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

Знак "+" в ячейке означает, что увеличение величины атрибута в соответствующей строке позитивно влияет на атрибут в соответствующем столбце. Например, при повышении легкости перемещения программного компонента повышается гибкость ПО, упрощается подключение к компонентам лругого ПО и возможность повторного использования и тестирования.

Знак "-" означает, что увеличение величины атрибута в соответствующей строке негативновлияет на атрибут в соответствующем столбце. Пустая ячейка означает, что атрибут в строке незначительно влияет на атрибут в столбце.

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

Таким образом, можно использовать эту диаграмму для того, чтобы не ставить перед собой несовместимые цели. Это если смотреть с точки зрения аналитика. А с точки зрения тестировщика - можно помедитировать над картинкой, размышляя, о чем мы могли забыть при тестировании. Рассматривая атрибуты, на которые модификация системы должна была повлиять отрицательно, можно увеличить число проверок, которые мы задумали провести для проверки новой функциональности!

А вы все учли при тестировании?

Доклад на конференции - какую проблему решает?

Сегодня ехала я на работу в метро, читала себе Карла Вигерса и параллельно размышляла на тему своего предстоящего доклада на Auto Confetqa, на тему будущей Fun Confetqa... И пришла я к мысли, что хороший доклад должен содержать ответ на вопрос - а какую проблему я решаю?

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

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

Вот например. Рассказал человек о том, как у них все круто на проекте. Ну ок, а дальше что? А как это к нам применить? И главный вопрос - а нужно ли? Если да, то зачем? Как настоящие тестировщики, мы придираемся к ТЗ или, в данном случае - к аннотации

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

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

Я вот, например, ни на одной работе еще не использовала майнд-мапы. Точнее, использовала, но совсем чуть чуть, так... Порисовать... Поизучать что-то новенькое.

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

Так как им постоянно звонили пользователи, у которых что-то не работало, потому что карточка была не в том статусе. Они спрашивали, что им делать, а тех поддержка спрашивала у нас, какие статусы после каких идут. Это, конечно, можно было и без майнд-карты нарисовать, но мне очень хотелось попробовать. Так что я нарисовала карту проекта, отдельно выделив на ней статусы. Полезно было, да! Заодно и продукт изучила, перед уходом то)))

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

А потом меня еще и Таня добила вопросом - а зачем тебе карты? Может, они не нужны?
Ну как это зачем? Я знаю, знаю зачем! Я хочу, чтобы висела на стене такая красивая карта на А3, а рядом еще одна, и еще. И чтобы посмотрел на карту, и сразу понял, чем эти проекты друг от друга отличаются - а значит, на что обращать более пристальное внимание.

Тогда какого хрена ты на "внедрении" рисовала детализацию функций? Это такой риторический вопрос к самой себе... Вот вроде знаю чего хочу, а реализовать не так то просто...

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

А вот если нету этого, то так сложно начать. А главное - сформулировать проблему. А то и сам начинаешь сомневаться, надо ли оно?

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

Какие проблемы он решает, а главное - насколько он эффективен. Насколько уменьшилось число ошибок, или увеличилось покрытие, или повысился уровень счастья команды

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

PS - А вот про карты я знаю, кому задавать вопросы. Ну, Таня, берегись! 


Отчеты об ошибках, правильно заполнять - легко?

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

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

Я это к чему - по долгу службы я все равно смотрю с точки зрения конечного пользователя. Удалось разработчику проблему воспроизвести или нет, мне стоит проверить.

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

Например, приходит письмо на почту администратора - "Не могу попасть в JIRA, щелкаю на поле ввода логина или пароля - а попадаю на форму отправления заявки администратору!".

Админ приходит ко мне, разводя руками - и как он умудрился? Все же работает. Открываю IE, так как из хрома лениво разлогиниваться, захожу по прямой линке и вожу мышкой между полями ввода. Замечаю странную вещь - между полями мышка из стрелочки превращается в маленькую ручку "нажми сюда". Щелкаю - ба, а вот и форма помощи администратора 

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

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

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

Агащаз. В дело вступает тестировщик. Так. Формочка 1 - не работает ссылка. Открываем формочку 1 - все работает. Но! Ведь эта формочка открывается не только отсюда... Переходим во второе место - бац! Не работает ссылка. Reopen с более точными шагами и удивление разработчика:

- А, так вот что вы имели в виду...

К чему это я все? Просто вчера увидела в ленте твиттера, который транслируется на http://software-testing.ru/ сообщение о том, что программа Fun ConfetQA практически укомплектована.

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

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

Давай, Серега, жги! Расскажи людям о том, как сделать мир лучше с понятным отчетом о найденных ошибках. И вдохнови всех писать так... Так... Чтобы разработчик, работающий на проекте первый день, смог воспроизвести проблему по одному лишь тексту!

А всем остальным я крайне рекомендую поскорее зарегистрироваться и успеть услышать эту вдохновляющую речь! 

Можно ли писать автотесты на родном языке?

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

Мой доклад с рассказом про написание тестов на русском языке вызывал в твиттере и чате противоречивейшие эмоции, от «вау!» до «ересь!», но никого не оставил равнодушным и в итоге занял третье место по результатам зрительского голосования.

Никогда не автоматизировали и боитесь начинать? Не понимаете языков программирования? Не владеете английским?
Вы не можете понять код, записанный с помощью кнопочки record?
Хотите, чтобы тест был не «сломай-глаза», а нагляден и понятен любому? Например, такой:

формочка

.Открыть
.НайтиОбъект
.ПерейтиНаОбъект
.ВвестиФигню
.ЕстьСообщениеОбОшибке
.Закрыть

 

Это возможно! На примере Visual Studio 2010 + Watin + NUnit + ReSharper и c использованием языка C# я покажу вам, что такие тесты… работают!



Хотите принять участие в предстоящей онлайн-конференции? Еще не поздно зарегистрироваться!!!

PS - сперто отсюда.