IDDQA

Внимание к деталям

2012-01-10T14:28:00.002+02:00

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

Независимость (возможность принимать самостоятельные решения)
Сложность (в смысле, что на работе вы занимаетесь не только тупым повторением одних и тех же действий)
Взаимосвязанность (Связь между прилагаемыми усилиями и получаемым результатом (вы видите непосредственный итог ваших усилий))

Мало когда работа умудряется соотвествовать всем трём критериям.

В целом идея меня заинтересовала и я прочитал ещё одну книгу Гладуэлла "Переломный момент", в которой описываются причины "эпидемий молвы", мода, преступность и т.д.. Помимо всего прочего (довольного интересного), там есть глава "Сила обстоятельств".

В этой главе Мальком ссылается на криминалистов и утверждает, что увеличение тяжких преступлений связано с мелкими деталями, как-то разбитые стёкла и граффити на стенах:

"Разбитые окна" — это детище ума криминалистов Джеймса К. Уилсона и Джорджа Келлинга, которые утверждали, что преступность — это неизбежный результат отсутствия порядка. Если окно разбито и не застеклено, то люди, проходящие мимо, решают, что всем все равно и никто ни за что не отвечает. Вскоре будут разбиты и другие окна, и чувство безнаказанности распространится от здания с такими окнами на всю улицу, посылая сигнал всей округе. В городе с относительно небольшими проблемами, такими как граффити, мелкое вымогательство, как пишут эти криминалисты, — это такой же сигнал, как разбитые окна, призывающий к более серьезным преступлениям.

Более того, Мальком приводит данные, что метод "борьбы с деталями" был успешно применён в Нью-Йорке, в масштабе всего мегаполлиса.
У меня разу возникли ассоциации с качеством продукта. Ведь качество - величина субъективная (во всяком случае пока что), то есть это мера удовлетворённости заказчика. И всякие мелочи, вроде как грамматическая/орфографическая ошибка, перекошенный текст и подобные им, могут подспутно вызывать чувство дилетанства, даже если всё работает как часики (ну, иногда падает конечно )) ).
То есть, иногда (а может и чаще!) лучше пофиксить 10 лоу, чем один хай? И вот здесь, я прихожу к выводу, что все известные дефекты в продукте должны быть пофикшены.

UPDATE из комментов:

Алексей Булат комментирует...
Вообще, надо стремиться к тому, чтобы пофиксить все известные баги. Но это задача становится маловероятной с увеличением размеров продукта и приближению к сдаче его заказчику. Всегда есть риск, пофиксив 1 дефект открыть 10 новых, и тем самым задержать сдачу.
"Ноун ишьюс" будут всегда, с этим надо смириться, но в тоже время надо стремиться сделать их количество минимальным!!!

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

Приколы нашего городка

2011-12-23T14:55:00.001+02:00

Предистория: Bughunt, событие когда участники пытаются найти как можно больше дефетов за определённое время. Суть в том, что заносится всё, что не нравится (дефект не дефект разбераются позже) и учавствуют все, от инженеров до менеджеров различных рангов и с различным уровнем знания продукта.
Ситуация: После разбора дефектов, тим-лидер программистов - отреджектил дефект Функциональному архитектору.
Rejection Reason: Not a defect, by design (!).
Посмеялись )))

Ротация тестировщиков в команде

2011-11-07T14:35:00.001+02:00

Суть идеи: "Сделать более гибкую команду тестирования за счёт ротации её членов".
Вариантов реализации может быть несколько, примеры:

Один человек постоянно помогает каждому члену команды.

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

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

Каждый человек в команде попеременно становится "гибким".

Преимущества - каждый человек в команде полностью ведает состоянием всех фич в продукте.

Однако, будут возникать ситуации, когда ответственный за область становясь "гибким" и помогая остальным - оставляет свою AOR (area of responsibility) без присмотра. Возникает "проскальзывание", что ни есть хорошо.

Техники тестирования "гибкими" мемберами:

Pair Testing. То есть скорость работы не увеличивается, за то возрастает качество и количество идей.
Работа делится. Увеличивается скорость работы + передача знаний/информации.

Кто-то пробовал нечто подобное? Может немного в другом исполнении. Поделитесь результатами :)

Карта приложения

2011-10-13T17:43:00.003+03:00

Я люблю картинки больше чем текст. Были даже задумки создать уроки "в картинках", таким образом впечатвыть несколько страниц текста в зрительный образ, наверное это особенности видения мира :)
Именно поэтому, хотя нельзя сказать наверняка, (с) Винни Пух возникла идея создавать feature report в виде карты приложения в цвете.
Что для этого нужно:

Создать карту приложения
Определиться, какая часть более важная. Если это квадрат - то сверху можно помещать более важные фичи, если машинка - то двигатель и так далее.
Создать легенду цветов, например: Красный - всё плохо, Жёлтый - плохо, но не всё, Зелёный - номано! Серый - ещё не готово, Белый - готово но не протестировано.
Обновлять статус каждую итерацию.

Преимущества, из тех, что вижу я:

Статус нагляден, на одной картине всё - сколько ещё должно быть сделано, сколько ещё не протестировано, то, что протестировано в каком статусе.
Чёткая приоритезация фич
Можно прикрутить автоматическое обновление статуса, в зависимости от количества дефектов.
Можно сделать это всё средствами Excel

Недостатки, из тех, что вижу я:

Карту надо кому-то создать
Если обновление (автоматическое/ручное), надо чтобы кто-то это делал

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

Вопрос: Кто-то чем-то подобным занимался? Кто-то может подсказать в чём, кроме Excel можно такое мутить?

Спасибки :)

Web-протоколы

2011-10-01T11:31:00.000+03:00

Ознакомился с книгой Кришнамурти "Web-протоколы". Книга очень полезная для тех, кто хочет разобраться как создавались и развивались основные протоколы, использующиеся в Web.

По современным меркам, материал довольно устаревший (издание 2002 года). Однако затрагивает много интересных моментов, над которыми стоит подумать - например, как измерить производительность части сети? Проблемы с утерянными пакетами, перенаправление пакетов по различным маршрутам в зависимости от загруженности и так далее.

Изложение простое, понятное. Под конец даже слегка устаешь от постоянного жевания одного и того же (американ стайл).
Автору (и переводчику) благодарен за то, что наконец-то сформировал картинку работы:

Протокола HTTP поверх TCP/IP
Работу web-сервера и его взаимодействие с ОС
Формирование заголовков запросов и ответов
Что такое метод (GET, POST и др)

То, что стало для меня маленьким "открытием":

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

Технологии настолько сильно рванули вперёд, что это-таки устаревший материал. Надо идти дальше - Rich Internet Applications, AJAX, SilverLight, Flash, Flex.. Мама дорогая..

Посоветуйте, с чего двинуться дальше +)

Собеседования (Перлы)

2011-07-29T14:44:00.010+03:00

Решил записывать перлы кандидатов :) Итак:

Пару фраз о своей работе на английском:
"I jobed in casino"

Три основных принципа объектно ориентированного программирования (собрано из ответов трех кандидатов):
- обобщенность - типа все обобщено, никакой конкретики :)
- наследие - это всегда важно
- полиформизм - многоликий будда :)

Для чего нужен FTP:
- для сопряженности процессов - фак мой мозг

Что такое указатель (в C++):
- это метка по которой программа прекратит запрашивать новые данные

Вычислить n! (C++):

Весь синтаксис сохранен!

Вариант №1:

 main() {
 cin>>n1;
 cin>>n2;
 cin>>n3;
 factor = 1*n1*n2*n3;
 }

Вариант №2:

 main(){
 for(n=1;n++) { 
 factor = n*n*1; }
 }

Собеседования

2011-07-26T21:43:00.002+03:00

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

Что такое полиморфизм - правильное определение я услышал всего один раз (от бывшего студента, который его не успел забыть), а вот объяснить что это на самом деле такое уже не смог никто.
Самые прикольные ответы:
- это возможность в программировании решать одну и ту же задачу разными способами (и был дан пример математической задачки, которую действительно можно решить по-разному)
- это множественное наследование (наследие, как сказал один из кандидатов) - самый короткий ответ :)
- это что-то связанное с виртуальными функциями (уже горячо :) ) - опа! услышав такое я даже заинтересовался кандидатом, но вот что такое виртуальная функция объяснить мне уже не смогли
Что такое SSH (да, я знаю что это не связано с программированием) - ни один! из кандидатов не смог ответить на этот вопрос
Самые прикольные ответы:
- это веб-сервер о_0
- это программа
- это что-то связанное с linux (ага!)
Что такое структура данных (как тип данных в программировании) - всего один правильный ответ.
Самые прикольные ответы:
- это последовательность команд вводимых в компьютер о_0
- это последовательность вызовов функций в коде
Что такое интерфейс (в программировании) - кое-то даже давал правильный ответ :)
Самые прикольные ответы:
- это что-то связанное с коллекциями (имелось ввиду коллекции в Java)
- это список параметров функции - тоже весьма короткое определение
Отсортировать одномерный массив простых чисел - справился всего один! кандидат. Либо вычислить n!, где n - простое число - многие даже не начинали решать эту задачку, а сразу говорили, что не знают как это делать (правда один раз мне показали практически правильный код :) ).
Что такое xml и для чего он нужен - многие могли сказать, что это расширенный язык разметки - а вот что он размечает и чем он расширен - большинство ответить не могли (были правда и те, кто давал весьма корректные ответы на этот вопрос)
Самые прикольные ответы:
- xml используется для написания парсеров, когда не хватает возможностей html
- xml используется для структурирования информации и документов - чтоб она хранилась в упорядоченном виде
Что такое статическая переменная (поле) - ни одного правильного ответа, большинство даже не пытались ответить
Самый прикольный ответ:
- статические поля нужны для того, чтоб к ним можно было обратиться извне класса
Новинка! Что такое инкапсуляция - некоторые кандидаты отвечают правильно, большинство просто не могут ничего ответить, но в последние пару дней мне стали говорить один и тот же прикольный ответ:
- это когда один класс встроен в другой, другой в третий и т.д. - как матрешка (почему-то всем нравится упоминать матрешку :) )

Вот так вот грустно - а среди кандидатов были: Delphi программисты из гос организаций (с опытом работы более 2х лет), php фрилансеры с солидным запасом готовых проектов, один Java ME разработчик, парочка выпускников вуза с красными дипломами.

IT JAM Conference

2011-07-14T11:55:00.011+03:00

А у нас тоже конференции всякие проходят! :-)

You have an excellent opportunity to become a speaker or to share an experience with best speakers & guru in IT-development & gathering developers from all-over Ukraine!

Java
.Net
PHP (different CMS and web-development in a whole)
Mobile
Testing
Agile, Management and Trends

The call for best speakers in Mobile, Java, web-development, .NET, QA has already opened http://it-jam.com.ua/become-speaker

You can find more information about IT Jam on http://it-jam.com.ua/

Шаблоны тестирования: "Файловый диалог"

2011-06-16T11:19:00.032+03:00

Решил сделать сборник "Шаблонов Тестирования" (можно ещё его на software-testing.ru потом закинуть)..

Суть: Описать наиболее полно кейсы для тестирования стандартных диалогов, фишек и др.

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

Начну с "Файлового диалога", это который появляется, когда пытаемся сохранить файл.

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

Updated! Спасибо участникам форума ;-)

Issue	Example
Root disk	C:\
Short path to a file	C:\tmp
Relative path to a file
Long path to a file (a lot of nested folders)
UNC path 1. Shared folder 1.1 Restricted permissions 1.2 Long path on other machine 2. Administrative access (c$, d$ ..)	\\machine_name\shared \\machine_name\d$\tmp \\192.168.1.2\shared \\192.168.1.2\d$\tmp
Mapped disk	Z:\ = d:\temp\test Y:\ = \\machine_name\d$ X:\ = \\192.168.1.5\shared
Use the path with "http://, ftp://, ..."	http://google.com
System variables 1. Standard 2. User-Defined	%TEMP% %my_variable%
Set file's filter to .	Try to open unsupported file
Set file's filter to *.ext	Type full name of the file with another extension (image.jpg)
Archived with the password	If allowed
External Storage	HP Quality Center,.. if application supports this.
I18N (name of the file and folder)
The name of the file is short 1. Empty 2. 1 symbol (digit/a-Z/special char)
The name of the file is long ( 16/32/64/128/256/... symbols )
Existed file	Save into (with the same name)
Space in the file name	Prog is My! I ne volnuyet
The name with different special chars
File name with the specific for OS chars and reserved words	\\, ., .., reserved names
User's Permissions	Administrators, Guests, Users, Power Users
Folder\File's Permissions	Read Only, Hidden, Normal
Locked file	Opened by another application
Corrupted file

1 апреля

2011-04-01T17:10:00.002+03:00

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

IT-сфера - область для "своих", никто извне не придёт посмотреть, а как тут у вас шутят.. а зря :)

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

Ликование сотрудников, паника местных HR как нельзя хорошо вписались в атмосферу праздника. "Улыбайтесь, вы таки в Одессе!".

SHCameraApp (Windows Phone 7).

2011-02-15T17:15:00.000+02:00

Вот уж никогда не думал, что смогу первым додуматься до чего-нибудь...
Собственно наткнулся на тему, о разработке альтернативной программы для фотографирования под WP7. По умолчанию WP7 не дает доступа к фотокамере, но тут описан способ как это обойти.
Собственно оригинальная тема на xda. Программа имеет один существенный недостаток - она умеет делать снимки только 640x480. Любопытства ради, потратил сегодня 40 минут и обошел эту проблему (никакой документации понятное дело нет - все методом тыка).

namespace CameraApp
{
public partial class MainPage : PhoneApplicationPage
{
PhotoCamera camera;

public MainPage()
{
InitializeComponent();
camera = new PhotoCamera();
cameraVisualizer.SetSource(camera);
camera.Initialized += new EventHandler(camera_Initialized);
}

private void button1_Click(object sender, RoutedEventArgs e)
{
//список всех разрешений для камеры
foreach (CaptureResolution res in camera.GetAvailableResolutions())
{
listBox1.Items.Add(res.Height.ToString() + "x" + res.Width.ToString());
}
//ну и выбираем самое высокое - для моего аппарата 5MPix
camera.SetResolution(camera.GetAvailableResolutions().Last());
camera.CaptureImage();
}

void camera_Initialized(object sender, EventArgs e)
{
camera.ImageAcquired += new EventHandler(camera_ImageAcquired);
camera.ImageSavedToDisk += new EventHandler(camera_ImageSavedToDisk);
}

void camera_ImageSavedToDisk(object sender, ContentReadyEventArgs e)
   {
//собственно и все - неясно как до этого никто не допер
//картинка сохраняется в IsolatedStorage приложения - дальше делай с ней что хочешь
this.Dispatcher.BeginInvoke(() =>
{
listBox1.Items.Add(e.RelativePath);//тут у нас имя файла
   });
}

void camera_ImageAcquired(object sender, EventArgs e)
{
   //тут чего-нибудь можно вывести... тоже через Dispatcher - иначе вылетит исключение
}

}

Собственно сразу же про это и написал (тыц)... Вот она новая - система, все приколы познаются сейчас...
ЗЫ: последствия моей работы - SHCameraApp
ЗЗЫ: автор оригинального проекта остановил разработку после моего релиза, жаль - именно он сподвиг меня на шевеление мозгами...
Если кто вдруг хочет поискать баги, так и не стесняйтесь.. ;-)

Меньше слов - больше смысла

2011-02-11T12:30:00.021+02:00

Прочитал на software-testing.ru обсуждение перевода статьи Роба Лэмберта "Меньше слов - больше смысла". Заглянул в саму статью. Автор проводит параллели между написанием прозы и тест-кейсов..

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

Пример для демонстрации Компактности в прозе (практически классика):

Он кивнул своей собственной головой в знак согласия, подтверждая сказанное.

Достаточно написать - "Кивнул", то, что это его голова - понятно, то, что кивают в знак согласия - тоже не секрет и так далее.

в тестировании

Дважды кликните на ярлыке программы "Облако", когда программа запустится, запишите новый скрипт
Запустите процесс проигрывания скрипта, для проверки правильности записи и дождитесь пока процесс завершится
Открывается репорт, проверьте все строки на предмет грамматических ошибок

Запишите новый скрипт
Проиграйте
Проверьте грамматику в репорте

Следуем второму пункту Направляющие, результат:

"Проверить грамматику в репорте".

У нас в компании уже несколько лет внедряется идея "направляющих" тестов. Но что, если пойти ещё дальше?

Не писать тесты? Именно, не писать) Рисовать! Не в смысле рисовать какие действия надо совершать, типа бежать и рисовать человечка, нет. Записать, что именно проверять в виде графа, дерева. На создание таких деревьев меня вдохновила програмулинка для записи идей при брэйншторме - XMind. Результат мне нравится простотой. Человек, взглянувший на такое дерево "сходу" может подкинуть парочку идей.

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

XMind - для составления тест-кейсов не очень удобен, отсутствуют циклические ссылки.. да и вообще не приспособлен. Может есть более удобные подобные программки, но даже здесь: можно сворачивать детали "узлов", получается санити; можно объединять тесты в общую схему, в идеале даже в полную схему продукта; можно каждый цикл регрессии отображать в графическом виде, по областям.. Может написать подобную програмулинку, заточенную под тест-кейсы? :)

Психология в тестировании

2010-12-15T15:28:00.007+02:00

Честно признаюсь, я не знаю, есть ли какие-то тренинги по умению правильно рассказать о проблеме или, может, негласная или гласная культура о том, как приносить «плохие» новости. Нужна ли такая культура? Из того, что я вижу – нужна, и чем дальше, тем острее ощущается её нехватка.

Изначально, когда программисты сами тестировали свои творения, баги найденные в процессе никаких особых психологических проблем (кроме времени, потраченного на поиск и исправление) не вызывали. Что-то упустил, пока проверял работу, нашёл проблему, изловил н-ое количество жучков и выпустил продукт. Кое-что нашли заказчики, но все знают, если написать программу без багов, то единственное, что она сможет – напечатать «Hello, World!», посему дефекты от заказчика хоть и не приятны, однако от них никуда не денешься, способа кодировать без багов пока что не придумали.

Идеи «всё в одном флаконе» стали именно теми дрожжами, на которых программы разрослись, а их создание и поддержка превратилась в нетривиальную задачу. Ко всему прочему добавим бурное развитие компьютерных технологий, в результате чего варианты использования создаваемых систем увеличились на порядки. Где-то здесь родилось тестирование, как отдельный вид деятельности.

Появились первые тестировщики, и многие программисты искренне не понимали, зачем они нужны, только от работы постоянно отвлекают, задают кучу вопросов и приносят баги. Ну есть в программе баг, может заказчик никогда с ним и не столкнётся? Если столкнётся – пофиксим, зачем тестировщики? Не понимание. Это была первая проблема.

Те времена быстро прошли, важность предоставляемой информации оценили по достоинству, но сколько бы не кричали добрые языки о победе светлого, вечного и крайне полезного – тестирования, сколько бы не верили в это сами тестировщики, в большинстве своём ситуация остаётся прежней. Человек, приносящий дурные новости по умолчанию не может восприниматься адекватно.

Отторжение этой, не самой приятной части процесса разработки ПО, немного видоизменилось. Теперь программисты смотрят свысока на братьев своих меньших. Это отношение можно кратко охарактеризовать так: «Если ты весь такой умный, что ж в программисты не пошёл?». Очень часто это в определённой мере справедливо – технический уровень подготовки QA ( и требования к кандидатам) ниже чем у программистов. В мануальном тестировании «чёрным ящиком» уж точно. Это вторая проблема.

Небольшое уточнение: Предвижу комментарии по типу, очень много тестировщиков имеют уровень подготовки не ниже чем у программистов. Согласен, что они есть, но чтобы очень много, не соглашусь.

С давних времён известно, что не сама информация оставляет «неприятный осадок», а способ - как именно её преподнесли. Анекдот: «Матч по легкой атлетике СССР - США. Бегут двое. Американец победил. Советские газеты сообщили: "В беге на 100 метров советский спортсмен пришел одним из первых. Американский бегун был предпоследним"». Таких примеров можно привести множество. Психологически нелегко принимать сведения, о допущенных ошибках и уж тем более от человека, кто технически менее грамотен. Это третья проблема.

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

Пример из жизни, у нас цикл регрессии, захожу в кубрик программистов, здороваюсь со всеми, ребята отвлеклись, ждут, к кому пришёл с проблемой?

Я: – Серёга, я к тебе..

Программист: – Блииин, в какой фиче?

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

По поводу психологических проблем от меня два совета:

Хвалить программистов тоже надо (когда есть за что), а не только приносить им баги. Писать письма с менеджерами в СС, о том, что было в фиче хорошо, а не только в какой области баги, а где их нет. Также лично приходить и рассказывать то, что вам действительно понравилось в реализации фичи.
Не стоит проводить все проблемы через баг-трекер, иногда стоит «подарить» их и, если есть возможность, проследить за исправлением. Так сказать для развития неуставных отношений, в конце концов мы ж не за статистику боремся, а за качество ;)

Надеюсь, что тренинги для развития умения преподнести проблему в скором времени появятся, и сформируется «культура» как рассказать о баге, чтобы программист остался доволен - хоть поговорить было приятно :)

UPDATE из комментов:

BEFORE: Но самое большое зло, это конечно же метрики :) Особенно, если они завязаны на количестве багов, что постоянно провоцирует «гонку дефектов».

AFTER: Но самое большое зло, это когда метрики, по которым оценивается работа тестировщика, всецело завязаны на багах, что постоянно провоцирует «гонку дефектов».

Конечно же не имелось ввиду, что МЕТРИКИ - это зло.

Узкая специализация в тестировании

2010-10-09T22:06:00.015+03:00

После обсуждений предыдущей статьи решил расширить и углубить один из её постулатов. А именно:

Разделение труда является причиной повышения общей производительности труда организованной группы специалистов (синергетический эффект) за счет:

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

Постулат был взят из википедии (что-то я начинаю её недолюбливать) как данность. В результате другие преимущества узкой специализации, хоть и были отражены в модели SQA-MQA-JQA, но их связь с этим постулатом осталась неявной.

Собственно узкая специализация тестировщиков это:

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

Неравнозначность выполняемых работ
- Позволяет распределить работу: Ответственную и сложную – матёрым, простую – новичкам. Также, упрощает рекрутинг.
- Практически всё тестирование проекта зависит от одного человека, а не от 4-5-ти.
- Нужно правильно распределить людей

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

Если кто-то может добавить пункт, или подпункт, или недостатки буду рад посодействовать :)

Рефакторинг фирмы, специализирующейся на тестировании

2010-10-03T10:24:00.029+03:00

Описанное ниже, вряд ли подойдёт аджайл-проектам.
Хочу на всякий случай попросить прощения у людей, кого заденут выражения "дешёвый" сотрудник, не корысти ради, а токмо что объяснить идею.

Когда встречаю объявления типа: "В связи с расширением штата сотрудников, требуется..", "Молодая развивающаяся компания ищет.. " и подобные им, сразу представляю, как маленькое село вырастает в пгт, оно, в свою очередь, в город, а тот – в мегаполис.

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

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

Такое себе – нагрузочное тестирование. Может стоит для анализа проблем фирмы нанимать перформанс инженеров? Почему бы и нет.. Интересно, были прецеденты?

Психологи говорят, что многие проблемы человека уходят корнями в его детство, этот же допущение верно и по отношению к организациям:

Детство. Много воды утекло с тех пор, как руководство осознало необходимость проверки продукта до его продажи и постановило – создать отдел тестирования. Сначала наняли аж двух тестировщиков, а когда всплыло, что продукт не такой совершенный (как уверяли программисты) ещё к ним тим-лидера (ТЛ) и гастрабайтера, пусть тоже будет. ТЛ распределил области ответственности между тестировщиками и понеслась, каждый пишет себе план и выполняет определённый объём работ, рапортует менеджеру, тот – дальше. Все при деле.

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

Стоп! Вы заметили проблемы, которые тянутся из "детства"?

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

Модель работы тестировщика, пришедшую из "детства" фирмы, назовём "вертикальной моделью" и она порождает проблемы при увеличении штата сотрудников (список проблем см. выше, можете расширить и углубить). Схематично можно представить так:

Естественно, в каждой фирме свои особенности, что-то из "серой" области переходит в "зелёную", не суть.

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

Давайте рассмотрим несколько "постулатов":

"Дорогой" сотрудник должен делать "дорогую" работу. Как только это правило нарушается – фирма теряет деньги. Если "дешёвый" сотрудник делает "дорогую" работу – фирма теряет в качестве.
Разделение труда является причиной повышения общей производительности труда организованной группы специалистов (синергетический эффект) за счет:
a. Выработки навыков и автоматизма совершения простых повторяющихся операций
b. Сокращения времени, затрачиваемого на переход между различными операциями
20% людей делают 80% работы - принцип Парето.

Основываясь на всех этих постулатах, создадим модель распределения труда тестировщиков, которую так и назовём "горизонтальная модель":

Senior QA (SQA) – это "мостик" между командой тестировщиков и практически всеми участниками процесса разработки, он не выполняет тесты, всё его время направленно на подготовку непосредственно процесса тестирования. Он тесно общается с ответственным за создание требований к продукту, а когда они созданы (FA) и проверены (им же), внесены возможные коррективы, он переключается на структуру и дизайн будущего приложения. Общается с ответственными за это дело архитекторами и дизайнерами, пишет тест-план. После того, как разработчики приступили к кодированию, SQA занимается написанием тест-кейсов для всех фич продукта. Долгими вечерами общается с девелоперами (пивко?) для получения целостной картины работы приложения и написания подробных тест-кейсов. Знание различных методик тестирования позволяет оптимизировать набор тест-кейсов, а "подсмотренный" у программистов код – не пропустить ничего действительно важного. Такой подход к работе позволяет SQA целиком сосредоточиться на написании тест-кейсов, создания разнообразных шаблонов, как тест-планов, так и шаблонов тестирования стандартных диалоговых окон и др. Подобными шаблонами можно делиться с SQA других команд, а также черпать идеи из чужих шаблонов.

Подробные тест-кейсы являются той квитэссенцией знания, выжатой из всеобъемлющего понимания продукта, опыта SQA и бест-парктисес соседних команд (либо мировых бест-практисес).

Middle QA (MQA) – этот человек уже своеобразный "мостик" между SQA и JQA. Он подготавливает возможности для выполнения тест-кейсов. Настраивает тестовое окружение: конфигурирует сервера, пишет необходимые AUTs (Applications Under Test), устанавливает ОС. Занимается автоматизацией (если решено какую-то часть продукта автоматизировать), изучает дополнительные программы (Selenium, QTP, AutoIt, BOM check, InputDirector и др.). После приобретения опыта в такого рода "тестировании", MQA уже накопил достаточное количество образов (ghost, acronis..) как ОС так и серверов. Он занимается оптимизацией использования машин и ресурсов. Подключается к выполнению тест-кейсов в случае необходимости.

Junior QA (JQA) – по сути, именно этих людей называют тестировщиками. Их основная обязанность – выполнение тест-кейсов, описание багов, создание отчётов, проверка починенных дефектов. Для большей эффективности работы, они мониторят список всех дефектов (если над продуктом работает ещё команды, например, из других стран). И если кто-то думает, что SQA выполнит свои тесты лучше чем JQA, то это совсем не обязательно так.

Принцип "Матрёшки": Человек приходит в тестирование без опыта. Знакомится с жизненным циклом дефектов, выполняет тест-кейсы (прошу заметить, очень грамотные тест-кейсы), тем самым обучаясь. Если может – дополняет их. Получает опыт. Из JQA переходит в MQA. Подготавливая тестовое окружение, он уже может учесть все нюансы, с которыми сталкивался в процессе тестирования. Получает новый опыт в программировании либо использовании программ автоматизации (если таковая присутствует на проекте), глубокие знания в конфигурировании серверов и операционных систем. Переходит на позицию SQA – тут так вообще не паханное поле для развития, но так как он был и JQA и MQA, при написании тест-кейсов он учитывает не только теорию, но и весь свой предыдущий опыт.

Естественно, не все смогут пройти путь от JQA до SQA, получается своеобразное "просеивание" кадров, это позволяет нанимать на позицию тестировщика людей, которые хотят попробовать себя в тестировании, возможно на данный момент не квалифицированны или существует серьёзные пробелы в знаниях, но ведь никогда не знаешь – кто идеальный SQA? Им будет у кого учиться, и если есть способности – фирма вырастит отличного специалиста.

Теперь разберём, как решаются, описанные выше проблемы "вертикальной модели":

Где взять столько спецов?
Действительно спецом должен быть только SQA, фирме на помощь приходит принцип "Матрёшки", а также "просеивание" кадров, что позволяет легче найти такого сотрудника. Он – лицо команды (человек-команда). То есть, если в продукте пять областей ответственности, для качественного тестирования нам надо не пять мега-пацанов, а одного.
Хорошие спецы хотят хороших денег.
SQA – должен получать много. Фирма может себе это позволить, всё-таки он один, а не их пять на проект. Ни стартап ни большая фирма с "вертикальной моделью" организации не сможет "перекупить" нашего парня!
Текучка.
a. Текучка SQA – крайне нежелательна, поэтому з/п у него серьёзная, конкурентная. Все усилия HR направлены в основном на них: Командировки на конференции, тренинги, бонусы, личные пожелания.
b. Текучка MQA – неприятна, но не смертельна. HR сюда тоже заглядывают – бонусы, тренинги и др.
c. Текучка JQA – вполне себе приемлемое положение, возможно даже первоначальный найм на контракт, скажем год, как себя покажет, так и примем решение, что делать с ним дальше (Если работа человеку понравится, он докажет, что годен быть MQA).
Эффективность сотрудников.
a. Каждый концентрируется только на своей области, что позволяет создавать оптимизирующие наработки (шаблоны, вспомогательные программы и др.).
b. Перебрасывание серьёзного спеца на работу с начальными этапами разработки (например, тестирование требований), позволяет "предупредить" многие баги и тем самым сэкономить время и деньги фирмы.
c. SQA не тестирует, то есть "дорогой" сотрудник не делает "дешёвую" работу.
Потеря знаний о продукте, вместе с уходом людей.
a. Во-первых, теперь люди представляющие "полную картину" продукта, редко уходят в другое место.
b. Во-вторых, все знания запечатлены в подробных тест-кейсах, в которых учтены и особенности продукта, особенности кода (или просто внутренней структуры приложения), методы оптимизации (например, pairwise). Так что, если вдруг фирма потеряет главного бойца последней линии обороны, как минимум будут проведены качественные регрессионные тесты. Некоторые продукты разрабатываются десятками лет и имеют уже 11-ю версию :)
Постоянное переключение между задачами.
a. Каждый сотрудник работает в своей области.
b. SQA переключается, но не туда-сюда по нескольку раз в неделю, а последовательно, от тестирования требований, к дизайну и разработки, потом на написание тест-кейсов, это нормально.
Качество тестирования.
Качество тестирования повышается за счёт пунктов 3-6.

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

На более качественные услуги фирма тратит меньше средств.
Самый дорогой сотрудник работает вне зависимости от задержек билдов или каких-либо холдеров, так как не занимается непосредственным тестированием (MQA частично тоже). В случае задержек или проблем с билдом "простаивают" только "дешёвые" сотрудники.
HR концентрируют усилия только на SQA и частично на MQA, что важно при большом количестве сотрудников, ибо никогда нельзя угодить большинству. В "горизонтальной модели" этого и не требуется.
Упрощённый рекрутинг. Если написаны подробнейшие тест-кейсы (MQA помогает расписывать их, добавляет названия машин, ОС и серверов с логинами и паролями), машины с нужными ОС и серверами настроены, часть работы автоматизирована, то прогонять оставшиеся тест-кейсы может любой человек с улицы, продвинутый пользователь ПК. А там уже курируем их, наблюдаем, делаем выводы.
Фирма не вкладывается в JQA и тем самым не "связывается" с сотрудником, и тем самым не теряет лишние деньги. JQA выполняют определённую работу, могут свободно изучать все процессы в фирме, присматриваться к работе более старших (по званию) коллег и решить, нравится – не нравится. Они выполняют грамотные тест-кейсы, тем самым уже самообучаясь. Имеют доступ к любым внутренним тренингам (проводимые MQA и SQA для каких-то своих нужд). Изучают баг-трекер, жизненный цикл дефектов, то есть основы, понравилось – пошёл дальше, здесь уже фирма их "подхватывает" и начинает активно помогать в дальнейшем развитии. По себе могу сказать, что первый год в новой сфере приносит столько нового, что никаких тренингов и не нужно, если работа нравится – прёт и само по себе. Человеку свойственно развиваться и обучаться.
По з/п я склоняюсь к соотношению JQA/MQA/SQA : 1 / 2-2.5 / 4-6.
Есть ещё такая идея – создать "буфер" исполнителей, например, цикл регрессии вообще не требует участия SQA, в основном это запуск автоматических скриптов (если такие имеются на проекте) и ими занимается MQA и ручной прогон набора тест-кейсов, для него можно подключить JQA из "буфера" на определённое время. Чем-то напоминает аутсорсинг :+) . Хотя вполне можно справляться и своими силами. Зависит от проекта.

Недостатки:

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

ВЫВОДЫ:

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

UPDATE:
Как стало понятно из коментов, мой стиль изложения окончательно запутал думающие умы. Сравнение для большей наглядности, SQA - не является бюрократом, который сидит и следит как вся команда пашет.. :)))
SQA фактически "рисует машину на бумаге" он её создаёт, а остальные только занимаются тем, что делают заготовки из железа, пластика (MQA) и собирают всё это вместе по шаблону (JQA). Когда прикручивается новая фича, SQA дорисовывает её, используя всякую там оптимизацию и приоритезацию, чтобы всем остальным было проще ;-) Вот функциональный архитектор у программистов, отдалённо напоминает SQA в отделе тестирования, можно и его обозвать бюрократом и наехать, мол ничего не делаешь хад!

Недокументированные функции

2010-09-07T13:26:00.010+03:00

Бывает звёзды становятся таким образом, что в окружённой нашим внимание программе, открываются новые возможности. Насколько это "хорошо", "плохо", "допустимо", "профессионально"? Сказать объективно сложно, найдётся множество мнений - мол, иногда с помощью таких вот "возможностей" можно сделать что-то, что не получается сделать обычным способом, моё мнение - это недопустимо. Таких функций (возможностей сделать непредусмотренное) просто не должно быть, это - дефекты.

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

Если функции не поддерживаются, значит они и не тестировались.. Верь после этого производителям ПО! :)

UPDATE: Нашёл ответ на этот вопрос! Стандарт ISO 9126 категория Функциональное тестирование, под-категория Защищённость (security) - программа должна делать только то, для чего предназначена и ничего сверх того.

Новая версия PinGUI, собираем идеи на будущее

2010-07-01T18:47:00.012+03:00

Итак, выложена обновленная версия программы - качайте с соответствующей странички ;)

Список изменений таков:

Пофикшено некорректное отображение Notes(надеюсь уже совсем пофикшено :) )
Добавлена возможность управления службами (services) удаленной машины.
Всякие мелочи...

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

В контекстном меню для параметров машины - Copy to Clipboard.
multi-select для параметров внутри одной машины
Горячие клавиши
Поддержка *nix систем (через ssh)
Ну и доделывать то, что пока не доделано до конца :)

Если у кого-то есть свои интересные предложения и замечания - милости просим в комменты ;)

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

Обновление PinGUI

2010-06-23T09:46:00.003+03:00

Вышла новая версия PinGUI (спасибо Серёга! ;-) ).

Список изменений

Пофикшено некорректное поведение кнопок Remove selected и Edit selected
Исправлено отображение заметок для оффлайн машин
Добавлено имя пользователя для списка запущенных процессов

Планируемые фишки:

Создание новой вкладки со списком запущенных служб (services) на удалённой машине, с возможностью запускать и останавливать.

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

Отдельная благодарность анонимным тестерам за проделанную работу ;)

PinGUI - програмка для управления лабораторией машин

2010-06-21T10:19:00.006+03:00

Сотрудник на работе сотворил програмку для управления лабораторией машин. Творение в стадии Альфа-тестирования, для заинтересованных - баги или предложения новых фич публикуем в комменты ;-) Удобная штука, особенно когда лихорадочно ищешь свободную машину, или машину с нужным билдом, или какой-то конкретный снэпшот вмваре-машины. С целью предотвратить крики:
- У кого есть предыдущий дроп??
- У меня!
- Какая ОСь?
- Ммм, глянь сам, я не помню, vmrndapp01 - пароль стандартный.
- А не, там 2008-я, Вопрос остаётся открытый! Что, ни у кого нет??

Ну или что-то типа такого:

- Удалённая машина при загрузке зависла, как её перегрузить? Или просто убить какой-то определённый процесс??
- Как как, PinGUI-ем! ;)

Програмку можно найти слева в меню, название PinGUI. Или по ссылке PinGUI. Если кто-то хочет написать хоть какую-то документацию по програмке, так мы вам всегда рады.

Total Commander. Регулярные выражения

2010-04-28T14:42:00.022+03:00

Проверял ребрэндинг продукта.

Одна их задач.

Свойства *.dll, *.exe, *.ocx файлов продукта должны содержать корректные значения для селдующих элементов:

Product version
Product Name
Copyright
Company
Author

Исходные данные:

Тысячи файлов продукта с разнообразной глубиной вложенности каталогов и подкаталогов.

Решение:

Сначала попытался использовать Explorer. Поколдовал с настройками колонок, и они таки начали выводить нужную инфу. Но возникла проблема: при переходе в другой каталог настройки сбрасывались. В добавок к этому безобразию, просматривать все каталоги и выписывать пути к файлам ну вообще не улыбалось. Explorer был предан анафеме.
Выручил Total Commander и его поиск с использованием плагинов. Хвала shelldetails. Огромное количество условий поиска, из которых мне больше всего понравились регулярные выражения + возможность искать заданный текст внутри файлов каталога, прям бальзам на израненную несовершенством Explorera душу простого куа. Однако и он не "5-й элемент" :(
Пустые строки искать отказался.. Поспрашивал на форуме командера, народ с удивлением признал, что пустые строки shelldetails не ищет. Но даже это не умаляет достоинств столь качественной и удобной тулзы.

КуА-Минь.

P.S: Commander также позволяет создавать пользовательский набор колонок и даже сохраняет его при сменах как каталогов так и дисков.

Ответ на вопрос из комментариев :)

Как была решена проблема пустых строк?

Руками, да, да, ручками..

Отфильтровал вывод файлов ("Вид->Фильтр"), показывать только *.exe, *.dll, *.ocx
"Вид->Пользовательский набор колонок", настроил колонки на нужную инфу (плагин shelldetails)
Отсортировал файлы с пустыми данными
Выделил их (вручную)
Выполнил из командной строки cm_CopyFullNamesToClip (на форуме подсказали, сохраняет полные пути к выделенным файлам в буфер обмена)
Вставил в блокнот, сохранил и перешёл в другой каталог

Получилось дольше чем просто поиском, но не смертельно. Минут за 30 управился.

Приоритет дефектов

2010-04-02T09:32:00.020+03:00

Приоритет дефекта штука капризная и понимается QA и RnD по-разному. Потому как смотрит тестер глазами юзера в одну сторону, а девелопер своими программистскими - в другую.

Не ограничивая общности примем за основу такую классификацию дефектов:

Critical (Show Stoper, QA Holder, Simple)
High
Medium
Low

Разберём шаги по определению важности бага с позиции QA:

Critical QA Holder: Критикал Куа Холдер - второй по максимальности приоритет бага, блокирующий работу одного-двух QA. Например, тестер должен протестировать создание отчётов. Выбирает в меню (или иным каким способом) "Создать отчёт" и ничего не происходит, либо приложение крашится. QA не может начать тестирование, хотя остальные области работают.
Critical simple: Обычный критический дефект - максимальный приоритет дефекта, связанный с потерей данных, вредом операционной системе, разнообразными крашами. Обязательно должен быть пофикшен до релиза продукта. Например, при попытке распечатать отчёт из тестируемой программы, при не установленном принтере "виндовс" крашится, выбрасывая "blue screen".
High: Хай - приоритет дефекта, связанный с нарушением логики работы программы, также критические дефекты с лёгким "обходным путём" (workaround). Должен быть пофикшен до релиза продукта. Например, поиск по странице выдаёт неправильные результаты.
Medium: Медиум - приоритет дефекта, связанный с неудобствами при работе с программой. В коммерческих продуктах их быть не должно. Например, не работает autocomplete фича в вижуал студии.
Low: Лоу - приоритет дефекта, связанный с незначительными неудобствами, мелкими недоработками. В серьёзных коммерческих продуктах их быть не должно. Например, текст описания слегка сдвинут. Пропущенная запятая в тексте хелпа.

Для полноты картины:
Show Stoper: Шоу Стопер - баг, с которым нельзя релизиться ни в коем случае. Например, проблемы с инсталяцией и нет никакого обходного пути. Программа не устанавливается и всё тут. В результате кастомеры не могут начать работу.
Regression defect: Регрессионный дефект - новый баг на старую функциональность. Version regression - дефекта не было в прошлой версии. Build regression - дефекта не было в прошлом билде. Например, простенький калькулятор отлично складывал числа, его релизнули. Решили в новой версии прикрутить возможность считать логарифмы, он перестал складывать. Регрессия на версию.

Определение приоритета бага имеет ещё один параметр: сколько человек могут с ним столкнуться.

Типа тестеры шутят :)

2010-03-30T20:36:00.001+03:00

Если в программе пофиксить все баги, всё что она сможет - сказать "Hello World!" ))

Дефект (баг), спецификация, фича

2010-03-27T08:55:00.011+02:00

Defect (bug): Дефект - не предусмотренный результат при работе программы. Обычно "не предусмотренный" имеет негативный оттенок, то есть: хотел получить одно, получил другое. Хотел, чтоб программа работала (для этого и запустил её), а она покрашилась, хотел получить сумму, а получил результат деления и так далее.
Бывают ситуации, когда неожиданное поведение программы имеет позитивный оттенок, например, хотел получить таблицу, а программа не только отображает её, но и может сортировать столбцы. Такие баги могут расцениваться как фичи (features).
Feature: Фича - отличительная особенность программы от других, вообще функционал программы - это совокупность фич. Фича также отличительная особенность одной и той же программы от прошлого релиза. Например калькулятор. Функционал первой версии - умеет делать основные операции с числами. Фичи второй версии - умение брать логарифм и возводить в степень и так далее.
Баги аля фичи. Рассмотрим пример выше. Программа должна выводить данные в виде таблицы. Девелоперы использовали стандартный компонент, в котором "зашита" возможность сортировки. С одной стороны - не предусмотренный результат при работе программы, с другой - ничего "плохого" в нём нет. Тестеры вправе сказать, что это дефект, такая "фича" - потенциальный источник проблем. Поэтому предусмотренность результата определяют спецификации.
Specification: Спецификация - это документ, в котором пункт за пунктом расписано: что должна делать программа, какие формулы использовать, как выглядеть и так далее. Набор требований к будущему продукту. Например, калькулятор. В спецификации может быть записано: результат работы должен выводиться в правом углу поля вывода результата. Поле вывода результата должно находиться между меню и кнопками.
Но обычно до таких подробностей не доходит, программы огромные. И программисты и QA их видят по-своему: одни изнутри, другие - снаружи. Потому и идёт борьба за качество продукта :)
По спецификации QA составляют план тестирования.
Test plan: План тестирования - документ, в котором QA расписывает как, собственно, он собирается тестировать продукт. Операционные системы, на которых будут проводиться тесты, какие области планируется проверить (функционал, юзабилити, айтинэн, UI и т.д.), какие тест-кейсы будут использоваться и др.

Терминология тестирования (MB, I18N, L10N)

2010-03-25T07:14:00.020+02:00

Продолжаем-с :)

MB chars (multi-byte chars)

MB chars (мультибайтовые символы) - символы, для отображения которых используется не один байт (как в стандартной ASCII), а несколько, обычно два. В английском алфавите - 26 буквы, ну ещё специальные символы, псевдографика, но и с учётом этого, 255 символов (1 байт) для кодировки - вполне достаточно.
Другое дело иероглифы, коих в китайском, японском и др. языках - десятки тысяч. Для таких случаев, где не хватает 255 значений для кодировки всех символов языка, используют мультибайтовые кодировки: один символ = двум байтам.
Пример, back slash (\) в ASCII таблице имеет норме 92. Если мультибайтовый символ закодирован числом, скажем х015С = 1*256 + 92 = 348 , тогда программа не адаптированная к MB, начнёт разгребать всё это добро побайтово, и байт со значением 92 переведёт в обратный слэш. Ну и скорей всего тут и загнётся :)

I18N (Internationalization)

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

обрабатывать файлы с японским названием,
открывать файлы, в пути которого есть папки названные по-японски
корректно отображать японские субтитры,
если можно писать комментарии к файлам в плеере - они тоже вполне могут быть японские.

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

L10N (Localization)

Элтинэн - тестирование на полную адаптацию программы к чужой для неё локали и пользователю. Всё, меню, любой текст, формат даты/времени, все сообщения об ошибках или информационный должны быть на чужом языке. Тестирование L10N полностью включает в себя I18N и плюс проверка, что всё, что в айтинэн оставалось на английском переведено на другой язык.

Hard-coded (hard-coding)

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

Терминология тестирования

2010-03-19T12:46:00.049+02:00

Я решил начать цикл объяснений терминологии QA в примерах. Прошу учесть, что моё понимание может отличаться от объяснений терминологии в книжках.

Собственно приступим-с :)

Build

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

Test-cases (Use-Cases)

Тест-кейсы - основной инструмент тестера (если не считать мозг конечно). ТК - это руководство к действиям: сделать то-то, сравнить с ожидаемым результатом. Если полученный результат отличается от ожидаемого - оформляем дефект.
Пример test-case для проверки корректности введённого возраста на сайте:

Открыть страницу
Ввести 25
Нажать кнопку "Отправить"
Проверить профайл

Ожидаемый результат: Отображаемый возраст = 25
ТК такого вида слишком детальны и не оставляют возможности для творчества, превращая QA в тестера. Более того, тратится слишком много времени на написание, постоянный апдейт тестов, так как программа (или сайт) модифицируется. Можно, не без основания, предположить, что два разных человека, выполнят этот тест одинаково, пройдут по одному и тому же пути. Такие тесты хороши для стажёров.
Второй пример test-cases для проверки корректности введённого возраста на сайте:

Попробовать ввести :
1. Положительные числа
2. 0
3. Отрицательные числа
4. Очень большие числа
5. Буквы
6. Специальные символы
7. Очень длинную строку
8. Ничего не вводить (также одиночный пробел)
Попробовать ввести данные с помощью мыши (если есть такая возможность)
Copy-paste

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

Sanity

Санити - пробное тестирование, проверка "готовности" продукта к работе. Цель санити - выявить наиболее критичные дефекты на ранних этапах работы с билдом. Что проверяется на санити: основные фичи продукта с установками по умолчанию (default settings). Пример - сделать санити на mspaint. Пришёл новый билд, QA устанавливает и проверяет основной бизнес процесс с дефолтными настройками:

Создание нового документа
Открытие документов в разных форматах (*.bmp, *.png, *.jpg)
Сохранение документов в основных форматах
Возможность использовать все инструменты рисования (pencil, select, line и др)
Возможность использовать все инструменты редактирования (undo, redo, copy, cut и др)
Распечатка

Далее уже идёт либо проверка всего функционала, который существовал ранее (регрессия), либо тестирование новой фичи.

Regression

Регрессия - тестирование всего функционала продукта. Пример - сделать регрессию на mspaint:

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

На каждую новую фичу пишутся тест-кейсы (должны писаться :), для регрессии используются все эти кейсы.

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

Full

Фул - отдельный вид регрессии. Части программы, как то: орфография, поддержка I18N (internationalization) вряд ли будут затронуты при починке багов или разработке новой функциональности, поэтому иногда такие проверки (наряду с проверкой функционала), выносят (для экономии времени на обычную регрессию) в Full. Иногда в фул добавляют ещё какие-то части регрессии, в разных конторах по-разному.

Из грязи в князи или кто такие QA

2010-03-16T20:07:00.029+02:00

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

Мы делаем то, что мы делаем - осчастливливаем людей, препятствуя проникновению некачественных программных продуктов на винчестеры и DVD-диски.

Наша основная задача - протестировать программу до того как её релизнут, и она попадёт в руки пользователей.

Кратко, как всё происходит.

Девелоперы (Developers) создают версию программы (билд).
QA проверяют, что она устанавливается и работает (делает то, для чего собственно создавалась) корректно, проверяют на разных системах.
QA отписываются о всех найденных проблемах.
Девелоперы создают новую версию программы с починенными проблемами и новым функционалом.
QA устанавливают билд, проверяют, что таки да починили старые проблемы, отписываются о новых.
Так происходит, пока весь функционал не будет реализован, важные проблемы устранены, программа корректная и стабильная.
Ура, релиз!

Областей проверки очень много:

Функциональность (Functionality)- мы должны проверить, что программа делает именно то, что от неё требуется. Простой пример: пользователь суммирует два числа и ожидает, что программа выдаст именно сумму чисел, а не их разницу, сообщение об ошибке или ещё какую гадость. Такое бывает в процессе разработки и довольно часто!
Юзабилити (Usability) - удобство использования. Необходимо обеспечить максимально комфортную работу с программой. Пример: программа для захвата видео с экрана, то есть запись видео. Мы, как пользователи, можем предположить, что для начала записи необходимо нажать на большую красную кнопку, которая расположена где-то слева, потому что это привычно. Если же кнопка записи квадратная, чёрная, и находится в правом нижнем углу, это кого угодно заставит задуматься о смысле жизни.

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

Странно и не юзабельно смотрится программа, в которой чтоб начать записывать надо зайти в меню, выбрать какой-то пункт, появится окошко с кучей каких-то настроек, далее диалог подтверждения и вот только тооогдааа.. Или наоборот, все настройки вынесены на тулбар, смотришь и теряешься в обилии кнопочек, выпуклостей и впуклостей.
UI - проверить как это чудо вообще выглядит. Программа должна быть выполнена в одном стиле. Одна цветовая гамма, одинаковый размер кнопочек, одинаковые шрифты, выравненные чекбоксы в настройках и так далее, это стильно, профессионально, узнаваемо.
Совместимость (Compatibility) - влияние данной программы на другие апликации в системе. Программа не должна мешать жить соседям (другим программам) и не кричать, что раз плеер для просмотра порно-фильмов запущен и уже использует ass.dll, то я не буду работать.
Стресс тестирование (Stress) - реакция программы на не предусмотренные события (перезагрузка, остановка сервака, резкая нагрузка и др.). Пример: создайте в ворде документ, измените его как-то и, не сохраняя, инициируйте перезагрузку системы. Винда захочет закрыть ворд, а тот в свою очередь спросит пользователя, сохранять ли файл. Продумано? Продумано!

Или ещё пример, клиент-серверное приложение, клиент настолько затрахал запросами сервер, что у того случился перегруз с выпадением в осадок. Так вот, тестеры должны удостовериться, что в таком случае клиент не станет ждать с отвисшей челюстью, ответа сервера или не закрашится от незавершённого SQL-запроса, а по тайм-ауту пожалуется пользователю на молчание сервера и попросит совета, как жить дальше и что делать.

И так далее.

Как происходят проверки:

Самое главное правило - QA должен знать, что делает программа, её основные фичи. Как он это узнает, дело десятое. Для этого есть спецификации, которых обычно нет и здравый смысл, которого тоже часто нет.

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

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

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

Чем более профессиональный QA, тем больше ПОЛЕЗНЫХ тест-кейсов он может придумать, следовательно более полно проверить работоспособность. Полезность случаев тестирования (тест-кейсов), определяется применимостью их к программе с оглядкой на её специфику.

Вот как-то так и работает вся эта кухня ;-)

Куатая помощница

2010-03-13T21:35:00.012+02:00

InputDirector - первая програмулинка оформлена! Да будет ваше тестирование удобней.

Ку-А-Минь.

К ней также можно пробраться: слева, где страницы указаны ;-)

Оно мне надо?!

2010-03-06T08:38:00.048+02:00

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

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

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

Employees

Такое состояние дел рождает два типа работников:

1-й тип:

Получает деньги, чтобы удовлетворить потребности где-то в другом месте. Самомотивация отсутствует. Для него работа - "вырванные годы", потерянное время, своеобразная каторга. Ему работа в тягость.

2-й тип:

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

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

Собеседование.

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

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

Так как редко кто толком понимает: кто же такие HR, поэтому частенько это люди, напичканные популярной литературой, как-то "Обязательный курс для профессионала кадровой работы", "Отбор и найм персонала: технологии тестирования и оценки" и т.п. и не то, что никогда этим не занимались, так ещё и абсолютно не представляют, чем вообще будет заниматься испытуемый. То есть задавая стандартный вопрос: "Почему вы пришли именно к нам?" такой HR удовлетворится практически любым ответом, если о таком ответе было упоминание в прочитанных книгах. В то время как человек второго типа, нанимаясь в куа, ответит что-то типа: "Я любознательный человек, постоянно что-то проверяю, нахожу новые пути в использовании вещей, мне это нравится" (тут ещё может последовать рассказ о каком-то случае из жизни, если HR создал располагающую атмосферу на собеседовании). А человек первого типа, что-то типа: "Да мне друзья посоветовали, пойди - попробуй, ничего сложного, вдруг понравится?"

Чем лучше работает первый фильтр, тем проще в дальнейшем организовывать эффективное взаимодействие сотрудников.

Мотивация

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

В период стажировки, начальник присматривается к новому подчинённому, с целью понять:

Мотивация к работе (какой он типаж)
Взаимодействие с "костяком" команды
Систему ценностей человека (на что он способен, на что нет)

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

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

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

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

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

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

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

Автоматизация бывает разная: чёрная, белая, красная.. (чёрная)

2010-03-04T07:27:00.032+02:00

Функциональное тестирование - проверка корректности работы программы.

Первый подход:

тестируем руками

автоматизируем процесс

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

Автоматизация может быть нескольких видов:

Чёрная. Название не подразумевает связь с трудом африканских народов, а говорит о том, что исходный код апликации - не доступен. Есть установленная программа, которую надо протестировать и всё.
Белая. Используется исходный код тестируемой апликации (unit-тесты).
Красная. Нет такого вида автоматизации, тему под слова из песни подгонял.

Этот пост про чёрную.

Делаем на себе вид, что умеем планировать и ставить задачи.
Задача: Протестировать калькулятор.

Калькулятор нужен для операций с числами.

Составим контрольный пример : 789 - 35*4 + 60/12 = 654 (задействованы все числа и основные операции).

Можно протестировать руками и успокоиться, но у нас в планах следующая версия калькулятора, с новыми фичами и финтиклюшками. Основная функциональность, понятное дело, не должна "поломаться", поэтому надо проверять её после каджой новой фичи. Автоматизируем этот процесс.

Задача: Нужна программа, которая будет в точности повторять все действия пользователя.
Для этого она должна уметь:

Отличать объекты один от другого
Записывать действия над объектами
Повторять их

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

Программ для функционального тестирования - достаточно, многие "заточены" исключительно под веб и пока что нам не интересны.

Остановимся на одном из трёх монстров: HP QuickTest Professional (QTP), IBM Rational Functional Tester и Borland SilkTest, - на QTP. Почему? Потому что я только с ним и сталкивался :) По той же самой причине, я не буду их сравнивать.

QTP устанавливается запуском сетапа и последовательным нажатием кнопАчки "Next". Далее попросят ввести лицензию или указать сервер-лицензий, куда деваться, продукт платный.

При запуске есть возможность добавлять/удалять add-ins, если вы точно уверены, что какой-то из них не будет использоваться, лучше его выключить. Нажимаем Record, предварительно указав в Record and Settings режим запуска тестируемого приложения и вперёд.

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

После клика пользователя на кнопке, QTP сравнивает свойства объекта, над которым произведено действие со стандартным набором. И заносит Test Object в Repository. Количество извлечённых свойств можно оценить на снэпшотике.

Помимо описаний стандартных объектов, в QTP есть add-ins для специфических технологий, с набором объектов, их свойств и применимых к ним методов.

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

Несколько режимов записи, например, запись кликов по абсолютным координатам без распознания объектов, множество средств работы с репозиторием и несколько режимов проигрывания скриптов, собственно вот и весь QTP. Да, ещё и result viewer, генератор отчётов, который выдаёт результаты прогона скриптов в удобоваримом виде, полезная штуковинка :)

В чём сила, брат?! В автоматизации, брат! И тот сильней, у кого её больше :)

2010-03-03T07:23:00.015+02:00

Несмотря на значительные трудности, связанные с автоматизацией, она шагает по миру, как усердные солдаты на плацу, потому что имеет ряд неоспоримых преимуществ. Подсчитать сколько бы стоили машины, если собирались исключительно вручную, сложно, но представить разницу вполне реально. А качество? Aston Martinы выверяют каждую мелочь, у них полностью ручная сборка, но производительность (300 машин в год) и цена (сотни тысяч долларов), врядли устроят простого обывателя.

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

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

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

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

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

Почему дома кривые, ведь кирпичи-то ровные?! (QA версия)

2010-03-02T20:32:00.021+02:00

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

Юнит-тесты позволяют уменьшить время на регрессию, облегчают процесс тестирования, а унификация кода - повышает надёжность: любой косяк в UI сразу мозолит глаза, не девов, для них главное функциональная правильность, а кьюэй и кастомерам; какую-то часть кода уже тестировали, что резко снижает количество потенциальных багов.

Опять же, если проберусь к власти в куа-столице, процесс организую так: Переиспользование, только теперь уже не кода, а тестов (создание q-паттернов).

Что это и с чем его едят? Допустим, до вас работал какой-то грамотный куатор, его давно перекупили конкуренты, ещё в период хэдхантовых войн, а программа как жила так и живёт, более того - она стала ещё больше, прям динозавр. Но как было у неё в меню, "открыть файл", так и осталось. Как тестировали от версии к версии этот диалог, так и сейчас тестируют.

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

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

Шаблоны полезны. Тяжелее всего - начать писать тесты с нуля, сложно и долго. Из-за нехватки времени, что-то забудется, ещё ж тестировать надо. Опыт прошедших до тебя хорошо помогает. Это как изучать грамотный и красивый код, перенимая приёмы. Новичок раз пять пройдётся по содержательному q-паттерну, применит и начнёт своё создавать, молодые всегда приносят что-то новое.

Хорошо помню случай, когда тестировал диалог с вводом пути к файлу. Сотрудник наблюдал, говорит - сетевой путь вводил? Конечно не вводил и даже не думал, а после такого "напоминания" пополнил арсенал, с тех пор всегда пользуюсь.

Как бы я составил шаблон генерации отчёта.
Убедиться, что:
1) При большом времени генерации, используется какой-то индикатор;
2) Корректно обрабатывается попытка отменить задачу;
3) Существует возможность наблюдать за прогрессом;
4) Загрузка CPU не более 75% (варианты);
5) Создаётся лог;
6) Существуют и работают горячие клавиши на вызов генерации;
7) Есть несколько точек вызова генерации в программе;
8) Существует импорт/экспорт данных;
9) Возможно сохранение в различные форматы данных;
10) Возможна кастомизация;
11) Существует автоматическая генерация;
12) Можно архивировать и аттачить к мэйлу;
...

Вы тестируете систему генерации отчётов в своей программе, а позже, код использует какая-то другая команда, возможно, они тоже найдут баги, которые автоматически будут пофикшены и в вашей программе. Эффективно.

Следующее, за что возьмусь - автоматизация, в отдельном посте конечно, вотЪ! ;-)

Почему дома кривые, ведь кирпичи-то ровные?!

2010-03-02T08:02:00.011+02:00

Какой-то великий человек пару постов назад писал, что любая фирма стремится к узнаванию себя любимой и пихает свои логотипы и стиль куда не попадя, придерживаясь "one voice" политики.

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

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

Обязательные юнит-тесты на эти исходники + дописывать свои для новой фичи. Это вначале может показаться, что вся эта кухня не будет работать. Если правильно организовать - меньше проблем, багов и унификация получается сама собой. Получается, локальный такой, "фирмовый" фреймворк. И новая программа строится из готовых "кирпичиков". Цвета, иконки и др, уже заточены под компанию. Если пользователь в одной программе привык жать в одно и тоже место и видеть один и тот же результат, пусть и в другой программе наслаждается этим же. Стабильность - признак мастерства!

To be continue for куэйты :)

Разделяй и наслаждайся эффективностью

2010-02-27T07:57:00.021+02:00

Из википедии:

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

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

Почему бы не сделать команду, которая специализируется чисто на UI и Usability программ. Любая фирма стремится к лёгкой узнаваемости себя любимой, в результате все производимые продукты приводят к единому виду (one voice), стилю. Да и унификация программ - благо. Хорошо разобравшись в одной, вы с лёгкостью разберётесь в любой другой програме этой фирмы, резко вспоминаем мелкомягких.

Не пройдя специалиста по UI или Usability, апликацию нельзя релизить, намного меньше было бы проблем. Обычно в каждой команде, работающей над продуктом существует или существовал, кто-то (один), он когда-то, возможно, тестировал UI, искал инфу по этому делу и то бишь более-менее грамотный. Если такой человек и был, то велика вероятность, что он уже уволился или ушёл в другую команду, и забота о том, как будет выглядеть продукт ложиться исключительно на девов, которые в этом ничего не смыслят и немножечко куа, который что-то такое где-то слышал.

Но если создавать команду чисто ЮАЙщиков, то тут же появляется идея создания команды автоматизации. Опять же, это такие спецы, которые только автоматизируют тестирование програм других команд фирмы и ничем более не занимаются, не разрабатывают конкретный продукт, не тестируют свой. Эфективность была бы существенной. Признайтесь, ну у кого на фирме автоматизацией занимаются спецы? Это либо программисты в "свободное" от основного кодинга время (ага, свободные время у прогерров, анекдот прям), либо куа, в большинстве своём ничерта в автоматизации не смыслящие. А если смыслят, то платить им надо поболее чем простому куа, так почему бы не сделать отдельную команду автоматчиков? :)

Оставим ЮАЙ и Юзабилити в покое, их эффективность тяжело подсчитать, наверное, так же как и эффективность рекламы. Разберём автоматчиков. Конечно, эти идеи больше касаются больших фирм, хотя и в мелких могут найти своё применение. Допустим у нас 15 команд, по 7 человек, включая тим-лида. Отбрасываем голову селёдки, остаётся основной костяк - 6 человек. Итого 90 человек тестероводов. По одному автоматизатору на команду - 15 человек во всей фирме. Против команды из 5 "чистых" автоматизаторов + их голова селёдки. Людей в такую команду надо меньше чем уже есть в фирме, а эффективность - существенно выше, почему?

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

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

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

Секрет прост - такой слаженный механизм, где каждый делает то, в чём он спец в рамках одного продукта, называется эффективной командой, а слаженный механизм, где каждая команда специализируется на чём-то одном, своём, родном называется - фирма с эффективно организованным трудом.

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

Опытный QA и полный "чайник"

2010-02-25T20:43:00.003+02:00

Отдых - важнейшая часть работы, но понимание этого приходит далеко не сразу. Иногда нужно несколько лет, прежде чем тестер откроет в себе QA и поймёт: "Нельзя объять необъятное, впихнуть невпихуемое и найти все баги. Основное внимание нужно уделять важному и не распылять его на пустяки". Следуя этому нехитрому правилу, обычный QA становится "опытным QA". И вот уже опытный куэйтор по-настоящему понимает всю ценность отдыха.

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

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

Главный на кухне не ваш начальник, и даже не начальник вашего начальника, главный на кухне - чайник. Простой "Vitek" или "Braun" здесь главнее всех холодильников, умывальников, столов и тумбочек, куэйторов и дэвов. Ради него мы здесь. Ради него мы прошли десятки метров, и вот он кипит, привлекая внимание. Разноцветные чашки ютятся вокруг чайника, кажется, ещё секунда и они начнут толкаться.

Чай может рассказать не только о вкусах и предпочтениях человека, но и о занимаемой им должности. Вот тестер помешивает кипяток с липтоном или майским чаем, он пропускает вперёд QA, что только-только выбросил треугольный пакетик с заваркой и бежит к компутеру. За ними расходятся по своим рабочим местам опытные куэйторы, у этих - качественный, дорогой чай. Среди них затесался дэв с жестяной банкой со слонами, купленной недавно в каком-то супермаркете. Сколько людей, столько и чаёв.. Ещё Конфуций в своё время сказал: "Кто цяй не пьёт, тот цьмо!".

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

Мы не гопота, мы обычная куэйта

2010-02-22T14:45:00.008+02:00

На сегодняшний день в IT-сфере Одессы засвечены свыше десятка крупных и не очень компаний, ака Luxsoft, COMODO, Lohika, TechInsight, Exigen и другие. Почему GlobalLogic обходит стороной этот райский уголок оффшора не понятно, но скорей всего у них имеются более-менее серьёзные на то причины.

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

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

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

Что же мы видим сейчас? Нечто, отдалённо смахивающее на эпоху Ренессанса. Безработного IT-брата скопилось достаточно много, как спецов так и жёлторотых выпускников институтов, согласных работать практически за гроши. Жирные зарплаты, взвинченные в период междуусобиц, стали худеть на кризисной-то диете. Многие бездельники даже начали усиленно работать, опасаясь за своё теперь туманное будущее. Заказчики возвращаются к подрядчикам, улыбаясь, с понтом никто никуда и не уходил, так.. в туалет выбежал, когда в первый раз прижала неопределённость, но теперь-то всем стало легче вести дела, и брошенные впопыхах проекты поднимаем, поспешно сдуваем пыль и.. за работу! Работа, она ж как волк, как сидела в лес глядела, так и сидит. Заглянешь в эти честные глаза - спать хочется..

Так вот, брат куа, в следующий раз, когда опять спать захочется при виде творений ваших девов, просто вспомни за тот народ, что спит и видит твой стул под своей пятой точкой, так что бди, ресницами глупо не хлопай, взгляд в монитор и работай, работай!

Этот комфортный город, я вижу во сне

2010-02-22T10:14:00.007+02:00

Директор центра «Институт города» Сашка Сергиенко проболтался за наш комфорт и безопасность: "Одесса является наиболее комфортным, безопасным городом для жизни в Украине..". Вы это слышали? Авторитетно ляпнул.

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

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

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

Одно греет, может прав Сашка и в других городах и того хуже?

Для тех, кому понравился "Мы из будущего"

2010-02-21T09:30:00.008+02:00

Нарыл ролик в Инете, чёткий. Те, кому понравился "Мы из будущего" однозначно заценят.

..Но всё реже услышишь от раза к разу здесь одесскую фразу..

2010-02-20T08:53:00.013+02:00

..юмор их довольно специфический. Может, конечно, автор где-то и гений, но в Одессе еле-еле идиот!
Вас здесь не стояло!
Вы не подскажите, который час?
Почему не подскажу? Мы что с вами поссорились?
Не делай мине беременную голову!
Таких традиций есть в одесской молодёжи
Состроилась как есть немая сцена
"Я себе знаю, а вы себе думайте"
Не надо мне делать нервы, их есть кому портить
Немножечко мёртвый
Мне стыдно ходить с вами по одной Одессе
Я имею кое-что сказать
Шоб вы мне были здоровы!
Я готов послушать за вашу просьбу
Вы шо, спешите скорее, чем я?!
Я много раз тебя знаю
Шо ты хочешь от моей жизни? Уже сиди и не спрашивай вопросы
Я не могу его слышать, потому шо я не могу его видеть
Бабки тают хоть сейчас и не весна
Он бережёт меня от положительных эмоций
Стал заносчивый, как гаишник с престижного перекрёстка
Сколько, Сколько?!
Женщина, вы с утра температуру меряли?
Я вас уважаю, хотя уже забыл за что!
Ну ты посмотри на этого патриота за мой счёт!
Что, сегодня меньше скользко чем тогда?
На тебе, такое выкинуть! Взял и умер посреди полного здоровья!
Вы шо, с мозгами поссорились?

Updates из комментов:

Вы спросите меня, имею ли я счастье, и я отвечу: "чтобы да, так нет!" :)