пятница, 29 марта 2013 г.

Java - разомни мозги!

Просто не смогла удержаться. Когда был выпущен журнал по тестированию, раздаваемый во время SQA Days, у него сзади на обложке был напечатан кроссворд по тестированию. Ух, какая классная фишка - помню, мы сидели с коллегами в субботу на работе, на уютном кожаном диванчике - и гадали кроссворд Smile :)

Поэтому представляю вашему вниманию нагло стыренный из "Изучаем Java" кроссворд. Да, он не совсем по тестированию. С другой стороны, наши автоматизаторы сейчас пишут в основном на java, судя по динамике тем на форуме software-testing... В общем, наслаждайтесь!

 

вторник, 26 марта 2013 г.

Black-box, white-box, static, dynamic...

Хочу дать несколько определений видов тестирования, которые мы так или иначе постоянно используем в работе. Определения взяты из книжки Software Testing (Ron Pattorn).

Black-box testing и white-box testing - тестирование методом черного ящика и тестирование методом белого ящика.



Black-box testing, тестирование методом черного ящика - это когда тестировщик знает только то, что приложение должно делать. Но при этом он не может заглянуть внутрь ящика и посмотреть, как происходит преобразование исходных значений в итоговые.

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

Static и dynamic testing - статичное и динамическое тестирование.

Static testing, статичное тестирование - тестирование чего-то. что не запущено (not running), исследование и ревью.

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

Ну а теперь группируем!

Static black-box testing - тестирование спецификации, требований. Требования - это документ, а не работающее приложение, поэтому подходит под определение "статическое".

Dynamic black-box testing - тестирование приложения без погружения внутрь кода. Также называется поведенческим, так как в данном случае мы тестируем поведения программы и определяем его корректность (в большинстве случает по ТЗ).

Static white-box testing - процесс тщательного и методичного ревью архитектуры приложения, его кода на предмет обнаружения багов. Ревью проводится без запуска кода, поэтому оно - статичное.

Dynamic white-box testing - использование информации, полученной при изучении кода и принципа его работы для составления тестов. Динамическим оно называется потому, что программа запущена. В частности, мы можем использовать debug - режим для понимания того, как работает приложение. 

понедельник, 25 марта 2013 г.

Операционная бригада. Хирург-тестировщик.

Сегодня я хочу представить вашему вниманию отрывок из книги Фредерика Брукса "Мифический человеко-месяц".

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

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

А что делать, если команда не 3-4 человека. и даже не 10, а сотни, тысячи? Харлан Миллз предлагает свое решение. Он предложил, чтобы на каждом участке работы была команда, организованная наподобие бригады хирургов, а не мясников. Имеется в виду, что не каждый участник группы будет врезаться в задачу, но резать будет один, а остальные оказывать ему всевозможную поддержку, повышая его производительность и плодотворность. Итак, наша команда:

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

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

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

...

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

Чем хороша такая бригада? Над задачей трудятся 10 человек, 7 из которых профессионалы, но система является продуктом одного ума или по крайней мере двух, действующих uno animo (как одно целое). И если в обычной бригаде партнеры равны, в хирургической различий интересов нет, а разногласия единолично решаются хирургом
------------------------------------------------------------------------------------

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

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

Страшно представить себе такую ситуацию. Но когда народу много, так и бывает. Тест-менеджер следит за группой своих тестировщиков, архитектор - за группой своих разработчиков, и чем выше по иерархии в большой компании, тем больше ответственности. Бррр. Хорошо работать в небольшом коллективе. Где ты сам себе хирург или хотя бы второй пилот Smile :)

Чем полезен доступ к коду...

Еще раз обращаясь к Ron Pattorn, Software testing:

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

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

Но при это доступ к коду порой может значительно облегчить нам жизнь и помочь найти багу, а иногда даже исправить ее самим Smile :)

Вот, допустим, один из примеров.

Загружаем в систему файл. он сохраняется в БД и данные появляются в приложении, но только если они есть в списке допустимых значений (допустим, в этом списке есть слово "TEST").

И так как мы всегда должны начинать с позитивных тест-кейсов, я ввожу "TEST" и загружаю файл. В ответ - ничего. Хм... Редактирую файл, чтобы убедиться, что загружается именно он - да, загружается именно он, но значение не подтягивается.

Открываю БД, смотрю, а у меня там значение "TEST                 ".

Что-то я сходу сама не сообразила в чем дело, поэтому пишу разработчику:

- А почему у меня в БД ";TEST              ;" (; выступает в роли разделителя), если в файле загружаемом у меня ";TEST;", откуда берутся пробелы?

- Ну, откуда я знаю? Это ты так грузишь.

- о_О

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

Изменяю значение прямо в БД на "TEST", коммичу, загружаю... Опять ничего о_О

Смотрю в базу - опять пробелы! И тут до меня начало доходить...
Открываю скрипт создания БД, ну конечно!

field_1 VARCHAR2(20 byte),
field_1 VARCHAR2(30 byte),
field_1 VARCHAR2(50 byte),
field_n CHAR(3 byte),
field_test CHAR(50 byte),
...

Ах это я так данные загружаю? А кто скрипт писал??

Переменные типа CHAR имеют фиксированную длину, поэтому при необходимости они заполняются до максимальной длины пробелами.

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

Вот так вот - всего то и надо было, скрипт поправить. А не будь у нас доступа к БД, к коду? Что тогда? Первый же позитивный тест проваливается! Мы загружаем правильное значение, а оно не появляется в системе. А почему - не знаем. Просто ставим блокер и сидим ждем, когда же его исправят...

JIRA. DashBoards

Итак, мы создали задачку в нашем проекте. Как нам найти информацию по тому, кто какие активности по этой задаче проводил, пока нас не было?

Можно посмотреть в проектах. Projects - название проекта.



Что мы видим, перейдя по этом ссылке? Изначально мы находимся на закладке Summary, справа в которой имеется удобный гаджет под названием Activity Stream. В нем отображается, что происходит на проекте.



Еще мы можем перемещаться по закладкам, сортируя, таким образом, информацию. Например, перейдя на закладку Versions, мы можем посмотреть все баги, поставленные и исправленные в релизе 1.0, 2.0 или любом другом. Перейдя на закладку Components, можно посмотреть задачи по определенному компоненту, например, "отчеты" или "логи".

суббота, 23 марта 2013 г.

Чек-лист сохранения файла (негативные тесты)

Хочу процитировать один из советов в книжке "Lessons Learned in Software Testing" (Cem Kaner, James Bach, Bret Pettichord). Сама книга - это набор из 293 небольших (по большей части) советов, которые даются тестировщику, автоматизатору, менеджеру итд, каждому в своем разделе.

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


  • Сохранить на заполненный (нет больше свободного места) локальный диск.
  • Сохранить на почти заполненный локальный диск.
  • Сохранить на диск, защищенный от записи.
  • Сохранить на заполненный диск в локальной сети.
  • Сохранить на почти заполненный диск в локальной сети.
  • Сохранить на диск в локальной сети, защищенный от записи.
  • Сохранить на заполненный диск в удаленной сети (VPN, например).
  • Сохранить на почти заполненный диск в удаленной сети.
  • Сохранить на диск в удаленной сети, защищенный от записи.
  • Сохранить в файл, директорию или на диск, к которому у тебя нет прав доступа на запись.
  • Сохранить на поврежденный (I/O error) локальный диск, диск в локальной сети, или "удаленный" диск (диск на другом компьютере).
  • Сохранить на неотформаттированный локальный диск, диск в локальной сети, или "удаленный" диск.
  • Удалить диск после открытия файла (отсоединить его, закрыть удаленное соединение).
  • Восстановление после timeout-та локального / "удаленного" диска.
  • Генерация других отказов во время сохранения на локальный диск, диск в локальной сети, или "удаленный".
  • Выключение локального компьютера во время сохранения на локальный диск, диск в локальной сети, или "удаленный".
  • Выключение соединения с диском , отсоединение диска время сохранения на локальный диск, диск в локальной сети, или "удаленный".
Для составления подобных чек-листов необходимы две сессии мозгового штурма с коллегами.

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

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

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

Мне кажется, отлично написано. Интересный чек-лист, к тому же применимый во многих организациях - так или иначе многие из нас в своих программах пытаются что-то куда-то сохранить. Так или иначе составляются чек-лист проверок - заполнение входного поля, числового, для email, символьного итд.

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

Просто помните - одна голова хорошо, а две - лучше! Smile :)

пятница, 22 марта 2013 г.

Улучшения - улучшения ли?

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

А потому, что люди не любят нововведений. Как привыкли, так и живем. Более того, люди противятся нововведениям. Что, Вы не такой? А как Вы думаете, Ваши подчиненные / коллеги такие?



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

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

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

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

И надо что-то менять - чтобы она была проста. Помните "Бла-бла-бла"? Побеждают не те, кто ищет компромисс - чтобы или понятно и красиво, легко и интересно, или полное покрытие и немного занудно. Нет! Долой компромиссы! Надо все и сразу! Осталось придумать, как Smile :)

среда, 20 марта 2013 г.

JIRA. Создаем проект, с чего начать?

Казалось бы. при чем тут тестирование?

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

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

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


Открывается примерно такой вид.

понедельник, 18 марта 2013 г.

Нельзя просто так взять и закрыть задачу


Капитан очевидность на связи!

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

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

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

Или даже так - а часто ли возникает такая потребность (если тип задачи был task, а не bug) ? Можно ли что-то сделать, чтобы сэкономить время в будущем?

Once upon the time... Когда-то, будучи простым black-box тестировщиком, я закрывала задачи быстрее, используя именно эвристику "Задание выполнено!"

Я тогда, правда, и баги иногда неоптимально описывала, особенно, не зная, в чем именно беда - "загрузить отчет *** на тестовой и он упадет". Как проверить, если разработчик не написал, из-за чего именно падало? Правильно, загрузить именно этот отчет (или скомбинировать его заново по скриншоту конфигурации) и закрыть задачу. Минут так за 5.

Графоманство? Не моя проблема, ТЗ пишет начальник. Тестировать "около"? Да тестирую я, тестирую, просто отдельную багу поставлю, делов то...

Сейчас, побывав по другую сторону баррикад, я эту эвристику почти не применяю.

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

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

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

А если сложный запрос? Тут так просто не ответишь... Здесь уже нужен анализ ситуации. Даже если видна ошибка, и есть инструмент по ее исправлению - но откуда она вообще взялась? Не устраняем ли мы следствие, а не причину? А есть ли ошибка вообще? Это вообще такие непредсказуемые задачки...

Вот например, в пятницу были у меня определенные планы на день. Пришла на работу... И весь день занималась поддержкой. Ну ок, пришла в субботу, поработать, пока тебя никто не тронет и не отвлечет. Угадайте с трех раз, чем я занималась полдня Smile :)

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

Не закрывайте задачу за 5 минут. Подумайте, откуда она вообще взялась и на что еще повлияла?
 

среда, 13 марта 2013 г.

Дэн роэм. Бла бла бла


Ссылка на OZON.

Книга написана автором бестселлера "Визуальное мышление" (про него пока ничего не могу сказать, еще не читала) посоветована многими "проверенными" людьми - например, Нэнси Дуарте. Ее книги (раз и два) мне очень нравятся, поэтому и Роэма я начала читать с удовольствием.

Речь идет о том, как часто люди говорят, и говорят, и снова говорят... И тонут в потоке слов, не понимая сути. Теряются в круговороте "бла-бла-бла". И, чтобы выбраться из потока пустых слов, нам необходимо пронести нашу идею через живой лес (F-O-R-E-S-T).

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

воскресенье, 10 марта 2013 г.

Руди Карсан, Кевин Круз. Компания мечты

Ссылка на OZON.

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

С другой стороны, пару раз мне таки захотелось растащить ее на цитаты:
Привлекла меня книга своим издательством, "Манн, Иванов и Фербер" обычно плохого не посоветуют Smile :)

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

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

Звонить ему раз-два в месяц, рассказывать о делах в вашем бизнесе и просить совета. Или просить рассказать что-нибудь наставника, "а как у вас это работает?"

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

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

А у Вас он есть?

PS - Добавила книгу в общий список прочитанных мною книг.

пятница, 8 марта 2013 г.

TEST IT! Увольнение, или как уйти?

Коллеги, пинг!

С вами снова наша рубрика TEST IT и я, ее сегодняшняя ведущая, Киселева Ольга.

Первым делом хочу от всей души поздравить наших прекрасных дам!


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

Отдельно хочется поздравить Наташу Баранцеву, которая столько всего для нас, тестировщиков, делает, Наташу Руколь за ее неиссякаемый оптимизм, Татьяну Зинченко за ее спокойствие и Ирину Винокурову за ее отчаянную любовь к переменам Smile :)

Спасибо Вам, девушки! И спраздником Вас! На правах ведущего рубрики имею право на рекламу

Но вернемся к нашим баранам, то есть к тестированию. Или не совсем к нему...

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

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

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

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

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

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

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

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

Ну а напоследок немного ностальгии и воспоминание о своем уходе:

Моя компания, компания А, закрывалась. Всех сотрудников было решено перевести в компанию Б, но она меня не устраивала. Почему? Потому что там не было тестирования. А я хочу оставаться на своем месте.

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

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

Распечатала заявление, пошла к начальству. Захожу в их кабинет, что-то рассказываю, мы обсуждаем вопросы по работе и тут один из начальников (Н) меня тихонько подзывает к себе:
- Оля, ты видела мой вопрос в аську?
- Нет, а что ты спросил?
Н. показывает в монитор, а там висит вопрос "Ты переходишь в компанию Б?".
- А! Нет! Кста-а-а-ти...
Кладу заявление на стол главного.
- Я ухожу.

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

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

Ну а наше время подходит к концу, поэтому я прощаюсь с вами. До встречи, ребята!
Мы ждем ваших писем - пишите на sprosi.testera@gmail.com, задавайте вопросы, рассказывайте истории, грустные и не очень, делитесь опытом - мы рады всем!

Пока, увидимся через неделю!

понедельник, 4 марта 2013 г.

Почему необходимо знать используемую СУБД?

Еще небольшая выдержка из Тома Кайта, "Oracle для профессионалов".

Оно, конечно, капитан очевидность и написано для разработчиков... Но, нам, тестировщикам, тоже важно знать устройство своей СУБД!

Итак, если вы разрабатываете ПО для СУБД Oracle:
  • Вы должны понимать архитектуру Oracle. Не требуется знать ее настолько, чтобы переписать сервер, но достаточно хорошо, чтобы понимать последствия использования тех или иных возможностей.
  • Необходимо понимать, как выполняется блокирование и управление одновременным доступом, и учитывать, что в каждой СУБД это реализуется по-разному. Без этого понимания СУБД будет давать "неверные" ответы и у вас будут большие проблемы с конфликтами доступа и, как следствие, - низкая производительность.
  • Не воспринимайте СУБД как черный ящик, устройство которого понимать не обязательно. СУБД - самая важная часть большинства приложений. Ее игнорирование приводит к фатальным последствиям.
  • Не изобретайте велосипед. Я встречал разработчиков, попавших в трудное положение не только технически, но и на личном уровне из-за незнания возможностей СУБД Oracle. Это происходило, когда оказывалось, что реализуемые ими в течение нескольких месяцев функции на самом деле давно встроены в СУБД.
  • Решайте проблемы как можно проще, максимально используя встроенные возможности СУБД Oracle. Вы немало заплатили за это.
Используйте функциональные возможности СУБД, не тратьте время на то, что уже создано до вас.

Тип компании "Агрессивный мудрец"

Еще один небольшой открывок из книжки "Компания мечты".

Вначале авторы расписывают 12 архетипов организационной культуры, а также то, подходите вы им или нет и почему. А потом на примере совмещают пару типов вместе. И вот что получилось:

Как оказалось, наиболее отчетливо в компании *** проявляется архетип "Мудрец", вторым доминирующим архетипом является "Герой". Сочетание "Мудреца" и "Героя" в совокупности с качественными данными привели к выводу о том, что культура компании принадлежит к так называемому смешанному архетипу "Агрессивный мудрец". Основнываясь на данных опроса, консультанты дали подробную характеристику архетипа, сформулировав пять логически последовательных тезисов, отражающих сущность культуры компании.
  • Движущая сила нашего бизнеса - наука, а движущая сила науки - эктузиазм.
  • Мы команда лучших.
  • Каждый день нас ждут новые амбициозные задачи.
  • Утверждение "Мы всегда так делали" недопустимо.
  • Мы не позволим бюрокртаии встать на пути воплощения интересных идей.
А ведь, в принципе, если заменить в первом тезисе "науку" на "людей" (и их  умы. знания, опыт) - то вполне себе хорошее описание Smile :)

Подумайте сами - Вы ведь команда лучших, не так ли? Wink ;)

А как насчет "Мы всегда так делали"? Вот приходите Вы на проект, а там всегда тесты в TestLink вели, тяжеловесные и никому не нужные. Но вели - ибо "так повелось". Что делать? Продолжать никому не нужную политику или переосмыслить то, что имеется и скорректировать объемы документации?

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

В общем, а вы работаете в "Агрессивном мудреце"? Smile :)

воскресенье, 3 марта 2013 г.

Watin - как написать робота?

Начнем с основ - что вообще такое робот и зачем он нужен?

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

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

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

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

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

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

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

Watin - Web Application Testing in .Net. Последователь Watir - Web Application Testing in Ruby, созданный для того, чтобы писать простые и понятные, легко-читабельные тесты на языке .Net. Имеющий свои недостатки, но, тем не менее, отлично подходящий для такой работы, как быстрая помощь себе в написании робота.

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

Чтобы тестировать движение по статусам, нам надо заполнять эту форму, создавая, таким образом, в своей системе новую карточку. Допустим также, что наше приложение пишется на C# и у нас уже есть Microsoft Visual Studio, в которой работают наши разработчики.

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

Итак, открываем Microsoft Visual Studio и начинаем делать робота... (в полной версии статьи можно не читать вступление, оно точно такое же, просто я хотела сохранить эту ссылку в блоге)

Важно!

В конце статьи есть ссылка на скачивание самого робота - можно скачать, добавить туда библиотечки Watin и посмотреть, как все работает, не написав ни единой строчки кода !!!

А также можно сохранить себе этот проект как пример и на его основе написать собственного робота - ведь переделать существующее всегда проще, чем написать с нуля. Удачи! Smile :)

пятница, 1 марта 2013 г.

Простое решение может... расстроить!

Начала читать "Oracle для профессионалов" Тома Кайта. Зацепила такая история:

Я видел, как разработчики в СУБД Oracle 8i создавали процессы-демоны, читающие сообщения из программных каналов (это механизм межпроцессорного взаимодействия в СУБД). Процессы-демоны выполняли операторы SQL, содержавшиеся в прочитанных из программного канала сообщениях, и фиксировали сделанное.
...
В версиях Oracle до Oracle 8i это был приемлимый (и практически единственный) способ реализации описанной функции. Когда я рассказал разработчикам об автономных транзакциях, поддерживаемых СУБД, они очень расстроились. Автономные транзакции, реализуемые добавлением единственной строки кода, делали то же, что вся их система.

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

Так вот, к чему это я - пока бродишь по конференциям, например, таким, как SQA Days, или читаешь отзывы о ConfetQA, зачастую слышишь и видишь примерно одно и то же.

- Ах, как это все просто и понятно.
- Спасибо, КЭП!
...

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

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

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

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

А еще хочу напомнить, что регситрация на обе конференции уже началась! Быть может, пора зарегистрироваться, а?