понедельник, 24 декабря 2007 г.

О наболевшем..

Большая проблема с которой приходится бороться в компании - это то, что новые люди в тестировании очень быстро устают быть тестерами. Перефразируя, большинство IT-ков по просту теряют мотивацию тестить после некоторого промежутка времени. При этом я бы не стал проводить аналогию с таким понятием, что любому человеку когда то просто не нравится то, что он делает. Проблема в другом.. У большинства сотрудников многих фирм есть какое то неправильное видение целей и обязанностей QA команды. Из чего и сами члены QA команды сами себя терзают таким же мнением.. Мнение примерно такое, что тестер это ничего не понимающий, не разбирающийся в работе софта мудила, который только и делает что тыкает программу как дурная обезьянка... Печальное мнение надо сказать, но более обидным является то, что в некоторых фирмах это реальность... На практике встречалось такое, что QA просто тупо тыкает софт, потом находит не захендленную ошибку и тупо радуется из сие факта. При любой поставленной задаче для QA должно быть первостепенным проверить валидно ли была выполнена та или иная бизнес логика, которая может быть какой угодно. В этом ракурсе я бы подчеркнул что в идеале QA должен понимать логику заказчика лучше самого девелопера. Этого можно добиться либо присутствием самого QA на обсуждении софта, либо (если таковой возможности нет) просто вытряхиванием всей информации по софту от любого носителя этой логики.
Так к чему же все это? Хотел провесьти некую систему приоритетов при тестировании любого продукта. Начнемс:
1) Проверка на валидность выполнения поставленной задачи;
2) Проверка юзабельности(на гуи стандарты);
3) Валидность работы софта при правильных значениях;
4) Валидность работы софта при не допустимых значениях;
5) Проведение нагрузочных, регрессионных и т.д. тестов(в зависимости от самой задачи)
6) Ну и наконец если все хорошо запись автотестов.
Все пункты не обязательные, они будут зависеть от самого выданного ТЗ.
Для меня лично идельным QA является тестер, который кроме вышеперечисленных пунктов может видеть проблемные части еще в самом коде и может подсказать те или иные решения еще при написании.
Все эти обязанности могут показаться муторными, вот это и есть та причина того, что люди теряют мотивацию работать именно в этом направлении. Огромнейшие виды тестирования раскрываются при тестировании веб приложений. Поскольку при их тестировании большой акцент выставляется безопасности. Те же самые SQL-иньекции, XSS атаки, подверженность dos-атакам и т.д. Все это ложится на плечи именно QA-отдела.
В примере работы именно нашего QA-отдела, то общение с заказчиком тоже лежит на нашем отделе. В этом смысле задач и работы у отдела всегда хватало.
Но самая главная проблема в нашем направлении наверно все таки в том, что нигде не учат на тестеров ПО, т.е. на эту должность приходят люди которые имеют образование именно девелоперов и сие факт постоянно терзает многих. В том смысле, что многие просто не довольны тем, что как бы учились скажем 5 лет на программиста а потом становятся тестерами и опять же сами не понимают собственной значимости. Главное все таки в любом деле это получать кайф от собственной работы, если этого нет, то сколько себя не мучай, но в конце концов все равно это выйдет боком и человек так или иначе уволится. Бывает и такое что у человека хорошо получается тестить, но нет никакого желания этим заниматься) Это самые огорчительные случаи.
Самый обидный ответ на вопрос как мотивировать тестера - практически никак, кроме того как заинтересовать его в собственной работе. Наверное на сегодня все.

пятница, 9 ноября 2007 г.

Об организации процесса разработки в нашей компании

Все таки вытоил время для топика).
Производственный процесс в нашей компании основан на практиках XP. Что за практики и с чем их едят в принципе описывается на http://exprogramming.ru/ . От себя же добавлю что эти практики были ответами на простейший вопрос "Как создавать софт(да и не только) быстрей, не потеряв при этом качество продукта". Практики весьма полезны и самое главное были придуманы на основе хорошего опыта и рациональных решений.
Подчеркну сразу что не все 12 методик применены в компании по тем или иным причинам. Тем кто хочет внедрить у себя XP посоветовал бы рационально подумать какие из методик им бы подходили, а какие нет.
Весь производственный процесс основан на вербальной коммуникации и здравом смысле, инициатива только приветствуется. Парное программирование, 40 часовая неделя, TDD, рефакторинг, небольшие релизы и т.д. все это присутствует. Но отсутствует методика "заказчик всегда рядом" в силу разных географических местоположений. Вместо этого есть масса альтернативных средств для общения с заказчиком, которые и используются).
Теперь о месте отдела QA в этом процессе.
В цепочке реализации софта наш отдел занимает последнюю стадию, но перед самим заказчиком. Самое главное то, что без одобрения отдела QA билд заказчику не может быть отправлен, если только сам заказчик не согласится с имеющимися недостатками и попросит его нефиксеный.
Деление проекта на мелкие релизы и итерации позволяет оперативно тестировать поставленные задачи. Кроме этого автотесты становятся просто необходимыми при итерационной разработке софта.
Говоря более детально: Любой проект по началу делиться на мелкие итерации, затем каждая итерация делится на мелкие задачи(task). Кроме типа тикета "задачи" имеется и тип задачи defect тобишь баг. Любой тикет проходит тот самый "жизненный цикл" в статусах тикета, а именно: InQueue, InStart, InProgress, NeedTest, FoundBug, Done, DeployedTest, DeployedReal. Значение и предназначение каждого статуса таится в их переводе)).
Trac открыт для самого заказчика, что позволяет ему быть осведомленным о текущих задачах и иметь возможность контролировать их с помощью приоритетов для тикетов.
Каждый тикет в конце концов приходит в статус NeedTest, т.е. в QA-отдел. Перед началом тестирования пишется "test case" и производится само тестирование функциоанала. На тип тикета defect, test case не пишется, поскольку описание бага и должно быть test case-ом.
После него следует статус FoundBug либо Done.
Первостепенной проверкой всегда должна быть проверка на валидность выполненной бизнес логики. Только после этого ручное, юзабилити, crush и регресиионое тестирования.
На последок если вы ищете какова разница построения QA-отдела в Ajile и других типах, то эта статья http://it4business.ru/articles/749/ вам поможет ответить на эти вопросы. В статье описывается то к чему и мы пришли спустя время с начала работы нашего отдела. На сегодня все)

вторник, 28 августа 2007 г.

О тестировании ПО (2-ч.)

Ну начнем по полочкам:
С чего надо начинать?
В общественном понятии QA team это такие сволочи внутри организации,которые не дают спокойно работать проггерам. Избавится от такого мнения является первой целью. Как этого добиться? Наилучшее решение на мой взгляд это дать понять команде разработчиков то, что QA имеют те же цели, что и они, т.е. "Предоставить заказчику действительно добротный и стабильный софт". Конечно же нельзя забывать о базовых понятиях для QA как багтрак, автоматизированная система тестирования, ну и главное иметь "талант" или расположенность к тестированию. Последнее понятие может показаться спорным, но если чувак не получает удовольствия от тестирования, то рано или поздно все это выйдет боком как для QA, так и для компании. Последствия чаще всего это - лень и утеря коммуникации со своими коллегами, что очень страшно...
Самым сложным в начальной стадии организации QA-team является "самоудтверждение самой команды внутри организации". Т.е. доказывание начальству, да и вообще самой компании, дееспособности и реально приносимой пользы от работы команды.
На мое личное мнение не нужно нагружать все возможныим обязанностями только начавшую свою работу команду. Обязанности будут накладываться по мере потребностей. Для начала команде хватит и GUI тестирования и попытки автоматизации скриптов.
Занимаемое место QA-team в жизненном цикле софта всегда должно быть перед заказчиком, в нормальных условиях только после одобрения QA софт должен отправляться заказчику. Такая жесткая политика просто необходима, поскольку почти во всех фидбэках от заказчика наверняка будут обвинены именно QA, со знакомыми словами "Это ты виноват))".
Обязанности QA, которые могут быть возложены на команду это не только GUI тестирование, но и проверка на правильность решения бизнес логики заказчика, проверка usability. Из этого и вытекает необходимость для команды быть в курсе хода всей системы в целом, знать "ТЗ" и понимать ожидаемые результаты работы выпускаемого софта заказчиком.
Жизнь Багтрака у нас в компании имеет интересную последовательность. Первой его задачей была запись найденных багов и последущее исправление проггерами. По сути она имела 3 статутса: "найден баг", "исправлено"(прогером) и "работает")). Естественно это нас не радовало, поскольку мы не были польностью осведомлены о проделанных изменениях в софте, что приводило к случаям того, что мы не могли протестить все проделанные изменения. При этом выбранный нами багтрак без проблем подключался к нашему SVN репозиторию, но прослеживать все проделанные коммиты было очень трудоемким. Решили эту проблему мы исходя из собственных потребностей. Все карточки(задания для проггеров) перевели на багтрак, при этом добавили(дописали=)) собственные необходимые нам статусы для карточек. Грубо говоря перевели жизненные циклы софта в статусы. Надо отметить, что жизненный цикл софта у разных компаний имеет разный вид, поэтому не стал называть статусы железными именами. Примерная последовательность это - в очереди, делается, на тестировании, найденбаг, закончено. Эта последовательность у каждой комании имеет собственный вид и дополняется собственными потребностями. Неплохо, если к карточкам привязывать жесткую политику последовательности.
Возможность делать собственные отчеты(запросы) по багтраку очень важно. Нашим выбором среди багтраков стал http://trac.edgewall.org/ по большей части из за того, что он был опен-сорс проектом и его можно было дописать, возможность подключения нашего svn к нему и куча созданных для него плагинов. Но опять же для разных видов организации процесса разработки необходимы разные решения.
Думаю хватит на сегодня)

понедельник, 27 августа 2007 г.

О тестировании ПО (1-ч.)

Хотелось бы написать собственное мнение о таком направлении как тестирование программного обеспечения. В общем то самое главное к чему я пришел за малое время работы в качестве QA в компании, так это то, что главная цель любого QA не должно быть "Найти максимальное количество багов", более правильным является "Сделать софт максимально качественным для заказчика". Количество найденных багов никогда не может быть показателем работы отдела тестирования. Мое сугубо личное мнение показателем становится реакция непосредственного заказчика на предоставленный софт, в каких то случаях количество фидбэков...
Почему же количество багов в софте не показатель? Потому что проггеры бывают разные и задачи также.
В плане багов большее внимание я бы обратил на адекватность восприятия бага программистом. Исходя из этого и выползают разные виды коммуникации с любым проггером, каждому нужен отдельный подход.
Самым главным в работе отдела QA на мой взгляд является поднятие максимально удобного и понятного багтрака, поскольку процесс выпуска софта у разных компаний имеет индивидуальынй характер. Довольствоваться тем, что есть на руках не лучшее решение. Тем более есть опенсорсные проекты которые всегда можно дописать самим.
Выбор автоматизированного софта для тестирования тоже не маловажный шаг... Самый большой и пугающий факт это то, что хороший софт стоит больших денег. Для того, чтобы сберечь собственную контору лучше всего накачать триальные версии этих программ и попробывать каждую. Исходя из этих опытов выбрать наиболее подходящий.
Для первой части наверно хватит)