Нужны советы по программе курсов по "Тестированию ПО"

Начать хотелось бы конечно с извинений, поскольку этот блог я перестал пополнять уже больше года, но я надеюсь, что наверстаю. Думается, что мысли не прекратятся и видение будет меняться с приходом все нового и нового опыта. Теперь по самой теме:
Ситуация такая: в Кыргызстане очень плохая ситуация с хотя бы молодыми и перспективными кадрами. Посему в КАРПО(Кыргызской Ассоциации Разработчиков Программного Обеспечения) было решено создать IT-лабораторию.
IT-лабораторию можно расценивать как небольшой эксперимент по повышению квалификации собственной отрасли. Суть данной лаборатории

Темы опроса(duplicated)

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

1. Тестирование по контексту - Context Driven Testing
2. QA, QC, tester, тестировщик, тестер. А разница?

Не хотелось зная писать, то что уже итак отлично написано до меня, посему:

1. Совсем недавно Алексей Лянгузов великолепно описал Context Driven Testing и дал собственные советы по приведенным практикам. Так что рекомендую к прочтению именно его статью.
2. Вторую тему отлично описал(я бы сказал перевел ) Вячеслав Панкратов в своем посте "В чем разница между Тестированием и QA"

Поскольку в опросе остались лишь пара тем, то опишу обе, но немного позже

Экстремальное тестирование

Хотелось бы уточнить название поста. Я хотел бы написать о тестировании в XP команде.
Экстремальное программирование XP базируется на 12 основных практиках:

1. Разработка через тестирование (Test driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Whole team, Onsite customer)
4. Парное программирование (Pair programming)
5. Непрерывная интеграция (Continuous Integration)
6. Рефакторинг (Design Improvement, Refactor)
7. Частые небольшие релизы (Small Releases)
8. Простота (Simple design)
9. Метафора системы (System metaphor)
10. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
11. Стандарт кодирования (Coding standard or Coding conventions)
12. 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Теперь же попробуем проецировать практики на тестирование.

Из QAS в Dev, из Dev в QAS, реально ли?

Ну а вы как думаете дорогие читатели?

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

Вопрос на самом деле другой: Кому легче и быстрее будет переквалифицироваться? На самом деле описать такую тему меня подвигнул пост одного из популярных IT блогов в СНГ блог Виктора Ронина на тему Программист против QC . Этот пост обрел очень большую огласку в то время среди QA(QC) среды.

Кому легче в принципе опять же зависит от многих факторов: желания человека, базы как таковой, прошлой специализации и т.д. Но давайте рассмотрим по 2-м усредненным типам специалистов. Предположим у нас есть Саша – хороший разработчик ПО и Ваня – хороший QAS.

Программисты и QAS в одной комнате

В принципе ситуацию нахождения программистов и тестировщиков в одной комнате можно воспринимать в качестве практики. Естественно у данной практики есть корень. Корнем я бы назвал практику XP, в которой говорится, что команда разработчиков должна находиться в одном помещении. Что это дает разработчикам в результате?

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

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

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

Уже после создания опроса понял, что название темы дает двойственное понимание. Посему решил, что опишу оба варианта:
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. На сегодня все...

Открыл общий доступ к своему RSS ридеру

Всем привет.Открыл общий доступ к своему GReader. Естественно в нем находятся не все мои подписки, а только те посты, которые я посчитал интересными :) На самом деле такая идея пришла намного раньше. Ситуация была следующая. В моем QA отделе я всегда был за то, чтобы мои ребята развивались, читали и держали руку на пульсе, но этого не происходило, всех затягивала работа... Для того, чтобы хоть как то поддерживать развитие у ребят, как только появлялось время просматривал свои подписанные ленты и отмечал то, что им казалось нужным к прочтению. Немного позже узнал, что подписались не только они. Теперь же думаю че уж тут для своих открывать, если уж открывать так открывать для всех и вот оно :) Его можно посмотреть справа :)

О необходимости знаний в программировании для QA

В каком то из постов я уже касался такой темы, что для меня лично, идеальный QA это прежде всего тот, кто указывает на ошибки, еще посмотрев на изменения в коде. При этом я не исключаю ни ручного, ни еще какого либо тестирования. Как показывает всеобщая практика 70-80% багов находятся в процессе именно ручного тестирования. Все должно быть в совокупности.Теперь начнем рассуждать по делу с самого начала... Все так или иначе столкнулись или столкнуться с тем временем, когда нужно набирать людей в свой QA отдел. Лично я приверженец того, что если человек решил заняться тестированием ПО "серьезно", то ему естественно нужен некий базис. В моем понимании базиса, QA должен иметь как минимум IT образование, причем я имею в виду не только высшее образование, это может быть и просто опыт работы без всякого "диплома". Скажу честно, что человека без IT прошлого на роль QA, я не стану даже рассматривать. Я знаю, что есть множество примеров, когда люди без "образования" тестировали продукты лучше специалистов. Но на этот факт надо смотреть по другому: ведь QA не занимается постоянным ручным тестированием в надежде найти ошибку, кроме этого он должен писать автоматизированные тесты, понимать хотя бы архитектурную суть софта и многое другое. А вот брать и учить даже этому, человека совсем не просвещенному в этих вопросах я не хочу и не буду. Мне жалко и свое время и свои нервы.Пойдем дальше. Автоматизированные тесты как бы к ним не относились... это тоже программный код, который в любом случае будет иметь свою логику и архитектуру. При этом написанные тесты придется усиленно поддерживать. Еще на данном этапе будут необходимы хотя бы минимальные знания программирования. Еще дальше. Всем опытным QA когда то приходилось тестировать задачи которые очень тяжело воспроизвести. В таких случаях тоже могут понадобиться те самые знания программирования. Т.е. смотрим в исходный код и смотрим где что могло вывалиться или сработать не корректно. Теперь о том, что было еще в начале. К примеру у меня уже давно стало привычкой еще до начала тестирования смотреть в изменения в коде для того, чтобы понять что, как и где изменилось и на что это может повлиять. Мой опыт показывает, что это как минимум не мешает общему процессу тестирования. Описал не все свои доводы, но постарался написать хотя бы общие.

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

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

С днем тестировщика

9-сентября не официальный праздник в принципе, но от этого не менее знаминательный День тестировщика или День QA. Поздравляю коллеги с праздником хоть и с опозданием в 1 день:). Почему 9-сентября можно узнать здесь . Первому найденному багу 63 года:) P.S. Че то я совсем забыл про блог, впредь буду отчаянно пытаться писать хотя бы 1 раз в неделю

Ну наконец то в Wiki

Начну наверно из далека. Такое направление как software testing или qa хоть и появилось относительно давно, но все community такого рода специалистов не консолидированы.
Что я имею в виду? Есть конечно какие то базовые понятия для любого QA но вот их взгляды на одни и те же понятия расходятся колоссально. Для примера открываем самые большие форумы и наблюдаем в обсуждениях просто кошмар. К примеру из 30 последних тем, около 25 будет с вопросом типа: А что такое тесткейс?, Что такое сценарий тестирования?. Причем это наблюдается как на англоязычных, так и на российских форумах.
Эта проблема известна многим и было много попыток сделать единую базу знаний для всех QA, примером такого может быть http://www.softwareqatest.com/ . Да я признаю что база знаний у нее неплохая, но вот 1 незадача, туда мало кто заходит просвещаться. А теперь главная фишка: Ни для кого не секрет, что большинство IT-товарищей первым делом пытаются просветиться либо в Гугле, либо в Википедии . Ну и вот наконец то к конкретно самой новости: в Wikipedia открылся отдельный портал для QA по адресу http://en.wikipedia.org/wiki/Portal:Software_Testing . Для себя открыл несколько интересных понятий, да и мне кажется, что любой QA найдет там массу интересного и база знаний будет дополняться.
P.S. Больше всего радует то, что можно будет пнуть долбанных индусов в Вики на форумах и не париться.

Стыдно но все же

Недавно улучшили процесс деплоя как на сторону заказчика, так и себе. Честно говоря очень обидно, что не доперли до этого сразу но все же. Принцип следующий:
Я уже писал в предыдущем посте, что мы используем Bamboo и ant в качестве средства для сборки билда и прогонки имеющихся ГУИ и юнит тестов. Так вот в Bamboo имеется такая фича как "artifacts", которая в принципе была сделана разработчиками из atlassian для хранения каких то собственных файлов после каждой попытки билда. Т.е. каждый конкретный произошедший билд имел бы какие то собственные к примеру сторонние логи или еще какую нить белеберду на вкус и цвет самого составителя билда.
И тут возникла идея для того, чтобы все qa в команде всегда имели последний валидный билд на руках, просто хранить сам билд в артифактах. Т.е. апдейт из репозитория, дальнейшая компиляция, компановка, прогон тестов и т.д. ложиться на интеграционку и в конце туннеля в артифакты суются уже готовые билды. К тому уже они имеют собственную хранящуюся историю. Говоря простым примером, то в классическом случае когда заказчик говорит "дай мне щас билд вот с этим функционалом", вы просто отправляете линку на билд в Bamboo с последним нормально оттестенным и считающимся стабильным номером билда.

О Continuous Integration (ci)

Вытаил время для очередного топика. На этот раз захотел написать о таком понятии как Continuous Integration, ну или просто CI. Для тех кто не знает что это такое, то читаем в Wiki . Прочитав можно сразу понять, что понятие ci было впервые озвучено многоуважаемыми Фаулером и Беком в качестве набора базовых практик которые позволяют команде наиболее быстро получать фидбек по работе софта.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...

Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.

Ну в общем то для начала думаю хватит.

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

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

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

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

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

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

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

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