субота, 24 грудня 2011 р.

Boundary Values, Сага

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

Будут расматриватся места где наиболее выгодно тестировать граничные условия. И это все будет расматриватся на примере пирамиды Маслоу и на примерах. Автор немножко модифицировал пирамиду для лучшей прозрачности и соотвествия MVC модели

Пример 1: Не идеальный мир черного ящика.
В основе лежит тестирование черного ящика, когда все сосредоточено на UI уровне. Также допустим в этом случае существуют Unit tests написаные разработчиками. Тогда картинка будет следующая
Это означает, что 80% ошибок при обработке граничных условий не будет покрыто (это называется скрытыми ошибками), и любая ошибка будет занимать много времени, так как значения проходять от UI уровня к Model уровню и не известно а каком из уровней возникло не соотвествие. Стоимость ошибки в даном случае очень высоко, качество продукта низкое, отвественость высока.

Пример 2: Мир среди дорог
В этом мире существует три прослойки общества.
Первая прослойка - это тестирование граничных условий на уровне пользовательского взаимодействия с системой (javascript, controllers)
В этом случае количество ошибок уменьшается до 60% в нижних слоях и до 10% на уровне дизайна. Если 10% ошибок приемлимо, то 60% скрытых ошибок оставляют большое время на их воспроизведение и не увеличивают качество.

Во второй прослойке, граничные условия тестируются еще ниже в архитектуре. Это тестирование называется интеграционным. Тесты на этом уровне обладают таким свойством, как быстрота и простота. При таком тестировании мы получаем 10% скрытых ошибок суммарно для JS&UI уровней и 40% скрытых ошибок на уровне Models. Качество продукта при такой модели довольно высоко и риски низки. Такое тестирование имеем место и можно на этом остановится, если мало ресурсов и нет времени для более глубокого иследования продукта.


Третяя прослойка, или высшее общество мира, тестирует граничные условия на уровне Model. При таком размещении любая проблема находится настолько быстро, насколько это возможно. Стоимость ошибки низка, качество высокое. Модель приближена к идеальной пирамиде маслоу, когда у нас очень много unit-tests и мало UI, так как достаточно проверять happy-path на этих уровнях

Но при такой моделе наблюдается небольшое увеличение сумарного количества скрытых проблем, которое составляет 20%

Пример 3: Економическое сообщество
Это идеальное общество, по мнению автора. Граничные условия тестируются на двух уровнях: Model & API
При такой модели количество скрытых ошибок суммарно составляет 10%, но качество продукта очень высоко, так что стоимость такой ошибки, если она обнаруживается ооочень низка. Также такой подход позволяет обнаруживать проблемы на очень раннем этапе разработки и доставлять готовый продукт закажчику быстро. Есть конечно минусы, когда большой процент тестирования ложится на разработчиков. Хотя последние тенденции говорят, что это лучший подход в Agile разработке

Пример 4: Идеальный мир
Такой мир существует, только при разработке очень критической функциональности (банковское ПО, самолеты, и тп).
В таком случае практически нет рисков, качество продукта на супер-уровне, все щастливы и свободны (но это не долго)

Подведем итоги:
Для того чтобы а) получить очень быстрый фидбек и б) сделать очень качественных продукт с в) малыми затратами необходимо использовать модель с Примера 3
Если у вас мало ресурсов, но все равно хотите быстро получать фидбек - используйте Пример 2.в


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

Конференция XP Days Ukraine

Вот я и вернулся с конференции посвященных Agile практикам разработки програмных продуктов.

В общем конференция прошла неплохо.  Было представлено много полезных техник, много опыта и отличных докладчиков.

Любая конференция несет в себе смысловую нагрузку и предоставляет некоторые знания.

Первое, что можно вынести, это представление фреймворка Approvals, который позволяет рефакторить Legacy функциональность. Данный фреймворк фиксирует входные и выходные данные и мы их принимаем на веру. И далее рефакторим фукционал не боясь его поломать.
Презентацию и видео можно посмотреть здесь
Фреймворк Approvals:  http://approvaltests.sourceforge.net/   http://blog.approvaltests.com/

Как рефакторить Legacy проекты? Вы еще не знаете, тогда Виктор Полищук идет к вам. По словам автора доклада, первым делом нужно определится нужен ли вам И закажчику этот рефакторинг. Далее следует продумать саму структуру проекта. Желательно также использовать Dependency Injection Frameworks (Spring, hibernate) и ОБЕЗАТЕЛЬНО строить стену между отрефактореным кодом и legacy. Вот тогда будет профит
Презентация: http://xpdays.com.ua/materials/legacy/

Дальше Я слушал Катю Каменеву с докладом, как у них в компании построен процес тестирования и Continiuos Delivery. Познавательно,  когда все тестируют, а не только отдел тестирования.
Смотрим: http://xpdays.com.ua/materials/agile-testing/

Далее были ЛайтТолкс. Автор услышал про полезные трюки при планировании времени, почему необходимо постоянно тестировать производительность, как кодить- чтобы не пахло.
http://xpdays.com.ua/materials/tricks/
http://xpdays.com.ua/materials/performance-testing/

Далее автор слушал гостей с далекого зарубежия.
Dmitriy Kovalenko расказал как сделать так чтобы мастер никогда не был красным. Также представил приемчики по автоматическому мерджу и реверту на CI (за наличием материалов следим на http://xpdays.com.ua/materials/ )

Второй доклад Joseph Wilk расказывал как с помощью BDD построить процес тестирования с стартапе. Полезно послушать самого создателя Cucumber, но каюсь - где-то на половине отключился. Смотрим, познаем: http://xpdays.com.ua/materials/bdd/

Вот так прошел день XP

неділя, 4 грудня 2011 р.

SQA Days 10

Вот и прошла юбилейная конференция SQA Days 10 в Москве.
По организации было все хорошо, но это была первая конференция, после которой у меня в голове фактически ничего не осталось.

Но все же я кое-что вынес из конференции:

Полезные советы по тестированию безопасности представленные Игорем Бондаренко, очень даже практичны и применимы. Правда придется еще пересмотреть разок видео с презентацией, так как мне не было видно всех операций производимых на екране. После доклада, я понял, что мне еще придется почитать про SQL Injection & PHP Injection и другие виды уязвимостей в Web-приложениях.  Также приведеные докладчиком инструменты, послужат мне службу, при внедернии Security Testing в моей организации.

К можалению я выбрал не тот доклад и пошел на Райана Наймана вместо доклада Татьяны Зинченко с докладом по Юзабилити. Теперь прийдется смотреть видео :"(

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


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

Далее слушал доклад на волнующюю меня тему метрики. Были расмотрены метрики
  • количество найденых багов до и после релиза
  • покрытие кода тестами. 
Первая метрика  расчитивается следующим образом:

        количество найденых багов после релиза кастомером
С = --------------------------------------------------------------------------
       сумарное количество найденых багов + надейные до релиза

Вторая метрика включает оценку покрытия как класические показатели:
  • Classes
  • Methods
  • Conditions
  • Pathes
  • Entry/End points
Так и специфические blocks/lines. Если с покрытием lines, более менее понятно, що с blocks все якось дуже розпливчасто. И расчытыается из ROI (но как так и осталось за ширмой )

 После обеда я засел на стендовых докладах, так как темы мне показались довольно интересными, но вынести довелось не много.
ITшоумен А.Орлов поведал о цикле Карба и о том, что правильнее науку про обучение называть андрогогика, а не педагогика (хотя в итоге оказалось, что первое - это всего лишь часть второго (с) гугль )
Горизонтами в тестировании, обозвали проактивную деятельность тест менеджера и предсказывание им последствий каких либо изменений в процессах. Хотя само разделение на типы последствий довольно интересно:
  • Шах (в пропасть) - грандиозное изменение в каком либо процессе. Предотвратить нельзя, но можно попробывать предсказать последствия. 
  • Атаки - это места наиболее используемые пользователями. Фактически это высоко нагруженые части. Предоствратить нельзя, но можно уменьшить влияние
  • Потенциал - любая потенциальная проблема
  • Расширение области видимости - например предугадывание наиболее класических ошибок в разрабатываемой фиче. 
Далее как оказалось суть всего доклада было умение задавать нужные вопросы нужным людям в нужный момент. Докладчика можно потролить в блоге yatester.ru

Интересный и полезный инструмент (скринкастер для снимания видео) был представлен Станиславом Фомином. Обещал выложить на сайте. Ищем по belonesox

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

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

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

Интересная идея делится собственными failures во время проекта была предложена ребятами из QAClub Dnepr. Организаторы даже собираются сделать конференцию на даную тему. Обещали пригласить, как докладчика. =)

Про принципы и необходимось быть правильным тест-менеджером расказала Наталья Руколь.

Вот все что я хотел вам поведать о конференции SQA Days 10 в Москве. Надеюсь следующая конференция, которая пройдет в конце апреля 2012 в Киеве будет более насыщеной и я там буду выступать в роли докладчика.

неділя, 13 листопада 2011 р.

Как всегда быть эфективным?

     Совсем недавно прочитал книгу Stephen R Covey  - "The Seven Habits of Effective People" . Я давно хотел подержать в руках данных бестселлер, но удалось это сделать только сейчас.

     Данная книга наталкивает на размышления об эфективности собственной жизни, твоих дел и задач в карьере.  Что же мы должны делать, чтобы быть эффективными? Чем руководствоватся, какими средствами пользоватся? Вопрос эффективности в нашей жизни, и в часности профессиональной деятельности часто обсуждаем и очень важен. Я всегда старался быть лучшим из лучших. Быть полезным и эффективным. Но не всегда это получалось.

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

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

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



пʼятниця, 21 жовтня 2011 р.

Как правильно отдыхать?

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

Читать дальше...

субота, 8 жовтня 2011 р.

PMCamp Kiev

Добрый день.

На прошлой неделе автор посетил еще одно мероприятие Project Management Camp

Даное мероприятие заставило задуматся на очень многими вещами. Это:


И много другой полезной информации.

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

Что еще стоит почитать, для понимание полноценности картинки:
  • Теория ограничений
  • Lean Process Development
  • Голдрат Элияху "Критическая цепь"
  • Роберт Шелдини "Психология влияния" 
  • Stakeholders in your project

10 принципов управления проектами в сфере услуг

Новое направление в проектном бизнесе это проекты сферы услуг. И эти проекты требуют особого подхода к управлению.

Это все потому что
"Услуги - в центре внимания люди"
"Наши активы - это наши люди"
"Каждый проект и клиент - индивидуален"
"Качество и сервис достигается тесным взаимодействием"

Выделяют следующие принципы управления 
  1. Маркетинговая кампания
  2. Важно собирать идеи и "недовольства" от клиентов. В особености "недовольства" - они дают "волшебный пинок" для вас
  3. Задачи, цели, стратегия
  4. - Главное понимать, а не продавать. - Адекватно оценивать ваши возможности - Важно: взаимная отвественность между вами и клиентом
  5. Кто клиент?
  6. Качественный подбор персонала
  7. Самый качественный персонал сам хочет у вас работать. Люди которые приходят сами предлагают за что они будут отвественны и что будут делать.
  8. Управление талантами
  9. Каждый человек талан. Нужно знать эти таланты и открывать новые.
  10. Обратная связь з персоналом
  11. Обратная связь с клиентом
  12. Обечения персонала + клиента
  13. Накопление и передача опыта
  14. Не нужно делать одно и тоже по нескольку раз. Необходимо вести базу проблем и решений к ним.
  15. Получайте удовольствие

(С) По следам доклада Виты Кравчук "10 принципов хорошего управления проектами в компаниях сферы услуг"

Управления креативными проектами

А точнее 10 правил "Как провалить проект"

Правило первое "Понятно"

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

Правило второе "Сам(а)"

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

Правило третее "Помню"

Пам"ять она девичья, знаеете. Все что вы сегодня помните - завтра обернется пустотой. Поэтому записывайте, дорогие мои ;)

Правило четвертое "Надо"

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

Правило пятое "Знаю"

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

Шестое правило "Опыт"

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

Седьмое правило "Некогда"

"Отстань, мне некогда!" мы слышали даное высказываение очень много раз и много раз его сами говорили. Но нужно четко понимать какие задачи
  1. Срочные и важные
  2. Не срочные, но важные
  3. Срочные, но не важные
  4. Не срочные и не важные
Так что необоходимо учится управлять своим временем и делегировать задачи (если они не требуют немедленного вмешательства)

Правило восемь "Кажется"

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

Правило предпоследнее девятое "Легко"

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

Правило десятое "Должен (должна)"

Мы никому ничего не должны. "Кому я должен - всем прощаю". Это касается контролируемости выполнения задач. Нужно четко оговаривать "контрольные точки" и спрашивать со всей строгостью.

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

(С) По следам доклада Марии Поляковой "Как управлять креативными проектами?"

Структорный подход к управления проектами

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

На углах этого трех угольника возникают точки управления. Это:
  1. Удовлетворения вашего персонала продуктом, который они разрабатывают (мотивация)
  2. Решения вашим продуктом проблемы на рынке (услуги)
  3. Желание и принятие бизнеса в котором работает персонал (мотивация, инновации)

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


Так что игроки на рынках выглядят следующим образом:


К сожалению 90% компаний в Украине имеют большой доход, что приводит их к неистойчивости. Также существуют перекосы в модели, что приводит к банкроству и раззорению бизнеса (неподписаный трехугольник)



Но в любом случае нужно стремится к стабилизации и пытаться достичь сбалансированой обстановки. И здесь возникают множество споров:
  • Зачем нам достигать баланса и терять доход?
  • Больше персонала - больше текучки, необходимости в управлении, мотивации и тд.
И здесь необходимо рассуждение о процессах
  1. Четкой цели
  2. Испольнительности
  3. Гибкости
  4. Обратной связи с подчиннеными, клиентами, рынка
  5. Контролируемости
  6. Понимании динамики процесса
Первый пункты более менее понятны каждому управленцу, а вот последний пункт имеет инстересную особеность - некую лаг фазу. (см картинку)

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

(C) По следам доклада Романа Сторчака "Системный подход к управлению проектами" 

субота, 24 вересня 2011 р.

Post-AgileEE

Добрый день дорогой читатель.

В этом году я решил не мелочится и заплатить 300 евро для того чтобы попасть на конференцию Agile Eastern Europe.
Организаторы конференции в этом году пригласили множество ключевых докладчиков, известных нам из книжек по Agile и даже тех кто стоял у истоков самого направления Agile.
Одной из полезностей конференция было то,  что не всегда выпадает возможность посмотреть в глаза создалею и спросить "Why?"

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

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

В общем конференция хорошая и полезная, если  фильтровать "базар"

Тезисы которые необходимо запомнить:
  • No mater what is  your speciality - agile is in your mind
  • IT-systems  are open-ended games while Software development is finite-ended game
  • Invent, Comunicate, Decide - general moves in game "Agile"
  • You have to learnt transactions in our company
  • People don't match formulas
  • If you still counting bugs number in the end of iteration -> you are not in agile project
  • We all from industry and school and this is our BIG problem in software development
  • Sometime leaders are continure behaving like home and this is blocker for collaborate in their teams
  • You should never roving against the tide.
  • You'll never work with system, you only dance with it
  • Software team is a complex adaptive system
  • Managers are monsters BUT agile managers is friendly monsters =)
  • Autonomy, Mastery, Purpose
  • Shu-Ha-Ri aproach
  • In agile Developers are Testers and Testers are Developers. 
  • "If you are not failing you are not trying"
  • Post-Agile is XP =)
  • Lawyers cost more that testers
  • Spec is speculation not specification
  • and more other

пʼятниця, 23 вересня 2011 р.

Отличия QA от QC

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

После первого дня пребывания на конфереции, а в часности общения в неформальном кругу за обедом меня заставили задуматься кто Я на самом деле QA или QC подворотный?

Для того чтобы разобратся что к чему необходимо определится с терминами (via) Wikipedia:

Quality assurance, or QA (in use from 1973) for short, is the systematic monitoring and evaluation of the various aspects of a project, service or facility to maximize the probability that minimum standards of quality are being attained by the production process. QA cannot absolutely guarantee the production of quality products.

Quality control, or QC for short, is a process by which entities review the quality of all factors involved in production. This approach places an emphasis on three aspects:
  1. Elements such as controls, job management, defined and well managed processes, performance and integrity criteria, and identification of records
  2. Competence, such as knowledge, skills, experience, and qualifications
  3. Soft elements, such as personnel integrity, confidence, organizational culture, motivation, team spirit, and quality relationships.
The quality of the outputs is at risk if any of these three aspects is deficient in any way.

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).

Теперь определимся с отвественностью:
QA имеет наибольшую отвественность (капитан Очевидность однако =) ) и отвечает за
  • Предоствления инструмента оценки качества продукта всем участникам процеса разработки
  • Измеряет метрики качества и на основе их разрабатывает способы улучшения качества продукта
  • Создает процес обеспечения качества если такого нет в компании
  • Расчитывает риски качества и предоставляет эту информацию лицам принимающим решения
  • Выступает отдельной ролью в проекте и компании.
  • Может принимать решения о выпуске продукта, если он отвечает метрикам качества
QC имеет меньшую  отвественность. Эту роль часто путают с ролью Тестировщика. И эта роль отвественна в:
  • Сборе метрик тестирования и качества проекта
  • Принимание непосредственного участия в обеспечении качества продукта.
  • Предоставлении информации о качестве продукта
Software Test Engineer отвественен за:
  • Тестирование продукта
  • предоставлении о состоянии того или иного разрабатываемого функционала
  • Предложений улучшения использования продукта ( usability )
  • Собирание таких метрик как количества багов на единицу кода
Что же касается меня, то я нахожусь во всех трёх ролях в разной пропорции.
  • Отвественен за построение процеса тестирования 
  • Планировании тестирования
  • Контроле за качеством продукта
  • Предоставлении информации о возможности выпуска продукта, и за редкими случаями за выпуск продукта
  • Сбор информации по продукту и разработку улучшений его качества. 

Также я понял что я обладаю всеми задатками QA и мне следует стремится принимать отвественность даной роли и выполнять все задачи этой области.

субота, 3 вересня 2011 р.

Тестировать - это интересно!

Недавно был на конференции IT-Jam Odessa и слушал доклад Kateryna Sushko и этот доклад по странным обстоятельствам натолкнул людей переходить в тестирование. 

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


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

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






 

четвер, 18 серпня 2011 р.

Чем отличается тестировщик от других камрадов.

От остальных работников К, сотрудник тестирования отличается наверное тем, что:
1) постоянно указывает другим на их ошибки. А ведь никому это не нравится!
2) не думает о том, что придет еще кто-то и найдет все его ошибки и недочеты.
3) знает разрабатываемый продукт (и особено его недостатки) лучше других.
4) не верит на слово другим работникам К (особенно в области, за которую несет отвественность).
5) обычно он виноват, если проект неудался, и не при делах, если все ОК.
6) всегда говорит о том, что ему не хватает ресурсов(времени, оборудования) чтобы все протестировать как надо.
7) при всем при том (см. п.6) ухитряется выжимать из имеющихся ресурсов более 100% :)
8) любит самостоятельно выполнять работу, которую другие не сделают без его напоминания (например верифицирует баги).
9) ленив, поэтому все-время что-то автоматизирует и оптимизирует (а перед релизом делает все руками, ибо так быстрее и надежнее :)
10) зачастую не доволен качеством выпускаемого продукта и порой удивляется его успеху у пользователей.
11) может представить не только как должна вести себя система в оговоренных спецификацией рамках, но и то, как заставить систему работать за этими рамками.
12) является первым настоящим пользователем разрабатываемого продукта.
13) созидает разрушая (как скульптор или резчик по дереву - отсекает все лишнее и неправильное получая в остатке произведение творчества)
14) порою, является единственным носителем знаний не только о том как работает продукт, но и о том как же он должен был работать.
 
(С)  http://software-testing.ru/forum/topic/14378/page__view__findpost__p__63180

Вместо привествия.

Добрый день читатель.

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

Немножко про автора:

Меня зовут Алексей Зозуленко.
На момент создания этого блога являюсь лидом небольшой команды тестировщиком.
Свой путь в тестировании начал еще на институтской скамье. Меня, так сказать, подсадили на тестирование (Это было в 2007 году). И теперь я как наркоман не могу без него жить.


Про дальнейшее развитие собитый раскажу по ходу написание постов в этом блоге.