субота, 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 в Киеве будет более насыщеной и я там буду выступать в роли докладчика.