среда, 29 июля 2009 г.
Хорошие новости нужно часто повторять!
Не могу пройти мимо хорошей новости. Хорошие новости нужно повторять.
Selenium обзавелся очередным дополнением Selenium Inspector.
Библиотечка позволяет содержит всякие вкусности для облегчения работы с табличками, assert-ами, легким парсингом DOM модели. Короче немножко улучшений и со вкусом.
В купе с тем что Selenium RC обновился до 1.0.1 и в скором времени обещают объединение с Web Driver - это вообще становиться мечта практикующего QA автоматизатора.
понедельник, 27 июля 2009 г.
Программная ошибка как артефакт существующей и правильной спецификации
Всю свою сознательную профессиональную жизнь я пытался создавать идеальные документы. Даже если это были просто отписки о проделанной ненужной работе. Сначала меня этому учили, потом я стал испытывать от этого удовольствие. Перейдя в QA идея идеальности была похоронена реальностью производства ПО.
Спецификации, технические задания, планы проектов быстро и безвозвратно устаревают. Редкий менеджер (в моей памяти) ведет историю документа и только QA, как мячик скачет от спецификации к менеджеру, от менеджера к разработчику, от разработчика к программе, что бы собрать крупицы правды. По этому же поводу Сем Канер отозвался очередной цитатой недели:
Одним из распространенных определений программной ошибки является - расхождение между программой и ее спецификацией. Не пользуйтесь этим определением. Расхождение между программой и ее спецификацией является ошибкой тогда, и только тогда, когда спецификация существует и она правильна.
А если спецификации нет или она неправильна? - Скачите Шура, скачите.
Спецификации, технические задания, планы проектов быстро и безвозвратно устаревают. Редкий менеджер (в моей памяти) ведет историю документа и только QA, как мячик скачет от спецификации к менеджеру, от менеджера к разработчику, от разработчика к программе, что бы собрать крупицы правды. По этому же поводу Сем Канер отозвался очередной цитатой недели:
Одним из распространенных определений программной ошибки является - расхождение между программой и ее спецификацией. Не пользуйтесь этим определением. Расхождение между программой и ее спецификацией является ошибкой тогда, и только тогда, когда спецификация существует и она правильна.
Сем Канер и др. Тестирование ПО
А если спецификации нет или она неправильна? - Скачите Шура, скачите.
среда, 22 июля 2009 г.
Паттерны тестирования: Condition\Time waiters
Количество велосипедов растет. Это радует.
Долгое время (ну, как долгое - месяца полтора) мучился, пытаясь сделать тесты Selenium-а более стабильными и не зависимыми от задержек AJAX. В конце концов наделал кучу TimeWaiter - ов. Хотел даже заметку написать. Похвалиться. Типа очередной велосипед готов. Но удачно наткнулся на более фундаментальный труд ;) Решил что данный труд претендует на более продвинутый паттерн.
Имя паттерна: Condition waiter
Назначение паттерна: Разработка автоматизированных тестов ориентированных на изменение состояний объекта.
Перепечатывать не буду - дам ссылку: http://blog.vitorg.ru/webtesting/2009/07/14/selenium-ojidanie-zaversheniya-ajax
Долгое время (ну, как долгое - месяца полтора) мучился, пытаясь сделать тесты Selenium-а более стабильными и не зависимыми от задержек AJAX. В конце концов наделал кучу TimeWaiter - ов. Хотел даже заметку написать. Похвалиться. Типа очередной велосипед готов. Но удачно наткнулся на более фундаментальный труд ;) Решил что данный труд претендует на более продвинутый паттерн.
Имя паттерна: Condition waiter
Назначение паттерна: Разработка автоматизированных тестов ориентированных на изменение состояний объекта.
Перепечатывать не буду - дам ссылку: http://blog.vitorg.ru/webtesting/2009/07/14/selenium-ojidanie-zaversheniya-ajax
понедельник, 20 июля 2009 г.
Цитата недели от Сема Канера: ценность плана тестирования
Ценности в жизни QA - это вообще отдельная ветка размышлизмов. Но сегодня будем цитировать мудрых. Например Сема Канера. У одного их столпов QA выявление ценностей звучит с легким бюрократическим уклоном:
Ценность плана тестирования определяется тем, насколько он помогает в организации процесса тестирования и поиске ошибок. Любые его составляющие, не отвечающие этим задачам, являются пустой тратой времени.
Ценность плана тестирования определяется тем, насколько он помогает в организации процесса тестирования и поиске ошибок. Любые его составляющие, не отвечающие этим задачам, являются пустой тратой времени.
Сем Канер и др.
Тестирование Программного Обеспечения
Тестирование Программного Обеспечения
среда, 15 июля 2009 г.
Паттерны тестирования. Timestamped Name
Я уже упоминал про желание складировать полезные мысли о проектировании автоматизированных тестов - паттернах и стратегиях тестирования. Данная запись одна из, надеюсь, многих и связана с использованием времени - как одного из вспомогательных факторов при создании объектов в процессе тестирования.
Имя паттерна: Timestamped Names
Назначение паттерна: Создание уникального имени для объекта
Во время прогона тестов, часто возникает ситуация когда необходимо создать новый объект. У любого объекта есть, как минимум, две характеристики: уникальный идентификатор и имя. Уточним, что имя должно быть более или менее понятным после прочтения (Good, Project etc), т.е. изначально все таки задается текстовая константа, по которой объект и будет именоваться.
У нас есть несколько путей задания задания константы:
- hardcoded константа,
- константа в конфигурационном файле.
Оба способа позволяют создавать статическое имя - в процессе прогона тестов изменить его не получиться. Каким то образом можно задавать имя перед самим выполнением теста или во время выполнения. Что не есть гуд, поскольку мы говорим об автоматизированных тестах и ручное вмешательство недопустимо.
Случается, что имя объекта также должно быть еще и уникальным. И тут указание имен в конфигурационные файлы выносить проблематично. Создаваться может несколько объектов одного типа, но требуются разные имена. Создавать для каждого объекта отдельную константу - слишком сложно (например имена для 1000 объектов). Нужен smart dynamic name. В данном случае - добавление временного префикса или постфикса к имени объекта. Само имя может как задаваться hardcoded, так и храниться во временном файле.
Например мы создаем товар Goods и и после выполнения timestamped операции получаем имя Goods_<...>, где <...> - это timestamped индекс. В будущем если мы захотим найти товар, с вероятностью 99,99999 мы найдем по данному имени только один товар. Оставшийся 0,00...1% я оставляю на проблемы с потоками, из за которых могут возникнуть два товара с одинаковым именем. Эта проблема известна и решаема, в каждом языке программирования - по своему.
В качестве альтернативы Timestamped Names можно использовать Indexed Name. Данный паттерн к имени создаваемого объекта добавляет числовой префиск или постфикс, который после именования очередного объекта увеличивается на единицу или на определенный шаг.
Timestamped Names
Имя паттерна: Timestamped Names
Назначение паттерна: Создание уникального имени для объекта
Во время прогона тестов, часто возникает ситуация когда необходимо создать новый объект. У любого объекта есть, как минимум, две характеристики: уникальный идентификатор и имя. Уточним, что имя должно быть более или менее понятным после прочтения (Good, Project etc), т.е. изначально все таки задается текстовая константа, по которой объект и будет именоваться.
У нас есть несколько путей задания задания константы:
- hardcoded константа,
- константа в конфигурационном файле.
Оба способа позволяют создавать статическое имя - в процессе прогона тестов изменить его не получиться. Каким то образом можно задавать имя перед самим выполнением теста или во время выполнения. Что не есть гуд, поскольку мы говорим об автоматизированных тестах и ручное вмешательство недопустимо.
Случается, что имя объекта также должно быть еще и уникальным. И тут указание имен в конфигурационные файлы выносить проблематично. Создаваться может несколько объектов одного типа, но требуются разные имена. Создавать для каждого объекта отдельную константу - слишком сложно (например имена для 1000 объектов). Нужен smart dynamic name. В данном случае - добавление временного префикса или постфикса к имени объекта. Само имя может как задаваться hardcoded, так и храниться во временном файле.
Например мы создаем товар Goods и и после выполнения timestamped операции получаем имя Goods_<...>, где <...> - это timestamped индекс. В будущем если мы захотим найти товар, с вероятностью 99,99999 мы найдем по данному имени только один товар. Оставшийся 0,00...1% я оставляю на проблемы с потоками, из за которых могут возникнуть два товара с одинаковым именем. Эта проблема известна и решаема, в каждом языке программирования - по своему.
В качестве альтернативы Timestamped Names можно использовать Indexed Name. Данный паттерн к имени создаваемого объекта добавляет числовой префиск или постфикс, который после именования очередного объекта увеличивается на единицу или на определенный шаг.
вторник, 14 июля 2009 г.
Измените свой календарь
Сколько себя помню работающим - я постоянно пытаюсь разобраться со своим time-management.
И когда был системным администратором, и когда стал программистом, и когда стал QA - все время приходилось менять свой календарь. Мне казалось, что это не правильно. Думалось мне - кем бы ты не работал, у тебя должен быть один шаблон календаря, и легкие изменения в формулировках и времени. Мне казалось плохо то, что я постоянно меняю средства планирования - то в электронной таблице, то используя какую нибудь программу, то использование других и нескольких программ. Все время изменялось мое желание - как планировать, как записать, куда записать... А в этом месяце я прочитал книгу "Выживают только параноики" Эндрю Гроува. И наткнулся на цитату, которую хочу поместить в свой недельный цитатник.
Стратегические изменения не начинаются сверху. Они начинаются с вашего календаря.
Эндрю Глоув. Выживают только параноики
Прочитал и задумался (со мной такое часто бывает).
Вспоминая то как менялись моя работа, мои обязанности, мои навыки - я понял, что на самом то деле я пытался приспособиться к новым стратегическим изменениям. И не боролся с изменениями, а использовал свои мозги чтобы к ним приспособиться. В общем то, делал правильно. Бывает радостно понимать, что что-то в этой жизни ты делал правильно.
Кстати. Я меняю работу. А началось все со смены календаря три месяца назад и пересмотра моих профессиональных планов на будущие два года.
понедельник, 6 июля 2009 г.
Имейте бесконечное терпение
Цитата на этой неделе выбрана не случайно (и когда я что то случайно делал? - ведь все с умыслом). Каждому QA случается сталкиваться с одной из следующих ситуаций:
- вам дали сроку "недели хватит", а тестировать нужно "ой как много то";
- самый-умный-программист-в-конторе (а они все такие, забывать об этом не стоит), не желает с вами беседовать о том, что в его фиче есть баги;
- документация "еще в разработке", но тестировать "нужно было уже вчера начинать"...
Цитата нашлась в выписке из правил поведения руководящих работников GE, 30-е годы 20 века. Полностью выписку можно найти здесь: http://www.it4business.ru/up/1913/
Что тут еще добавишь? Удачной недели. И да прибудет с вами сила... и Терпение.
- вам дали сроку "недели хватит", а тестировать нужно "ой как много то";
- самый-умный-программист-в-конторе (а они все такие, забывать об этом не стоит), не желает с вами беседовать о том, что в его фиче есть баги;
- документация "еще в разработке", но тестировать "нужно было уже вчера начинать"...
Цитата нашлась в выписке из правил поведения руководящих работников GE, 30-е годы 20 века. Полностью выписку можно найти здесь: http://www.it4business.ru/up/1913/
Правило № 4: Имей бесконечное терпение
Что тут еще добавишь? Удачной недели. И да прибудет с вами сила... и Терпение.
пятница, 3 июля 2009 г.
Тестеров никто не любит
Все что написано ниже нужно рассматривать не иначе как стеб. Данная запись - это сгусток сатиры, сарказма, преувеличения и выдумки. Это словестное хулиганство рожденное на самых темных сторонах QA, просто потому, что это могло родиться. Это вредные советы и наивреднейшие правила. Следовать им стоит только имея здравый смысл и зная как не обидеть людей своимт шутками. В остальном это заряд дроби слишком напыщенным QA инженерам в известное место.
Тебя не любит руководство потому, что оно не понимает зачем ты нужен, когда есть программисты.
Тебя не любят программисты потому, что они верят - ты вселенско зло, посланное им в наказание за их маленькие ошибки в коде.
Ты подозреваешь, что тебя любит только твой кактус. Но ты не любишь его потому, что ты тестер - и ты не можешь никого любить. К тому же кактус колючий и в прошлый раз, когда ты его обнял, то всю оставшуюся неделю вытаскивал колючки из своей головы и ладоней.
Правила Если...
Если ты нашел чужую ошибку - радуйся. Это повод доказать разработчикам, что они бездарные.
Если разработчик говорит, что найденное непонятство это фича - обзови это багом и запости.
Если кто то говорит что так написано в спецификации - заставь показать это место. Пусть этот негодяй прочитает, нет - пусть заучит наизусть это требование. Потому что ты можешь себе это позволить - заставлять цитировать требования.
Если ты еще не нашел багу - значит ты пока проявил великодушие и просто даешь передышку этим несносным разработчикам.
Правила Будь...
Будь недоверчивым. Не верь никому - потому, что зачем кому то верить, если тебе платят за обратное?
Будь нудным - потому, что нудных не любят. Ты тестер - тебя не могу любить по определению, так что ты ничего не теряешь.
Будь недовольным - потому, что недовольных не трогают, а стараются им угодить.
Будь злым - потому, что злых бояться, а поскольку тебя никто не любит, то пусть хотя бы бояться.
Будь высокомерным, потому что разработчики должны стыдиться своих ошибок. Глядя на твое лицо они должны испытывать стыд и горе, царапать свое лицо камнями и ногтями от бессилия. А ты ошибок не совершаешь - потому что ты их ищешь.
Будь спокоен. В кризис увольняют только программистов - потому что их и так много. А ты один и ты незаменим. Ибо ты велик и ликом ужасен. Начальство испугается тебя уволить, потому что ты нудный, злой и недовольный.
Тебя никто не любит - потому, что ты тестер.
О любви...Тебя не любит руководство потому, что оно не понимает зачем ты нужен, когда есть программисты.
Тебя не любят программисты потому, что они верят - ты вселенско зло, посланное им в наказание за их маленькие ошибки в коде.
Ты подозреваешь, что тебя любит только твой кактус. Но ты не любишь его потому, что ты тестер - и ты не можешь никого любить. К тому же кактус колючий и в прошлый раз, когда ты его обнял, то всю оставшуюся неделю вытаскивал колючки из своей головы и ладоней.
Правила Если...
Если ты нашел чужую ошибку - радуйся. Это повод доказать разработчикам, что они бездарные.
Если разработчик говорит, что найденное непонятство это фича - обзови это багом и запости.
Если кто то говорит что так написано в спецификации - заставь показать это место. Пусть этот негодяй прочитает, нет - пусть заучит наизусть это требование. Потому что ты можешь себе это позволить - заставлять цитировать требования.
Если ты еще не нашел багу - значит ты пока проявил великодушие и просто даешь передышку этим несносным разработчикам.
Правила Будь...
Будь недоверчивым. Не верь никому - потому, что зачем кому то верить, если тебе платят за обратное?
Будь нудным - потому, что нудных не любят. Ты тестер - тебя не могу любить по определению, так что ты ничего не теряешь.
Будь недовольным - потому, что недовольных не трогают, а стараются им угодить.
Будь злым - потому, что злых бояться, а поскольку тебя никто не любит, то пусть хотя бы бояться.
Будь высокомерным, потому что разработчики должны стыдиться своих ошибок. Глядя на твое лицо они должны испытывать стыд и горе, царапать свое лицо камнями и ногтями от бессилия. А ты ошибок не совершаешь - потому что ты их ищешь.
Будь спокоен. В кризис увольняют только программистов - потому что их и так много. А ты один и ты незаменим. Ибо ты велик и ликом ужасен. Начальство испугается тебя уволить, потому что ты нудный, злой и недовольный.
Удачного рабочего дня, трудяги !
Подписаться на:
Сообщения (Atom)