Ты тестировщик ты должен уметь всё

Уже после создания опроса понял, что название темы дает двойственное понимание. Посему решил, что опишу оба варианта:
1. Совмещение позиции QA специалиста с какими то другими обязанностями
2. Необходимость большой базы знаний для качественного тестирования ПО

Итак, поехали по 1-му пункту:
Совмещение обязанностей, наверное, бесит абсолютно всех QA-специалистов(QAS). Если вы кроме тестирования занимаетесь программированием или администрированием сети, либо круче этого, вы - офис менеджер, то бросьте вы эту затею. Профессия тестировщика одна из тех, которым не пойдет «в плюс» совмещение позиций. Ведь вы профессионально тестируете софт, т.е. вы имеете деструктивное мышление, это вам не поможет не в обслуживании сети или офиса, а при разработке ПО будет всячески мешать, хоть и в некоторых случаях и помогать тоже.
При всем этом я вполне допускаю вариант тестировщика:

1. Выясняющего и пишущего постановку бизнес требований
2. Внедряющего ПО
3. В роли похожей на «Product owner» в Scrum
4. IT-консультанта

Почему?

1. Я уже много раз писал, что еще в начале проекта на этапе сбора требований нужно подключать QAS. А при должном опыте работы общения с заказчиками, такая задача вполне по плечу тестировщику. Если не верите, то у меня и Ромы был личный опыт.
2. Об этом я тоже давно пишу, что тестировщик лучше всех знает как установить и использовать софт. Не редкие случаи, когда тестировщик знает работу всего продукта лучше любого из разработчиков. Это объясняется тем, что QAS обычно работает со всем функционалом сразу. Кроме этого сборку и установку ПО каждый нормальный тестировщик обязан автоматизировать и в этом случае у него при внедрении все карты на руках :)
   
3. Этот пункт, что-то вытекающее из 1-го пункта, в довесок просто плотное общение с заказчиком
4. В принципе этот пункт я оставил напоследок, поскольку все скорее будет зависеть от самого человека, нежели от профессии, но я бы подчеркнул, что для QAS это не противоречивая должность

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

Теперь по 2-му пункту:
База знаний QAS немногим уступает, а в идеале и вовсе должна быть больше базы разработчика. Кроме фундаментальных типов тестирования и инструментария к нему, тестировщик должен знать бизнес логику, архитектуру и наиболее рискованные участки софта. Знание всего вышеперечисленного уже является не малым багажом знаний.
Почему же я написал, что в идеале QAS должен знать больше самого разработчика? Я уже писал здесь, о том, какие знания разработчика должен иметь тестировщик и чем он должен владеть для меня в идеале.
Я понимаю, что в больших командах тестирования специалисты в большей мере узко специализированы и мое видение может показаться неправильным и не фундаментальным. Но я пока не имел опыта работы в действительно огромной команде тестирования и являюсь приверженцем, того что QAS должен быть универсально подкован во всех видах и типах тестирования.
Наверное, хватит! Извините за небольшой сумбур в описании. Получился 1 из примеров когда хотелось рассказать многое но не клеилось. Комментарии опять же приветствуются.

P.S. Обратно создал опрос на следующую интересующую тему. Выбирайте, срок почти тот же - 10 дней.

Трекер задач(Issue Tracker, Bug Tracker) ч. 2

Извиняюсь что так долго не писал, но блог блогом, а работа есть работа :)Как и обещал вот продолжение предыдущего поста о трекере задач. На сей раз допишу о том, что я забыл указать в базисах для любого трекера (Спасибо Роме:)):
1. Для основных статусов не написал такой важный статус как "Открыт заново", но в свое оправдание могу сказать что многие просто из статуса "Реализован" отправляют в "Подтвержден".
2. Очень не маловажный фактор это резолюции при реализации(Например: Выполнено, Не будет выполнено, не воспроизводится и т.д.)
3. Тут я сильно облажался но САМОЕ ГЛАВНОЕ это кто создал и кто реализовал, тобишь исполнитель. Если нет этих вещей, то любой трекер задач теряет свой смысл сразу...

Ну это все было то, что я не дописал в прошлом посте. Теперь же, то что я обещал написать, т.е. workflow который я поставил у себя. Ниже приведен рисунок, в котором я попытался обобщить все виды рабочего процесса.Теперь начну объяснять почему так. Ну во первых думаю понятно, что значит овалы и стрелки? Если нет, то объяснять я все равно не буду :)
Начнемс:
1. Создания задачи - это действие лучше разрешать всем кто работает над текущим проектом.
2. Подтверждение задачи - этот шаг нужен в качестве фильтра на создаваемые задачи. Подтверждение означает то, что задача полностью сформулирована и одобрена заказчиком, руководителем проекта или отделом тестирования.
3. Отмена задачи - означает то, что задача не сформулирована или просто не выполнима. Статус "Отменен" дает заказчику выбор на то, чтобы либо все таки реализовывать решение или же закрыть. Естественно при действии закрыть автоматически выставляется резолюция "Не будет выполнена"
4. Статус "В разработке" выделен отдельным статусом от "Решено" для того, чтобы заказчику или руководителю проекта было понятно над какой задачей работают, а над какой нет. В этом смысле статус "Тестируется" имеет то же самое значение. Если у вас в компании это не критично, либо не нужно, то конечно лучше просто сделать переход из "Подтвержден" в "Решен"
5. Статус "Не решен" тоже отделен от понятия "Подтвержден" потому что по этому статусу понятно, что реализация решения какое то было, но были найдены ошибки при тестировании.
6. Статус "Проверено". Здесь думаю все понятно. Конечно можно объяснить зачем проверенную задачу можно отправить в не решенные? Думаю у всех были случаи когда, во время тестирования задачи все работало, а позже при полном тестировании версии(итерации, проекта и т.д.) были случаи когда функционал просто не работал. Это именно для таких случаев.
7. Статус "Опубликовано" больше понадобится если у заказчика имеется понятие приемочного тестирования. Т.е. в реальности это означает, что вы передали дистрибутивы заказчику и он развернул его себе на своем тестовом окружении. Здесь имеется еще 1 интересный момент. Если на стороне заказчика задачу считают не решенной, она попадает именно в QA отдел. Это сделано впервую очередь для того, чтобы все ошибки впервую очередь были воспроизведены и только потом попадали на реализацию решения. Это можно считать еще одним фильтром :)
8. Ну и наконец задачу внедренной считает именно сам заказчик либо группа внедрения, где как в принципе. В частности для этого рабочего процесса конечным статусом будет "Внедрено".
На этом думаю все. Пожелания, вопросы и претензии в комменты :) В следующем посте постараюсь описать основные на мой взгляд достоинства JIRA и некоторые хитрости с ней.

Трекер задач(Issue Tracker, Bug Tracker) ч.1

Ну как и обещал пишу об Issue Tracker, ну или Bug tracker кому как...В прошлом посте я описывал желательный рабочий процесс(workflow), который как мне кажется должен быть у всех. Теперь попробую написать о том, как все это дело фиксировать и как работать. Как мне кажется главная задача любого трекера задач - это фиксировать состояния задач и стараться максимально "прозрачно" работать с заказчиком. В принципе если ваш рабочий процесс построен не так, как я попытался описать в предыдущем посте, то это ни о чем не говорит. Но надо понимать что ваша задача это перенесьти весь имеющийся рабочий процесс на статусы в трекере. В любом деле важно максимально честно работать с заказчиком и давать ему возможность выставлять приоритетность задач. Ну это все набор слов, который встречается везде, теперь по полочкам.1. Создание задачи, ошибки или улучшения. Абсолютно все, что хочет заказчик должно фиксироваться в трекере. Никакого рода отмазок типа "Не понимает чего хочет", "Ему это не пригодится", "Потом заведу" быть не должно. Почему? Каждая новая задача для вас - это хлеб и возможность выглядить в более приятном свете перед заказчиком. Наверно все, не раз сталкивались с ситуацией, когда заказчик сказал по окончании проекта "Я же вам говорил, что это надо сделать".. При этом надо понимать, что эти задачи надо просто завесьти. Остальные вопросы кто, когда, в какой версии и зачем будут решаться позже. 2. Статусы или состояния задач. Статусы задач имеют чуть ли не самую главную роль в трекере. Если вы работаете с заказчиком то вы отлично понимаете что есть этапы, по которым происходит реализация задачи. Самые базовые:-Открыт. Статус в котором задача только была создана.-Подтвержден. Задачу подтвердили на разработку, т.е. такие задачи встают в очередь для решения.-Реализован. Задачу реализовали и передали на проверку QA отделу. -Закрыт. Реализацию задачи проверили и передали заказчику.Эти статусы присутствуют едва ли не в любой системе трекинга задач. Суть думаю понятна3. Переходы между статусами. Здесь главное на мой взгляд построить переходы между состояниями так, чтобы получилась некая модель типа конечного автомата.4. Выделение прав, кастомизация процесса. Здесь в принципе момент спорный. Если у вас нет необходимости ограничивать пользователей трекера и нужно просто фиксировать работу, то и не надо париться вам вполне подойдут бесплатные, опенсорсные решения типа Bugzilla, Trac или Mantis. Но вот если же все таки встала острая необходимость, то тут либо править ручками исходники open source продуктов или тупо купить уже готовые решения. Здесь конечно же очень выделяются продукты как Atlassian Jira или TrackStudio. Для себя же выбрал Jira... Не сочтите это за рекламу, но этот продукт действительно устраивает меня во всем и я его никому не навязываю. Кстати, если у вас небольшая фирма из 4-5 человек, то для вас вполне подойдет спец предложение от Atlassian по которому вы можете получить ее на халяву, правда с ограничением на нескольких пользователей и 1 проект кажется.Для полного представления трекера задач в следующем посте опишу workflow в собственной компании.И напишу некоторые советы по настройке Jira. На сегодня все...

Рабочий процесс(workflow) с QA

Всем привет.Захотелось написать о рабочем процессе разработки ПО и самое главное где впихнуть в уже имеющийся процесс свой QA отдел.В принципе эту тему я как то затронул в другом своем посте, но он честно говоря был уже написан давно и так рекламировать Trac я уже не стану. Теперь конкретно по теме:
1. Рабочий процесс разработки ПО практически всегда начинается со сбора требований. Так вот уже здесь лучше всего привлечь QA специалиста. Почему? Потому что первостепенной задачей для любого QA всегда должна быть проверка правильности выполненной бизнес логики. И узнать эту логику лучше всего еще до начала реализации. Опять же если у вас отличная документация к проекту или хорошо налаженная коммуникация с командой программистов, то этот шаг может быть будет и не нужен.
2. После сбора требований обычно пишут ТЗ. Здесь я бы советовал паралельным ходом уже начать писать тестплан для ПО(версии, релиза или продукта суть не важна, все зависит от вашей процедуры внедрения). Кроме сценариев, если это нужно, помочь в описании заказчику сценариев приемочного тестирования. Надеется на то, чтобы описать тестплан позже, лучше не надеется и описать его сразу же, а в дальнейшем по тихоньку его дополнять и улучшать.
3. Если ТЗ подписали, то начинается непосредственный этап реализации. Здесь очень важно, что для водопадной модели и любой ajile модели процесса, построить процесс так, чтобы после окончания любой задачи, она попадала на тестирование. Это поможет сократить сроки выполнения проекта и позволит быстрее получать ошибки от QA отделу программистов.
4. Непосредственно после реализации всего проекта должен быть выделен отдельный этап полного тестирования проекта. К этому времени у QA просто должен быть полный тест план и рабочие автоматизированные GUI тесты по нему. Здесь исправляются все имеющиеся ошибки и билд становится стабильным.
5. Следующий этап - отправка дистрибутивов. Почему это отдельный этап? Просто хотелось бы подчеркнуть, что именно QA лучше всего отправлять дистрибутивы на сторону заказчиков. Поскольку именно QA должны знать какой из дистрибутивов является стабильным, а какой нет.
6. Этап внедрения. Здесь важно понимать, что ошибки или дополнения так или иначе будут в 80% случаев. Исключить ошибки на данном этапе возможно лишь одной из методик XP - "customer on-site". Это мало когда бывает, но это возможно. Стоит подчеркнуть, что все найденные на стороне заказчика ошибки или дополнения сперва должны попадать в руки QA на воспроизведение. Этим выставляется некий фильтр на большой поток запросов от заказчика :)
7. Конец проекта(релиза, версии) и много, много пива :). Этот пост можно считать первой частью разговора об issue tracker и его роли.
Продолжение будет в следующем посте :) Всех с прошедшим Новым Годом!!!

Открылся новый сервис для микроблоггинга по адресу http://qa.co.kg

Обращаюсь к колегам QA. Заходите и регистрируйтесь на http://qa.co.kg. Будем обмениваться инфой и линками. Попробуем сделать комьюнити :)

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

Все таки вытоил время для топика).
Производственный процесс в нашей компании основан на практиках 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/ вам поможет ответить на эти вопросы. В статье описывается то к чему и мы пришли спустя время с начала работы нашего отдела. На сегодня все)