Записки безумного тэстера

Собсна вот и родилось что то, будем развивать!

Адрес: qa.co.kg
Авторский коллектив: Роман Кононов (собсна я он и есть) и Самат Жукешов (блог «QA о разном»).

От авторов:
Основная идея проекта QAлификация - объединение в комьюнити, людей работающих в одном географическом регионе над улучшением качества ПО. Проект реализован в формате микроблоггинга.

Для авторов, это своего рода записная книжка/блог/форум и даже своего рода мини портал, который объединяет людей близких к обеспечению качества программного обеспечения, здесь ведут обсуждения, публикуют заметки, вопросы и решения проблем связанных с общим понятием Software Quality Assurance - как тестирования программного обеспечения так и обеспечения качества процесса разработки, управления, сопровождения и деплоя. Главное - это обмен опытом.

via http://www.it4business.ru/blogs/1639/

PS Всем спасибо за участие,содействие и пеар (надеюсь и продолжите это все делать)

Нашел интересный проект, посвященный созданию визуального интерфейса для распространенной системы контроля версий - SVN. Сам проект называется SVN Monitor

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

В общем интерфейс получился достаточно наглядный и юзабельный :)

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

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

Итак снова продукт от Thoughtworks о котором я недавно писал. Прошлый раз я описывал написание selenium (браузерных) тестов в продукте Twist, в этот раз попробуем проверить другую заявленную возможность - написание тестов на фреймворке Frankenstein .

( Read more... )

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

По содержанию довольно актуальные и интересные темы в частности:

• Turning Software Testing into the Backbone of your Quality Assurance System
• Requirements-Based Testing - Ambiguity Reviews
• Surveying Test Strategies:A Guide to Smart Selection and Blending
• Finally Usability Testing?
• Requirements and test management:More safety in vehicles through traceable testing

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

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

Кстати может кто подскажет еще онлайн периодику по теме тестирования?

Давно не следил за обновлениями данной тулзы, как оказалось обновился до версии 1,2,0 из изменений собсна более информативные отчеты - если раньше отображался только общее количество очков тестабельности, то сейчас можно развернуть более подробную статистику например так

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

К интеграционке также прикручивается методом ant task-а, из анализируемых языков пока таже java, будем ждать развития.

P.S

На официальном сайте можно посмотреть занимательную статистику отражающую результаты проверки на тестируемость различных популярных проектов (AspectJ,JRuby)

Не так давно состоялся бета релиз тулзы для функционального совместного тестирования - Twist. Компания,что выпустила данный продукт уже не раз отмечалась весьма интересными проектами в области тестирования и управления, взять хотя бы Mingle ишшу трекер или CruiseControl - сервер интеграции с которого все начиналось.

Итак Твист (собсна название началось от девиза - пусть вся команда танцует твист) ( Read more... )

На днях читая блоги наткнулся на непонятное определени - оценка покрытия согласно С1, как оказалось это один из видов оценки покрытия кода, спросив у гугла наткнулся на достаточно подробное описание видов покрытия, как оказалось их гораздо больше 3, что я описывал ранее. Итак виды покрыти кода.
1)Собсна то самое(Statement) C1 - линейное покрытие кода, считается каждый выполненный оператор (строчка кода или блок).Данный вид покрытия самый простой и не требует изменения исходного кода.
2)Оценка покрытия кода с учетом условных операторов(Decision - С2) - в каждом условном операторе (if,while,switch...) проверяется вызывался ли условный оператор со значением условия true и false, данный способ оценки более адекватный, но не учитывает тот случай если условие содержит несколько выражений - например if(sample||sample2), при этом вариант sample2 не проверяется/вызывается (если это функция).
3)Оценка покрытия кода с учетом всех условий(Condition) - проверяется покрытие кода на предмет того вызывается ли условный оператор со всеми возможными значениями проверяемых переменных. Данный способ более адекватен чем предыдущий и позволяет получить объективную оценку покрытия
4)Оценка покрытия с учетом путей выполнения(Path Coverage) - в данном случае считаются все пути, которые выполняются в процессе работы (путь - уникальная последовательность выполнения операторов, с учетом условных операторов)
5)Оценка покрытия с учетом вызовов функций(Function Coverage) - учитываются только уникальные вызовы функций - скажем так очень не объективная оценка покрытия (также ее называют BullsEye coverage)
6)Оценка покрытия с учетом выполнения циклов (Loop Coverage)- данная метрика оценивает выполнялись ли циклы имеющиеся в коде один или более раз или не выполнялись.
7)Оценка покрытия с учетом одновременного выполнения (Race Coverage)- показывает выполняется ли какой либо код одновременно - помогает выявить возможные проблемы в частности Race condition
8)Оценка покрытия с учетом операторов сравнения - выявляет встречаются ли в операторах сравнения (>,<) непредусмотренные значения (например 1>1).
9)Оценка покрытия с учетом выполнения таблицы конечных автоматов - определяет выполнились ли все возможные ветки в таблицы конечного автомата...

Собсна оценок покрытия кода как оказалось очень много и тут перечислены далеко не все. Программно реализована тоже малая часть из них (буквально первые 3) да и большой необходимости в этом нет, так что данный список представляет исключительно академический интерес
PS
Спасибо ненашему провайдеру КТ, за баненые ипки, сижу через анонимный прокси, слов нет...

В свежей версии Марафона (http://www.marathontesting.com/Home.html) наконец пофиксали понты с кликом по меню. Проблема заключалась в том, что в жава приложении написанным при помощи Spring Rich Client на гуи морде меню появлялось не сразу а после прошествии определенного времени, а собсна марафон не мог определить момент подгрузки меню и постоянно падал с NPE при попытке клика по неподгруженному меню, решали подобное через sleep(), но периодически,даже при больших задержках падало.В релизе 1,2,1,1 данный баг уже пофиксан. Наконец можем писать нормальные,стабильные автотесты. Всем индусам авторам марафона - большой рахмет

Давно хотел написать о различных надстройках что появились для селениума. В принципе селениум и сам по себе достаточно удобен для написания автотестов для веба, но вот некоторым неймётся уменьшить уровень вхождения для написания автотестов (чем проще писать, тем больше смогут это делать). В итоге получается очень много различных "химер" на базе селениума - например Selenium+Fitnesse или фреймворк для автотестов о котором я хочу рассказать - Tellurium (раньше назывался AOST).
( Read more... )

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

Конечно запись совсем даже и рядом не относиться к работе или направлена на решение чьей либо проблемы, но блог все таки является дневником в первую очередь.
Итак с этого дня являюсь преподавателем кафедры ПОКС свово универа в котором собсна и пишу кандидатскую, данный шаг обусловлен совсем даже не попыткой "поднять бабла" или "уговорили на кафедре" а необходимостью отвести определенное количество часов для кандидатского минимума. Держитесь студенты...
ЗЫ не "развожусь"

• 80% ошибок "зарыты" в 20% процентах кода
• Высокая цикломатическая сложность является маркером бажных мест
• Даже если код покрыт тестами на 100% , примерно 35% ошибок появляется из-за отсутствующей логики,
• еще 40% ошибок возникает при уникальном сочетании входных данных
• остальные являются рапространенными ошибками программистов
  
• Чем дольше баг не фикситься, тем дороже стоит его пофиксить
  

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

Здравствуйте.
Юзабилити - качественный атрибут отражающий то насколько просто\удобно\быстро  можно использовать интерфейс предоставляемый конечному усреднённому пользователю.Итак получилось довольно непонятное определение, попробуем попроще

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

Здравствуйте.

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

Здравствуйте.

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

Тестируемость - довольно сложное понятие, в первую очередь под тестируемостью мы понимаем насколько удобно для тестирования (любого вида тестирования) подготовлено(разработано,описано)

 

Всем доброго времени суток.

Паттерн Singleton или Одиночка очень часто ипользуется