Цитата недели




Задача выполненная на 99% считается невыполненной

Шпаргалки для боссов. Тимур Горяев




понедельник, 29 июня 2009 г.

Цитата недели для QA от Developer

Цитата недели для QA от Developer

Новая цитата недели пришла не от QA и не для QA, но данная фраза может быть перефразирована для специалиста любой специальности и любого направления. В том числе и QA:

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

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

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

Джеймс Гослинг для меня один из Энштейнов мира разработки ПО. Поэтому данный человек и его мысли мне весьма и весьма подходят для очередного висящего измышлизма в моем блоге. Пусть висит.

понедельник, 22 июня 2009 г.

Паттерны тестирования. Велосипед первый: GUI-Domain-Test-Report


Паттерны тестирования.
Велосипед первый: GUI-Domain-
Test-Report




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

И поскольку я человек умный, я должен как и всякий умный человек размышлять об умных вещах (подозреваю, что за такие предложения нужно сжигать прилюдно). Я уже упоминал про желание складировать паттерны тестирования в своем блоге . В данной заметке я бы хотел обсудить паттерн построения архитектуры тестовых фреймворков приложений, которому я дал название "GUI-Domain-Test-Report".

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

Проблематика построения тестовых фрейморков приложений

WebDriver: Design Patterns and Development Strategies

Первая ссылка это Design Patterns and Development Strategies . Проект WebDriver должен быть знаком тем, кто занимается автоматизированным тестированим веб-приложений. В документации к данному проекту присутствует описание стратегий-паттернов тестирования.

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

GUI-level

В статье компании ATSG упоминаются оконные объекты:
Оконные объекты - этот тип компонентов специфичен для автоматизированного тестирования, в частности GUI-level тестирования и один из наиболее критичных к изменениям тестируемого приложения. Поэтому, для тестирования подобных компонент следует выработать некоторый workflow-сценарий, который затронет все ( или хотя бы просто большинство ) оконных объектов

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

Test-Buisiness-GUI

Недавно прошла конференция SQADAYS 2009, на которой мне не удалось побывать. Среди прочих презентаций нам будет очень очень полезна презентация господина Ревко Практические Рекомендации По Организации и Проведению Автоматизированного Тестирования. На странице 11 данной презентации появляется картинка с иерархией различных уровней.






"Для создания тестов, тестируемое приложение нужно разбить на 3 основных уровня:
- Тестовый Уровень
- Бизнес Уровень
- GUI Уровень
2 дополнительных:
- Уровень данных

- Уровень Функций"


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

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

Фреймворк-тест-драйвер-приложение

В веб-семинаре Алексея Баранцева Автоматизация функционального тестирования приводился пример стека автотестов:

И один из примеров стека автотестов:

В том числе на семинаре были озвучены паттерны тест-дизайна:
- адаптер для всего приложения,
- адаптеры страниц,
- адаптеры частей страниц\блоков,
- репозитарий элементов UI.

Замечание: Алексей просил не выкладывать материалы семинара на общее обозрение, - чего я и не делаю, но делаю небольшую рекламу его презентации и пиарю его курсы - надеюсь мы в расчете ;).

Нам важны данные материалы поскольку на конкретном примере TestNG-Tests-Selenium-Application мы можем понять, как приложение разбивается на слои с использованием существующих продуктов.

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

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

GUI-Domain-Test-Report (GDTR)

Как это принято в умных книгах, я приведу краткое описание паттерна:

Наименование: GUI-Domain-Test-Report (GDTR)
Также известен: стратегия построения тестового фреймворка
Тип: системный
Уровень: архитектурный
Назначение: обеспечить создание тестового фреймворка разрабатываемого приложения

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

Паттерн GUI-Domain-Test-Report или в дальнейшем GDTR я бы определил как архитектурный, по той причине, что он связан с построением архитектуры тестового фреймворка приложения.

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

Паттерн ADTR подразумевает выделение логически разделенных слоев в тестовом фреймворке приложения для обеспечения более гибкой архитектуры. Паттерн включает выделение тех же самых уровней что и в презентации Ревко , но
+ еще один, самый верхний, следующий после тестового - слой формирования отчетности ADTR:REPORT
- один, уровень Функций, который я не понимаю для чего выделять.
- еще один уровень Данных - о котором позже.

GDTR: GUI-ADAPTER
Данный слой предоставляет набор объектов (GUI-ADAPTERS) , озвученных ранее как ObjectAdapter или оконные объекты.

В основе создания данных объектов как я понимаю, лежит использование паттерна проектирования Adapter (он же Wrapper) (http://en.wikipedia.org/wiki/Wrapper_pattern). Любой графический объект (элемент оконной формы) может иметь свой т.н. адаптер для манипуляции с его содержимым в самом тестовом фреймворке.

Я бы выделил следующие графические объекты:
- Элемент (может быть объединен с другими элементами в контейнере формы или более высокого уровня).
В качестве примера графического объекта можно привести: выпадающий список, поле ввода, чекбокс или радиокнопка.

- Форма (может быть объединена с другими формами в общий компонент или страницу).
В качестве примера: вкладка с зависимыми элементами, тег FORM в HTML.

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

- Страница (является контейнером обычных полей, форм, общих компонент) .

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

Что же входит в обязанности адаптера графических объектов:
- получение данных,
- установка данных,
- клики,
- проверки данных и пр.

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

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

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

Если переводить слово адаптер на язык программирования, то легче думать об адаптере , как о классе, интерфейс предоставляет методы для манипуляции графическими объектами.

GDTR: DOMAIN-ADAPTER
Данный слой предназначен для того, что бы "беседовать" с приложением на его языке - на языке проблемной области. В этом слое также создаются адаптеры, но уже над графическими адаптерами и для бизнес логики.

В качестве примера можно привести оформление товара в интернет магазине. Для выполнения заказа мы должны:
1. Авторизоваться (адаптер авторизации);
2. Перейти в каталог (адаптер главного меню, адаптер страницы каталога);
3. Перейти выбрать товар (скорее всего адаптер формы товара с ссылкой на товар);
4. Перейти на страницу корзины (адаптер страницы корзины);
5. Оформить заказ (адаптер страницы оформления заказа).

В скобках я указал приблизительные gui-adapter-ы для выполнения операции заказа товара. Данную операцию из 5 шагов может выполнять даже один domain adapter.

Здесь возникает вопрос - могут ли одни адаптеры проблемной области включать другие адаптеры проблемной области? Я считаю, что могут. В противном случае возникает дублирование кода. При усложнении поведения сайта, я бы рассмотрел возможность выделения в отдельный адаптер проблемной области шаги 2 и 3 и еще в один отдельный адаптер шаги 4 и 5. Но тут нужно думать ;)

GDTR: TEST

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

Я бы назвал данный уровень модульным тестированием результатов работы адаптеров более низких уровней. Тестовые объекты проверяют и отваливаются с ошибкой, либо отрабатывают успешно. О модульном тестировании, использовании тестовых фреймворков, думаю, в данной заметке особо распространяться не стоит.

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

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

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


Заключение
Надеюсь, что в моей заметке есть и новое и занятное, (да бог чтобы не было такой ситуации когда новое не занятное, занятное не новое) и даже неправильное. К сожалению я не присутствовал на SQADays 2009 и не знаю как обсуждалась презентация господина Ревко. Очень бы хотелось, но не получилось. Думаю результаты обсуждения могли бы серьезно повлиять на содержание данной заметки.

Конечно же многое еще не раскрыто. Есть еще вопросы, которые следует обдумать:
- Вопросы именования объектов слоев. Весьма спорный вопрос. Например, именовать все тестовые объекты начиная с префикса Test. Я лично против такой обязательности. Но в JUnit так принято (а вот в TestNG - нет).

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

- Проблема отделения локаторов графических элементов от их поведения - в литературе используется термин GUI mapping. Я упомянул проблему в заметке. Дай бог разумения понять, как это делается.

Надеюсь, что замечания по паттерну скоро поступят, и я подправлю данную заметку.

Замечания принимаются и обсуждаются.

воскресенье, 21 июня 2009 г.

Цитата недели: Хороший тестировшик, не тот, кто выявит больше всего ошибок, и не тот, кто заставит смутиться даже самого первоклассного программиста. Лучшим является тот, кто добьется исправления наибольшего количества ошибок. Сэм Канер

Умная мысль для цитирования на этой неделе:

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

понедельник, 15 июня 2009 г.

Пятиминутка недоверия

С некоторых пор я перестал доверять людям.

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

- "В моей фиче багов нет"
- "У меня все работает стабильно"
- "Ты потеряешь время - займись чем нибудь другим"
- "Я все проверил сам"
...


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

Все что ты знаешь - ложь









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

Но я немного отклонился.

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

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

Почему же не стоит верить специалистам? - они ошибаются. Часто. Постоянно. Но самое главное - непреднамеренно. За это мы их и прощаем.

Я не однократно упоминал о Мистере Фейнмане. Физике с душой тестировщика. В книге "Вы наверное шутите мистер Фейнман", главе "Решение с семипроцентной поправкой", он описал то, как жестоко ошибся на 9, потом на 7 потом еще на сколько то процентов в одном из своих гениальных расчетах, только потому что использовал данные и константы полученные другими специалистами. Т.е. он использовал результат деятельности других людей. После того как Фейнман понял насколько легко другие люди ошибаются - он сделал вывод: "Больше я никогда не совершу такой ошибки: не доверюсь мнению специалистов."
Тестировщики, скажу громкое слово - МЫ - не имеем права верить в то, что Солнце каждый день всходит на Востоке и заходит на Западе. Каждый день мы должны проверять это. Более того я уверен, что Солнце так не делает. Магнитные стрелки и Солнце очевидно друг о друге знают мало и расхождение должно быть большим.

Теперь задачу усложню: Не верьте себе.
Почему?
Потому, что вы тоже человек.
Я изначально настраиваю себя на перепроверки и планирую время на дополнительные исследовательские тесты. Кроме того у нас с напарницей (очень-обаятельной-бывшей-программисткой) существует практика парного тестирования. После того как один прогонит тест план - тест план начинает прогонять другой. Что то из разряда agile методов для тестировщиков ;).

Время цитировать мудрых










Закончу запись рядом цитат (своих, не своих и не своих подредактированных), которые нужно всегда иметь под рукой.

В любой программе есть ошибки.- Это аксиома.

Не верь словам других специалистов.

Не верь ничему, что написано или получено на основе опыта другого специалиста.

Не верь никому, кто говорит, что все работает!

Все что тебе говорят - ложь!

Не верь себе!!!

Проверь еще раз.

PS
На всякий случай объяснюсь.
Кто то может меня обвинить в излишней агрессии к представителям другой профессии, более "благородной" чем тестирование ;). B ни в коем случае мои предложения не стоит выносить куда то кроме процесса разработки ПО. Я верю многим и многим людям ( даже если они когда то ошибались). Более того я иногда верю и нашему правительству, да, и что греха таить, - нашим обоим президентам.
Моя запись всего лишь попытка посмотреть на проблему недоверия - только как на профессиональные отношения специалистов по тестированию к результатам деятельности разработчиков - ни больше.

Время Цитировать Мудрых, Цитата Недели Или Конец Книги "Вы, Наверное, Шутите, Мистер Фейнман"

С некоторых пор я начал все чаще задумываться над смыслом жизни. Наверное старею... ;)

А если без шуток. Любую книгу теперь я читаю несколько иначе, чем раньше. Теперь читая - я думаю. А раньше просто думал о том, что прочитал, уже после того как закончил листать книгу.

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

"Время цитировать мудрых..." (Каста).

Я создал гаджет "Цитата Недели". Теперь цитаты недели я буду обновлять... каждую неделю. Можно, конечно, и каждый день. Но меня надолго не хватит: через месяц другой начну забывать. А неделя - это все таки 7 возможностей вспомнить!

Моя первая цитата была из замечательной книги про замечательного человека Ричарда Ф. Фейнмана: "Вы, наверное, шутите, Мистер Фейман":

Произойти может все, что угодно, а не то, что, как вы уверены, должно произойти.

Данную цитату я вынес в заголовок одной из своих записей. Читать здесь

Я сторонник того, что специалист должен читать не только книги по своей тематике, но и что то другое. Стихи в этот перечень тоже входят ;). А книга о господине Фейнмане - прекрасный источник вдохновения для специалиста, который хочет продолжать любить свою работу (вы, наверное, помните: "Скучной работы не бывает. Бывают скучные люди").

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

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

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

Да будет у вас эта свобода!

четверг, 11 июня 2009 г.

Новые велосипеды и Паттерны Тестирования


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

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

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

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

На одном из веб-семинаров Алексея Баранцева я задал вопрос - почему озвучено так мало паттернов (практически - только адаптер страниц\объектов). Ответ прозвучал приблизительно так: "наверное потому, что среди тестеров мало хороших программистов". Согласиться с этим не могу, и буду с спорить (люблю спорить если честно): скорее всего просто нет еще достаточного уровня унифицированности и стандартизации (хотя есть istqb), нет еще своего Кента Бека и Марти Фаулера в этой области (хотя есть Канер и Роман Савин), нет еще своих легенд (хотя есть Luxsoft: ).

Мысль о паттернах тестирования витает в воздухе - об этом упоминали в SQADays 2009, в книге Кента Бека Разработка через тестирование (http://www.ozon.ru/context/detail/id/1501671/) есть небольшая глава "Паттерны тестирования" (опять же связанные с модульным тестированием). Паттерны тестирования протягивают свои метастазы и в веб-семинары. Но мало кто складирует паттерны тестирования в одном месте. Пора навести порядок. Если не я - то кто (вроде бы это слова Жанны Д'Арк?).

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

вторник, 9 июня 2009 г.

Почему я не верю в жизнь после смерти или баги выше третьего приоритета

С некоторых пор я занялся профессиональным тестированием.

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

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

Почему я не верю в жизнь после смерти? - потому что я никого не видел из тех, Кто От Туда Вернулся.

Почему я не верю в баги третьего приоритета (4,5 а то и 7!)? - такая приоритезация за собой не несет никакой пользы.

Я раньше разделял проекты (к проектам я отношу не только работу но и домашние дела - вынести мусор для меня настоящий проект) на два приоритета - сейчас и потом. Сейчас нужно написать баг репорт, потом можно протестировать фичу после ребилда. Сейчас нужно накормить ребенка, потом посадить на горшок.

С тех пор я подрос и понял что кроме сейчас и потом есть еще когда будет время или когда нибудь или когда вспомним или, в самом экстремальном случае, наверное уже никогда, но для отчиски совести.... Сейчас нужно написать баг репорт, потом можно протестировать фичу после ребилда, если будет время - просмотреть API новой версии Selenium RC - 1.0. Сейчас нужно покормить ребенка, потом - посадить на горшок, если будет время до прогулки - повторить с ребенком два цвета: синий и зеленый.

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

Сложно?

Cуть в том чтобы баги приоритета 1 и 2 были бы постоянными (стараться этого достичь), а баги приоритета 3 - либо повышались либо оставались такими же. Пересмотр багов должен проводиться периодически и постоянно. Это один из процессов которые нужно внедрять. Простая мысль - управлять багами тоже нужно - но я не встречал практического применения данной мысли на практике - наверное мне "везло".

Пересмотр, повышение приоритетов, и даже (что мне не нравиться) - понижение приоритета, объединение багов в один и присваивание им приоритета на один выше - вот я думаю начальные шаги управления багами.

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


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

понедельник, 8 июня 2009 г.

Exploratory Testing, Мартышкино тестирование, Тестирование по аналогии, Фейман и сейфы

С некоторых пор я читаю ... много. И много чего. За последние полгода в среднем я читаю по три книги в месяц, сотне другой статей, и прослушиваю c пяток аудиокниг.
Эти книги связаны не только с тестированием (нужно же знать больше чем знают другие которые могут предложить новую работу), но также:
- с подготовкой к сертификации по SCJP (нужно же расти профессионально и в цене),
- современная фантастика (нужно же знать что стоит за тем что называют современной фантастикой,
- фентези Пратчета (нужно же иногда и отдыхать),
- преподавание в высших учебных заведениях (нужно же знать о своем хобби),
- блоги своих студентов (нужно же знать тех кому ты преподаешь),
- материалы конференций (нужно же знать умных людей и места где они появляются) и прочее и прочее и прочее И в этом месяце я начал читать книгу "Вы конечно шутите мистер Фейнман". Я уже упоминал о ней и о ее герое. Я думаю данную книгу нужно внести в список книг для обязательного прочтения всеми ... не только тестерами но и людьми IT. Книга далека от IT но мышление господина Фейнмана пригодилось бы любому специалисту этой области. Одна из последних глав прочитанных мной - глава "Ты шнифер, и я - шнифер". Вкратце перескажу одну историю:

Фейнман - любознательный человек. Он решил научиться взламывать сейфы. Он научился. Он также прочел несколько книг как взломать сейф зная человека (очевидно одни первых книг по социальной инженерии ).
И вот несколько больших сейфов со всей документацией по тому как создать атомную бомбу. Хозяин сейфов - человек очень близкий к математике.
И вот приходит Фейнман. Он пытается понять какие числа нужно вбить.
Фейнман находит записку с константой π = 3,14159. Но она не подходит.
И тогда Фейнман использует код основания натурального логарифма e = 2,71828 (вторая по важности после пи математическая константа)
И сейфы с секретами создания атомной бомбы открываются.


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

Теперь об остальных частях заголовка. Что же я хотел сказать.

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

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

Теперь про тестирование по аналогии. Очень редко я читаю про данный вид тестирования. Редко его вспоминают. Тем более ни разу не читал про использование мартышкиных тестов в связке с тестированием по аналогии, а это дает очень и очень хороший результат. Правда, - в количестве багов. К сожалению, данные баги (все 99,99%) будут 3 приоритета. Про баги с приоритетом выше третьего я не верю, равно как про жизнь после смерти, а 1 и 2 приоритеты им дать сложно, поскольку воспроизвести пользователю все то, что я проделал очень сложно.

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

И будем вам счастье.

пятница, 5 июня 2009 г.

произойти может все, что угодно, а не то, что, как вы уверены, должно произойти

C некоторых пор я начал читать книгу "Вы, конечно, шутите, Мистер Фейнман. " о Ричарде Филлипсе Феймане - нобелевском лауреате, одном из создателей атомной бомбы. Это набор историй об этом крайне любознательном и веселом человеке. Среди прочих его рассказов есть глава "Смешивание красок".
Эта глава - прекрасный пример работы тестировщика по жизни. Надеюсь что никто не оторвет мне голову за то что я процитирую кусочек этой интересной книги:

...Я частенько бывал в симпатичном маленьком ресторанчике, который назывался “Папино место”. Однажды, когда я там обедал, недалеко от меня сел маляр в рабочем комбинезоне. Он спустился со второго этажа, где красил комнату. Каким то образом между нами завязалась беседа, и он начал говорить о том, как много нужно знать для того, чтобы заниматься малярным делом. “Например, – сказал он, – если бы вам пришлось красить стены в этом ресторане, какой цвет Вы бы выбрали?”

Я ответил, что не знаю, на что он сказал: “Стены нужно покрасить в темный цвет до такой то высоты, потому что, видите ли, люди, сидящие за столами, трутся локтями о стены, так что белая стена здесь не подойдет. Она слишком быстро становится грязной. Но над темной краской должна быть белая, чтобы создать в ресторане ощущение чистоты”.

Видимо, парень действительно разбирался в том, о чем говорил, так что я сидел, развесив уши, когда он сказал: “Кроме того, нужно разбираться в цветах: знать, как при смешивании красок можно получить различные цвета. Например, какие цвета Вы смешали бы, чтобы получить желтый?”

Я понятия не имел, как можно получить желтый цвет, смешивая краски. Если речь идет о свете, то нужно смешать зеленый и красный, но я знал, что он говорит о красках. Поэтому я сказал:

“Я не знаю, как получить желтый цвет без желтой краски”.

– Ну что же, – сказал он, – если смешать красную и белую краски, то получится желтая.

– Вы уверены, что получится не розовая?

– Конечно, – сказал он, – получится желтая.

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

Тут меня осенило. “Должно быть, происходит какое то изменение в химическом составе. Может быть. Вы используете какой то особый вид пигментов, которые изменяют химический состав краски?”

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

В этот момент я подумал: “Что то здесь не так. Я достаточно знаю о красках, чтобы знать, что в таком случае желтый цвет получить невозможно, но он, должно быть, знает, что желтый цвет получается, а значит, происходит что то интересное. Я должен это увидеть!”

Поэтому я сказал: “Хорошо, я принесу краску”.

Маляр поднялся наверх, чтобы закончить работу, а ко мне подошел хозяин ресторана и сказал: “В чем смысл вашего спора? Он маляр и всю свою жизнь был маляром, и он утверждает, что желтый получается именно так. Так зачем же с ним спорить?”

Я смутился. Я не знал, что сказать. Наконец, я ответил: “Всю свою жизнь я изучаю свет. И я считаю, что, смешивая красный и белый цвет, желтый получить невозможно – можно получить лишь розовый”.

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

– А! – сказал я. – Конечно! Если добавить желтый, то получится желтый, но без него ничего не выйдет.

Маляр ушел обратно красить комнату.

Хозяин ресторана сказал: “У этого парня хватило наглости спорить с человеком, который всю свою жизнь изучает свет!”

...

В конце главы есть предложение которое нужно распечатать крупными черными буквами и повесить на видное место:

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



четверг, 4 июня 2009 г.

Буквально вчера провел в своей конторе занятие. Лекцию, может быть семинар: автоматизированное тестирование веб приложений. Взял за основу прослушанный веб-семинар и материалы к этому же Алексея Баранцева (Функциональное тестирование веб-приложений), презентации последней конференции SQADays 5 2009, материалы конференции SEC(R)-2008 и свое понимание и опыт.

Целей было несколько:
1) донести до разработчиков именно моего проекта (в конторе несколько проектов) что автоматизированное тестирование не есть зло в своем ярком обличии - а всего лишь дополнительный инструмент, который нужно использовать в нужное время в нужных местах с нужными людьми;
2) систематизировать для себя ЧТО нужно делать дальше с построенным фреймворком для тестирования приложения и КАК это сделать наиболее безболезненно
3) показать пример того что занятия в конторе нужны - опытом делиться нужно ( я бы вот послушал особенности работы с СУБД MS SQL Server и Java в нашем проекте - но кого заставишь?)
4) попробовать выступать не перед студентами. Все таки преподавание студентам ( которые по любому будут тебя слушать ) и выступление перед более умными людям (которые могут встать и уйти) - имеют большую разницу

Все цели считаю достигнутыми.
1) разработчики поняли что я не лентяй :)
2) систематизацию провел - наметил план рефакторинга своего кода для автоматизированных тестов
3) пример повлиял - недели через две будет озвучен доклад о проектировании приложений на C++ с использованием UML и паттернов проектирования.
4) выступил не плохо, людям кажется понравилось. Но опять же думаю нужен опыт выступления не перед знакомыми людьми с которым кофе по утрам распиваешь а перед аудиторией побольше и менее знакомой. Думаю провести встречу OSUM в сентябре-октябре в родном Ульяновском политехе. Должно быть интересно. Надеюсь.