Airguru

Wanted: QA Lead

2011-11-29T13:51:00.004+04:00

Коллеги, наша компания (labs.mind.com) все еще (уже как полтора года) стремительно растет и развивается.

Поэтому,

Если вам понятно, что написано в этом блоге;
Если вы с этим согласны или считаете, что что-то можно сделать лучше;
Если вы обладаете опытом работы в тестировании и автоматизации сего процесса (обязательно) более 2 лет;
Если вы знаете как минимум 2 скриптовых языка (один из которых JScript) и 1 высокоуровневый;
Если у вас есть опыт проведения нагрузочного тестирования (не только сторонними средствами, но и самописными (+допиливание оных));
Если вы можете подробно рассказать о тестировании на русском и английском языках;
Если вы прочитали более 5 книг по тестированию;
Если вы еще не устали учиться и добывать знания;
Если в голове полно креатива);

а также:
Если вам нравятся сверхинтересные, сложные проекты (например, imind.com, e.mind.com), работа в высокопрофессиональном коллективе, возможности безграничного обучения;
(sal. from 70kRUR);

Пишите- будем общаться) ибо

Открыта вакансия на позицию ведущего тестировщика (впрочем, вакансий открыто несколько).

/Достойным поможем переехать, если будет такая необходимость.

Розыск еще одного тестировщика

2010-09-15T17:47:00.003+04:00

Коллеги, наша компания стремительно растет и развивается. Поэтому,

Если вам понятно, что написано в этом блоге;
Если вы с этим согласны или считаете, что что-то можно сделать лучше;
Если вы обладаете опытом работы в тестировании и автоматизации сего процесса (обязательно) более 2 лет;
Если вы знаете как минимум 2 скриптовых языка (один из которых JScript) и 1 высокоуровневый;
Если у вас есть опыт проведения нагрузочного тестирования (не только сторонними средствами, но и самописными (+допиливание оных));
Если вы можете подробно рассказать о тестировании на русском и английском языках;
Если вы прочитали более 5 книг по тестированию;
Если вы еще не устали учиться и добывать знания;
Если в голове полно креатива);

а также:
Если вам нравятся сверхинтересные, сложные проекты, работа в высокопрофессиональном коллективе, и офис гугла);
(sal. from 70kRUR)

Пишите- будем общаться) ибо

Открыта вакансия на позицию тестировщика.

система управления требованиями

2010-05-28T16:39:00.002+04:00

Тем, кто в поисках такой системы предлагаю списочек:

Requirements Management Software

Accompa
Accept 360
Active!Focus
AnalystPro
Caliber-RM
Clariys
CORE
Cradle
DOORS & DOORSrequireIT
Enterprise Architect
GatherSpace
GMARC
IRqA
Jama Contour
Leap SE
Lighthouse RM
Mac A&D and Win A&D
MKS Requirements
objectiF
Open Source RM
Optimal Trace
PACE
PixRef Pro
Polarion Reqs
Projectricity
Rally
RaQuest
Reconcile
Reqtify
Requirement Tracing System
Requisite Pro
RMTrak
RTM Workshop
SoftREQ
SpiraTest
Teamcenter
TestTrackRM
TopTeam Analyst
Tracer (free)
TRUEreq (free)
XTie-Requirements Tracer

Взято отсюда:

http://www.jiludwig.com/Requirements_Management_Tools.html

Внимание: розыск тестировщика

2010-04-15T15:28:00.003+04:00

Если вам понятно, что написано в этом блоге;
Если вы с этим согласны или считаете, что что-то можно сделать лучше;
Если вы обладаете опытом работы в тестировании и автоматизации сего процесса (обязательно) более 2 лет;
Если вы знаете как минимум 2 скриптовых языка (один из которых JScript) и 1 высокоуровневый;
Если у вас есть опыт проведения нагрузочного тестирования (не только сторонними средствами, но и самописными (+допиливание оных));
Если вы можете подробно рассказать о тестировании на русском и английском языках;
Если вы прочитали более 5 книг по тестированию;
Если вы еще не устали учиться и добывать знания;
Если в голове полно креатива);

а также:
Если вам нравятся сверхинтересные, сложные проекты, работа в высокопрофессиональном коллективе, и офис гугла);
(sal. from 60kRUR)

Пишите- будем общаться) ибо

Открыта вакансия на позицию ведущего тестировщика.

идеальный тест?

2010-03-24T22:18:00.001+03:00

оцениваем:

http://www.computerpowertest.com/

440 Web Test Tools

2010-03-12T14:28:00.002+03:00

Очень внушительная подборка инструментов (440 штук!) для автоматизированного тестирования.

зы: Не все краткие описания совпадают с действительностью.

http://www.softwareqatest.com/qatweb1.html

Опять про собеседования

2010-03-12T13:41:00.002+03:00

Очень понравилась статья Владимира Антонова "Собеседование специалистов или интервью как игра". Читая, вспоминал, как сам набирался опыта в этом плане..Особенно интересно, когда побывал на нескольких описанных позициях, например, на трех или больше.

К предыдущему моему посту очень кстати)

Взято отсюда:
http://www.protesting.ru/qa/interview_game.html

как собеседовать кандидата на вакансию тестировщика?

2010-02-27T11:28:00.007+03:00

"оЧень осторожно" примеры:)
главное- выявить нужного\подходящего из всего потока и сделать ему предложение, от которого он не откажется.

вот и задача сформулировалась.

теперь- к условиям.

необходимые:
1. кандидат должен быть способен выполнять его обязанности.
2. выполнять пункт 1 за плату, которая укладывается в рамки бюджета на позицию\отдел.
3. выполнять пункт 1 за время, которое укладывается в отведенные для этого сроки.

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

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

для типа А:

1. обучаемость и желание учиться;
2. способность находить стандартные и нестандартные решения вопросов в заданных рамках (временных, информационных, компетенции, лояльности);
3. умение применять полученные знания;
4. умение работать как в команде, так и самостоятельно;
5. инициативность;
6. понимание процессов (смысла, целей и методов) тестирования и разработки вцелом.

для типа Б:

1. способность четко выполнять поставленные задачи и соответствовать правилам и шаблонам;
2. внимательность;
3. исполнительность;
4. понимание процесса (смысла, целей и методов) тестирования;

Итак, сформулированы условия, удовлетворение которым нам и потребуется проверить.

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

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

дополнительные:

для типа А:
1. поставить задачу, сказать как искать решение.
2. поставить задачу, НЕ сказать как искать решение.
3. применить пункт 1 на практике.
4. прямые и косвенные вопросы (как было, как хотелось, что нравилось, что- нет).
5. сколько и каких вопросов задал в пункте 2?
6. :)

для типа Б:
1. поставить задачу, посмотреть на результат выполнения.
2. добавить в пункт 1 хитрое условие.
3. опыт прошлого.
4. :)

Очень думаю, что перечислил далеко не все. Со временем дополню.

Не забываем вести беседу так, чтобы кандидат в ужасе не убегал с собеседования, перекрещиваясь пяткой (относится к части о предложении).:
А предлагать надо только то, что сможешь выполнить. Никогда не нужно обещать того, чего не сможешь выполнить ("не мешайте мне работать" Стас Давыдов (ссыль)). Тем более возможно твоему будущему сотруднику.

Спецификация на ПО (шаблон)

2010-02-11T11:22:00.008+03:00

Для тех, кто еще не знает, зачем пишутся спецификации- http://russian.joelonsoftware.com/PainlessSpecs/1.html

Для тех кому лень- вкратце это выглядит так:

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

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

Без детальной спецификации невозможно составить план. Отсутствие плана не проблема, если вы пишете кандидатскую диссертацию и рассчитываете за ближайшие 14 лет ее закончить, или если вы программист, работающий над следующей версией игры Duke Nukem (мы выпустим ее, когда все будет готово и сделано на высшем уровне). Но почти в любой отрасли реального бизнеса вы просто обязаны знать, как долго все будет продолжаться, потому что разработка продукта стоит денег. Вы даже джинсы себе не купите, не узнав, сколько они стоят, так как же ответственный бизнесмен может принять решение, создавать или не создавать продукт, без информации о том, сколько это займет времени, и, следовательно, сколько это будет стоить?

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

Спецификации – это мать всего!

Теперь непосредственно о форме и содержании:
(за основу взят шаблон "A Software Design Specification Template" by Brad Appleton. найти можно здесь: http://www.cmcrossroads.com/bradapp/docs/sdd.html)

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

Схема шаблона:

Введение;
Обзор системы;
Вопросы проектирования:
-Предположения и зависимости;
-Основные ограничения;
-Цели и руководства;
-Методы разработки;
Архитектурные стратегии:
Стратегия-1 название или описание;
Стратегия-2 Название или описание;
...
Архитектура системы:
Компонент-1 Название или описание;
Компонент-2 Название или описание;
...
Политики и правила:
policy/tactic-1 название или описание;
policy/tactic-2 название или описание;
...
Детальное описание системы:
Модуль-1 Название или описание;
Модуль-2 Название или описание;
...
Глоссарий;
Библиография.

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

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

Далее по разделам:

Введение:

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

Обзор системы:

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

Вопросы проектирования:

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

-предположения и зависимости:

Похожие программное или аппаратное обеспечение;
Операционные системы;
Характеристики конечного пользователя;
Возможные и/или вероятные изменения в функциональности.

-основные ограничения:

HW и SW окружение;
окружение конечного пользователя;
наличие ресурсов;
соответствие стандартам;
требования совместимости;
требования интерфейсов и протоколов;
требования БД и транспортов;
требования безопасности;
ограничения памяти и производительность;
быстродействие;
сеть;
требования тестирования, тестопригодность;
другие значения требований качества;
другие требования.

-Цели и руководства:

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

(Сохранить это максимально простым и понятным;
(акцент на скорости работы, вместо ограничения выделения памяти;
(работать, выглядеть, ощущать продукт, как готовый;

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

-Методы разработки:

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

Архитектурные стратегии:

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

использование частных (сторонних) продуктов и инструментов- язык программирования, БД, библиотеки и т.д.;
повторное использование существующих компонентов системы;
планы на расширение и доработки;
используемые образцы интерфейсов (модели ввода\вывода);
примеры взаимодействия HW, SW;
обнаружение ошибок и восстановление после сбоев;
использование памяти;
внешние БД и СУБД;
распределенные данные и контроль над всей сетью распределения;
основные подходы к контролю;
распараллеливание и синхронизация;
механизмы взаимодействия;
управление другими ресурсами.

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

Архитектура системы:

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

Архитектура подсистем:

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

Политики и правила:

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

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

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

Детальное описание системы:

Большинство компонентов, описанных в разделе "Архитектура системы" потребует более детального обсуждения и описания. Другие компоненты (нижних уровней) и подкомпоненты возможно, необходимо будет также описать . Каждый подраздел этого раздела будет ссылаться или содержать подробное описание программных компонентов системы. В ходе обсуждения должны быть охвачены следующие атрибуты компонентов программного обеспечения:

классификация: вид компонента, такого как подсистема, модуль, класс, пакет, функция, файл и т.д.;
определение: специфическое назначение и значение компонента в системе. Может понадобиться ссылка на спецификацию требований;
функции и поведение компонента: Что должен выполнять этот компонент? Какие роли он играет? Какие виды сервисов он предоставляет для клиентов\пользователей? Для некоторых компонентов здесь может быть необходима ссылка на требования;
Ограничения: Любые уместные ограничения, лимиты для этого компонента. Здесь должны быть указаны ограничения по времени, объему данных, состояниям компонента, может включать в себя правила для взаимодействия с этим компонентом (охватывающие предварительные условия, постусловия, инварианты, другие ограничения на входе или выходе, форматы (типы) данных и доступ к данным, синхронизация, исключения и т.д.);
Состав: описание использования и важности субкомпонентов, которые являются частью этого компонента;
Использование\взаимодействие: описание взаимодействия с другими компонентами. Какие другие компоненты используются этим компонентом? какие используют данный компонент (здесь необходимо включить описание влияния на другие части и компоненты, которое может иметь данный компонент). Объектно-ориентированный дизайн должен содержать описание любых известных или предполагаемых подклассов, суперклассов и метаклассов;
Ресурсы: описание всех управляемых, находящихся под влиянием этого компонента, а также необходимых ресурсов. Ресурсы являются внешними элементами при проектировании, например, память, процессоры, принтеры, БД или библиотеки. Здесь должно быть включено обсуждение всех возможных условий и возможных блокирующих проблем, а также пути их решения;
Обработка: описание того, как компоненты действуют, выполняя функционал, который они должны выполнять. Это должно включать в себя описание всех алгоритмов, изменения состояний; соответствующие временные или пространственные сложности; параллельность, методы создания, инициализации, а также очистку; обработку исключений;
Интерфейсы\экспорт: набор сервисов (ресурсы, данные, типы, ограничения, процедуры и исключения), которые предоставляются этим компонентом. Четкое определение и объявление каждого такого элемента должно быть актуальным, с комментариями и аннотациями, описывающими значения величин, параметров и т.д. для каждого сервиса;

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

Глоссарий:

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

Управление конфигурациями

2010-02-10T11:27:00.001+03:00

Все разложили по полочкам авторы Новичков Александр, Лапыгин Дмитрий:

http://anovichkov.msk.ru/?p=598

А также "Конфигурационное управление
(Software Configuration Management по SWEBOK)":

http://swebok.sorlik.ru/6_software_configuration_management.html

свободное время тестировщиков

2010-02-04T15:11:00.004+03:00

свободное время тестировщиков

Болтон предлагает использовать его так:
1. неописанные тесты (небольшие);
2. рискованные значения (негативные тесты, граничные условия);
3. сделать ошибку и вернуться на шаг или больше назад. пользователи совершают ошибки. обработка ошибок и восстановление являются наиболее уязвимой частью программы;
4. посветить время просмотру справочной информации, относящейся к проекту;
5. вести блог, вики (профессиональные);
6. продакшн баги и предложения переводим в тестовые идеи и непосредственно ТС;
7. написание простых программ, которые позволят сэкономить в будущем время, повышение опыта программирования (вот оно- слияние автоматизации и ручного тестирования);
8. помочь коллегам:)
9. осмотреть свое тестовое окружение, определить новые риски, записать новые тестовые идеи, сделать предложения..
10. самообучение -> применение новых знаний к проекту, оформление отчета в виде вики.

ЗЫ:
Рекс (Rex Black, www.rbcs-us.com) упомянул мой пробный перевод в ньюслеттере:
" Critical Testing Processes Introduction - in Russian!

We receive frequent requests from all over the globe to translate our articles, publications and Rex Black's books into other languages. Most recently Andrey Punin requested that he translate the introduction to Rex Black's acclaimed book, Critical testing Processes, into Russian.

Andrey works as a test lead in a large software company in Moscow, Russia. His experience covers test automation, test team planning and management, development of test strategy, test department creation, coaching, and transfer of test activities from one country to another (within one large software company). He has written several articles on software testing. He also enjoys translating software testing articles from English to Russian.

To see the translation, visit our Basic Library page."
Скоро закончу перевод очередной статьи.
Также на подходе много новых статей и заметок.

\Просто не было времени. Совсем.

Кто тестировал год назад

2009-12-03T17:46:00.002+03:00

Занятные результаты.
Взято опять с http://habrahabr.ru/blogs/testing/45899/

Где хранят ручные ТС

2009-12-03T17:25:00.003+03:00

Такие вот любопытные результаты.
Взято с хабра: http://habrahabr.ru/tag/test%20management/

Переводы статей по тестированию

2009-11-16T04:11:00.005+03:00

С любезного согласия Рекса Блэка (Rex Black, www.rbcs-us.com) буду публиковать переводы его статей по тестированию. Очень много полезной и важной информации.

Первая статья, как вступление:

Критичные процессы в тестировании программного обеспечения (ПО)

Рэкс Блэк: Президент и главный консультант компании
RBCS, Inc., Bulverde, TX
Ключевые слова (теги): Тестирование ПО, критичный процесс тестирования,
управление тестированием, проекты разработки ПО,
проекты сопровождения и поддержки ПО,
автоматизация тестирования, ручное тестирование.
Аудитория: Руководители тестировщиков, ведущие тестировщики, менеджеры проектов,
тестировщики, руководители разработчиков, менеджеры конфигураций.
Перевод с английского: Андрей Пунин (anairguru@gmail.com).
Оригинал: http://www.rbcs-us.com/software-testing-resources/library/basic-library

Введение

Как профессионалу в области тестирования с почти двадцатилетним опытом в области компьютерных технологий, мне приятно видеть новую статью, посвященную нашей области, в журнале “Journal of Software Testing Professionals”, и я имею честь внести свой вклад, как редактор. Первой задачей в этой роли мне было предложено написать самому , а также сотрудничать с другими специалистами в области тестирования, чтобы получить цикл статей, отвечающих на вопрос: “Что мы подразумеваем под критичными процессами в тестировании, которыми профессионалы в этой области должны владеть и управлять, чтобы добиться успеха?”. В каждой из этих статей мы будем подробно рассматривать один такой критичный процесс, предлагать практические советы: что уже работает и предостерегать от того, что может создать проблемы.

Содержание цикла

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

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

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

Типы и зависимости критичных процессов

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

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

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

Рисунок 1.

Выбор критического процесса

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

Планирование и оценка объемов работ по тестированию. Планирование объема работ- это не то же самое, что и написание тест кейсов. Тестирование включает много логистических и организационных факторов, о которых тест менеджер должен подумать до того, как тест кейсы будут написаны. Планирование также включает сбор фактов от многих участников и оценку поддержки коллегами и руководством вашего плана. Мы посмотрим на различные процессы и стандарты, которые существуют для планирования тестирования и которые помогут подобрать правильные для вашей организации.
Риски оценок и риски управления качеством. Тестирование- это прежде всего задача управления рисками, но иногда мы не понимаем критичных рисков качества, пока не начнем тестировать. В будущей статье мы поговорим о путях выстраивания наших систем тестирования совместно с заказчиками, пользователями, и другими заинтересованными сторонами, чтобы быть уверенными, что мы тратим наши ресурсы на правильное тестирование.
Тестирование релизов сопровождения ПО. В то время, когда тестирование разработки получает больше всего обратной связи, процесс тестирования релизов сопровождения позоционируется как процесс с набором труднореализуемых, но быстрых изменений. Срочный патч для критического бага требует больше различных методов, подходов тестирования, чем регулярный релиз по расписанию. Поэтому гибкие процессы обязательны. Мы представим наборы методов, включая дискуссии о сильных и слабых сторонах каждого их методов.
Измерение и увеличение тестового покрытия. Как мы можем оценить контрольный показатель по достижении которого, можно будет судить о достаточном покрытии кода тестами? Мы обычно измеряем покрытие в строках кода, при помощи спецификаций, требований, но существуют другие показатели. Статья будет содержать опрос сообщества профессионалов в тестировании об их техниках.
Распределение объема тестирования. С появлением аутсорсинга, офф-шор вендоров и многофункциональных ИТ практик, как частей разработки ПО (больших и маленьких), какая-либо организация имеет возможности увеличивать тестовые возможности своих партнеров и свои собственные. Также тестовые лаборатории, контракторы и консультанты предоставляют ресурсы для заполнения недостающих ваших собственных ресурсов. Статья будет содержать материалы о том, как координировать различные группы тестировщиков, вовлеченных в процесс и определенных для достижения результатов каждым из них, а также коммуникации и обмен информацией между ними.
Динамическое распределение приоритетов в тестировании. Большинство тестировщиков соглашаются, что они не могут выполнить все их тесты за отведенное время. Иногда слишком мало времени отведено на разработку тестов, приводящее к необходимости прокрытия многочисленных тестовых условий малым количеством тест кейсов. Давайте посмотрим на пути разработки эффективных тест кейсов и приоритезируем эти пути для достижения высокоуровневого риск менеджмента независимо от сроков.
Распределение ролей в команде тестировщиков, этапы их привлечения в тот или иной процесс в мастштабах всей организации. Процесс тестирования не должен напоминать собой “детский футбол”: когда множество людей бегает за мячем на большом поле и пытаются ударить по мячу. Благодаря использованию этапов (стадий) тестирования каждая команда занимает правильную позицию в тестировании продукта. Достигнув уверенности, что команда остается на правильных этапах (стадиях) тестирования (и только тестирования), заботливый тест менеджер сохранит свою команду эффективной. Статья будет содержать обсуждения фокусирования на нужных объемах работ тестирования, включая сложные межведомственные отношения и менеджерские рассуждения о том, как тест менеджер должен организовать остальных для выполнения определенных видов тестирования.
Сбор требований и спецификаций. Вы когда-нибудь замечали, что тестируйте приложение при существенном или полном отсутствии информации о том, как приложение должно себя вести при различных условиях? Метод “научного тыка”, расспросы коллег, сравнение вашего приложения с конкурентными и прием во внимание пожеланий заказчика- это все части единого процесса решения таких проблем. Мы посмотрим и на другие пути решения этих проблем.
Развитие и поддержка тестовой системы. Статический набор тестов страдает от того, что доктор Борис Бейзер называет “парадоксом пестицида”: этот набор может стать менее эффективным, так как разработчики учаться избегать ошибок, которые находятся тестами (и, разумеется, исправляют существующие ошибки – Прим перевод.). Мы будем изучать процессы, которые постоянно улучшают наборы тестов, добаляют новые тесты, устраняют устаревшие тесты и апдейтят существующие тесты в соответствии с изменяемыми требованиями и условиями.
Построение тестового репозитория. Тестовые системы состоят из тестовых условий, тест кейсов, тестовых инструментов, наборов тестов и других объектов. В неоднородных условиях эти объекты распростроняются на различные Ос`и, языки программирования и даже на различные команды тестирования. Вы можете построить или купить систему, которая бы позволила вам управлять этими разрозненными частями? Давайте посмотрим на техники построения и использования таких самописных инструментов и на коммерческий софт для управления тестированием.
Управление релизами и конфигурациями в управлении тестированием. Тестируемый софт не должен просто появляться магическим образом в тестовом окружении, так же как и тестовые среды не должны магическим образом конфигурировать себя вокруг доставленного кода. Плавное течение софта от разработчиков к команде тестирования в лабораторию тестирования, с четким контролем результатов установок, требует тотального менеджмента и эффективных коммуникаций, часто в бытро меняющихся условиях. Будущая статья рассмотрит ключевые моменты в этих областях вместе с примерами менеджмента релизов и конфигураций, сделанных корректно и наоборот- недостаточно верно.

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

Обращение к участникам:

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

Как и у ваших коллег- профессионалов в тестировании, у вас также может быть ваш собственный набор методов и идей. Как читатель этого журнала вы можете судить о том, какой же процесс является критичным. Следуя руководствам и правилам журнала вы можете публиковать свои аннотации к статьям. Если вы “боретесь” с критичными процессами и хотите учиться у своих коллег- дайте мне знать. Я за всестороннее общение с читателями. Мой e-mail написан ниже.

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

Об авторе:

Рэкс Блэк (Rex_Black@RexBlackConsulting.com) – президент и главный консультант компании “Rex Black Consulting Services Inc.” (http://www.RexBlackConsulting.com) – международной консультационной компании в областях тестирования и обеспечения качества. Он и его компания предоставляет помощь их клиентам в применении, передаче знаний, а также наборе персонала для работы над процессами тестирования и обеспечения качества. Его книга “Управление процессами тестирования” была публикована в июне 1999 года издательством “Microsoft Press”.

Статья про Контекстное тестирование

2009-11-03T09:43:00.000+03:00

Алексей Лянгузов грамотно все описал http://www.software-testing.ru/library/testing/general-testing/847-context-driven-testing

Рекомендуется к запоминанию.

Exploratory Testing Dynamics

2009-10-26T10:01:00.000+03:00

James Bach опубликовал новый документ, описывающий Exploratory Testing. Очень интересный док. Чего только стоит: "Imagine a problem, then find it."
Рекомендую к прочтению.

http://www.satisfice.com/blog/wp-content/uploads/2009/10/et-dynamics22.pdf

Постановка задачи тестирования

2009-10-16T11:20:00.000+04:00

В очередной раз поставили задачу максимально некорректно. Типа: "У нас обновление такое-то. Потестируй там что-нибудь..".
Нервы мои не выдержали, и я разразился очередным документом "Постановка задачи тестирования". Документ этот содержит список простых вопросов, ответы на которые необходимо получить перед началом тестирования. К сожалению, многие не понимают, что только корректная постановка задачи приводит к желаемому результату :(
Вполне допускаю, что список не совсем полный, но по мере необходимости буду дополнять и корректировать. Замечу, что эти вопросы перекликаются с вопросами, размещенными в предыдущем посте, но цели у них разные.

Постановка задачи тестирования
1. Что именно нужно тестировать? (дистрибутив, ссылки на веб клиенты).

2. Вид тестирования (Функциональные (+уровни тестирования); Нефункциональные; Связанные с изменениями).

3. Как тестировать? (что конкретно должно быть протестировано, что должно быть проверено обязательно, что дополнительно, что "если останется время").

4. Где документация? (спецификация, требования).

5. Когда и как долго тестировать? (сроки, время начала, если сразу нельзя начать)?

6. Где тестировать? (адреса, ссылки, машины, ОСи, окружение)?

7. Чем тестировать? (инструменты, файлы)?

8. Где необходимые инструменты, артефакты? (файлы, базы, логины, пароли, учетные записи, сертификаты и т.д.).

9. К кому обращаться за дополнительной информацией?

11. Что делать с результатами?

12. Необходим ли отчет? (если да- см. заявку на отчет).

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

10. Дополнительные инструкции.

Заявка на получение отчета о тестировании.

2009-10-09T12:05:00.000+04:00

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

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

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

Воспользовавшись ресурсами it4business.ru, статьей в блоге "255 ступеней" (http://blog.shumoos.com/archives/190) оформил вот такой список вопросов, ответы на которые нужно включить в постановку мне задачи о написании отчета о тестировании.

Заявка на получение отчета о тестировании.
Так как отчет о тестировании может быть сформирован множеством способов, зависящих от того, кому отчет? зачем? что на его основании будут делать?- при следующей необходимости написания отчета предлагаю вместе с постановкой такой задачи отвечать на вопросы:
кому отчет?
зачем?
что на его основании будут делать?
что нужно показать?
указать, что работает или что не работает?
другие комментарии.
А также следует ли отвечать на вопросы вида:
1) Это можно продавать/устанавливать или нужно доработать/выкинуть?
2) Какова степень уверенности?
3) Как называется то, о чем идет речь?

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

Что именно тестировать?
Как тестировать (что должно быть проверено обязательно, что дополнительно)?
Когда тестировать (сроки, время начала, если сразу нельзя начать)?
Где тестировать (адреса, ссылки)?
Чем тестировать (инструменты, файлы)?
Где необходимые приложения (файлы, базы, логины\пароли, учетки, сертификаты и т.д.)
Инструкции.
Другое.

Корректность фиксов багов

2009-10-06T15:31:00.000+04:00

Должны ли разработчики проверять корректность своих фиксов?
Проблема обсуждалась неоднократно на форуме проекта it4business.ru , в блогах и т.д. Попробуем разобраться в ситуации.

Априори предполагаем наличие здравого смысла в организации процесса и ясность смысла проверок всем ясна. Итак, если проверки необходимы, то их кто-то должен делать- либо сами разработчики, либо тестировщики. Рассмотрим 2 варианта: 1- тестировщиков на проекте не достаточно; 2- тестировщиков достаточно для того, чтобы смотреть еще и за результатами фиксов, несмотря на то, что времени на тестирование всегда не хватает. Второй утопический случай можно смело отбросить) и поставить вопрос так: должны ли разработчики сами проверять не только корректность конкретного фикса, но и некоторое минимальное окружение вокруг этого фикса (бага)? То есть ограничиваться ли автору фикса проверкой только лишь того конкретного бага\проявления бага, который указан в баг репорте? Или все-таки включить мозг, попробовать другие действия, окружение и т.д.

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

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

Что получилось:

Вобщем я решил, что такой регламент должен быть коротким, чтобы разработчикам было не лень его читать и применять. Также чтобы он описывал только основные моменты.
Смысл его введения:
1. Разработчики дожны проверять, что то, что они сделали (написали\пофиксили), работает вообще.
2. Разработчики дожны проверять, что то, что они сделали, работает корректно.
3. Разработчики дожны проверять (хотя бы в минимальной степени), что то, что они сделали, не ломает существующий, корректно работающий функционал.
Можно переложить почти все эти проверки на тестировщиков при условии, что как максимум на 4 разработчиков будет 1 тестировщик. В нашем случае это без вариантов.
По опыту тестирования (конкретного софта) могу сказать, что очень много времени у меня уходило: на поиск существующих в системе баг трекинга баг репортов + их возвращение, комментирование; на запись похожих. При организации проверки фиксов разработчиками этого бы не понадобилось. А потраченное время я бы потратил на более серьезную проверку.

Проверка фикса (не только):
1. Время верификации каждого фикса не более 10-20 мин.
2. В первую очередь производится попытка воспроизведения бага (по описанным шагам).
3. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.).
4. Проверка этих областей.
5. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)).
6. Проверка этих методов.
Минимальное свободное тестирование (специфично для определенного софта):
7. Проверка работы с некорректными данными (например, сохранение, поиск по ним).
8. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт).
9. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными
обязательными полями).
10. Если, например, теструется установка дистрибутива или импорт данных, имеет смысл
использовать виртуальные машины для одновременной проверки разного функционала или
параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и быстрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).

Все это опять же- FYI.

Относительная плотность багов

2009-10-02T15:11:00.000+04:00

Окунемся в теорию.
Рассмотрим такое теоретическое понятие как относительная плотность багов. количество багов на некоторую единицу, например, на единицу времени (неделя, итерация), на единицу разработки (фича, модуль), на рабочую единицу (тестировщик). Более всего интересно распределение количества по времени. Заметил, что с течением времени это количество не постоянно. Проанализировав, получил, что: значение плотности багов должно обычно изменяться с теченем времени, потому что:

1 низкая плотность в начале работы (обусловлено тем, что имеем новый продукт (софт\фича), вероятно, новые инструменты, новые люди);

2 выше в середине работы (процесс налажен, всё известно, все знают зачем, что и как делать, у всех есть желание и возможность сделать свою работу);

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

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

2. соблюдать инструкции и правила. (без этого предыдущий пункт можно вычеркнуть).

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

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

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

6. ротация людей по областям (не обязательно всех), взаимозаменяемость.

7. смена типа, метода, подхода ручного тестирования (Прежде всего в области ad hoc, exploratory testing).

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

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

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

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

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

Круговорот документации

2009-10-01T14:04:00.000+04:00

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

Заведите себе глоссарий (необходимость говорить на одном языке)

2009-09-30T11:02:00.000+04:00

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

Расстановка приоритетов тест кейсов

2009-09-29T14:58:00.000+04:00

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

Правила работы с багами (баг репортами).

2009-09-28T12:25:00.000+04:00

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

Работа с дефектами:

1. Вся работа с дефектами должна быть в соответствии с требованиями TFS (Напомню, что это наш основной инструмент). 1. Каждый дефект репорт в багтрекинговой системе: 1) имеет уникальный номер ID; заголовок (краткий, но максимально информативный для поиска и ориентации по нему); важность; срочность; ссылки на связанные дефекты, ТС, требования (обязательно для дефектов требований, спека), документацию (при необходимости); описание (что, где и когда именно не работает(работает неправильно));набор шагов для воспроизведения (необходимо указывать максимально короткую последовательность из возможных, то есть проводить доподлинное выявление дефекта, его локализацию), если существуют другие способы появления этого же дефекта- необходимо их указать (например, в комментариях); к какому приложению и\или его области дефект относится, в каком билде найдет, в какой билд вошел фикс; статус (в каком состоянии он находится, кто в данный момент времени над ним работает, кто автор, кто ответственные);комментарии, историю изменений. 2) описывает уникальное состояние приложения (на данный момент времени). 3) должен содержать максимальное количество (уникальной) информации о дефекте (xml, скрины, графические файлы и тд).
Остановлюсь на заголовке подробнее. Правильный заголовок должен отражать суть дефекта, быть таким, чтобы по нему можно было найти дефект поиском, в то же время- кратким и емким. Если это исключение, значит пишем, что "исключение при...", а не "появляется сообщение с исключением..". Второй вариант допустим при дефекте вывода не того сообщения, которое должно быть, например.

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

3. Недопустимо повторение дефектов в системе багтрекинга. Перед постингом необходимо убедиться в отсутствии такового же дефекта в системе, используя поиск. При необходимости- открыть заново с соответствующим комментарием.

4. Каждый дефект репорт должен содержать описание только одного дефекта. при отклонениях должен быть создан другой репорт (за исключением некоторых случаев, которые будут оговариваться отдельно). Здесь имеется ввиду то, что нельзя запихивать несколько дефектов в один репорт. Не путать с одним дефектом и несколькими путями (возможностями) его проявления.

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

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

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

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

9. Количество шагов для воспроизведения должно быть минимальным, но достаточным (дефект должен быть максимально локализован).

10. Необходимо проводить регулярные bug review, bug status review.

11. Описание дефектов необходимо дополнять достаточным количеством скриншотов.

12. Как правило каждый дефект имеет свое влияние на выполнение\невыполнение ТС\TS и др. Поэтому должен содержать ссылки на зависимые элементы.

13. Что нужно проверять при проверке фикса\новой фичи: 1. проверять, что то, что сделали (написали\пофиксили) разработчики, работает вообще. 2. проверять, что то, что сделали (написали\пофиксили) разработчики, работает корректно. 3. проверять, что то, что сделали (написали\пофиксили) разработчики, не ломает существующий, корректно работающий функционал.

14. Проверка фикса (и не только): 1. В первую очередь производится попытка воспроизведения бага (по описанным шагам). 2. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.). 3. Проверка этих областей. 4. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)). 5. Проверка этих методов. Минимальное свободное тестирование (сугубо специфично): 6. Проверка работы с некорректными данными (например, сохранение, поиск по ним). 7. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт). 8. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными обязательными полями). 9. Если, например, тестируется установка дистрибутива или импорт данных, имеет смысл использовать виртуальные машины для одновременной проверки разного функционала или параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и бытрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).

А так же читаем про управление дефектами на http://software-testing.ru/library/testing/bug-tracking?layout=default

Правила написания скриптов автотестов (TestComplete)

2009-09-25T09:13:00.000+04:00

В дополнение к предыдущему посту, и для совместного (параллельного) использования этих постов.
Обращаю сразу внимание, что правила в этом посте специфичны для конкретного проекта, конкретной организации и конкретных инструментов автоматизации и тестирования вообще. Поэтому основные мысли уловить можно, но перед использованием в других проектах\компаниях эти правила следует заточить под свою спецтфику. У нас инструмент автотестрования- TestComplete 6.52. Багтрекинг - TFS. ОС- Vista, WinSserv2003, WinSserv2008. Виртуализация- VMWare. MS VisualStudio2008.
Итак сами правила:

1. Правила создания тест кейсов. Без комментариев :)

2. Инструкция к тесткомплиту. Без комментариев :) Хорошо, что есть на русском и на английских языках.

3. Структура: нумерация и название ТС, идентичны ручным ТС. Иначе не поймешь, что проверяет тот или иной скрипт.

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

5. Структура: первый проект (ТС) содержит скрипт (назовем его "Reference"), содержащий функции и методы, испотльзуемые в других ТС. Тут следует прокомментировать: оптимальным вариантом представлялось такая организация- тест кейс=проект (project) тесткомплита, набор тест кейсов=(project suite) съют. сам скрипт (script)= набор функций (function).
Каждый ТС (проект) содержит несколько скриптов: Первый- ссылка на скрипт "Reference" первого проекта.

6. Структура: первый проект (ТС) содержит скрипт ("Reference"), содержащий функции и методы, используемые в других ТС.

7. Структура: остальные ТС (все кроме первого) содержат основные скрипты ТСа ("Main" и "Local _Reference"), и "ссылку" на скрипт ("Reference") скрипт (выглядит эта ссылка просто как скрипт). Таким образом у нас имеется 3 скриптовых элемента в каждом проекте: 1)одно хранилище ("Reference") функций и методов, используемых в различных скриптах, находящееся (физически) в первом проекте и вызываемое из других проектов (ссылки); 2)"Main" скрипт в каждом проекте, в котором находятся наборы функций, необходимых для выполнения тест кейса; и 3)"Local _Reference" скрипт, в котором находятся "локальные" функции, которые сделаны для того, чтобы не загромождать "Main" скрипт, облегчать процесс "понимания" скрипта, облегчать модификацию и т.д. Поясню зачем это нужно: при выполнении тестирования часто приходится повторять одни и те же действия по многу раз. Ясно, что иметь одинаковое описание этих действий (функцию или ее часть) во множестве скриптов совершенно неэффективно, тем более подумайте о процессе модификации такой функции при необходимости. Поэтому эта функция выносится в отдельное место (скрипт "Reference", или вообще в отдельную библиотеку, но пока не будем усложнять) и вызывается при необходимости. Таким образом, когда нужно будет исправить скрипт в этом месте работы, мы правим только одну вызываемую функцию и все. Далее: основной скрипт проекта ("Main") содержит основные функции проверки- например, 3 штуки: открыть форму, внести изменения, сохранить. Логично предположить, что 1 и 3 действия будут проделываться многократно при тестировании (хотя я заносил в скрипт "Reference" функции уже при однократном повторении). Поэтому выносим их. 2 действие выносить смысла нет, так как, допустим!, вносим какие-то уникальные изменения, для данной конкретной проверки.
Однако расписывать эту функцию прямо в мейн скрипте не стоит- потом сложно будет разбираться в этом нагромождении (как правило функции содержат в себе множество вызовов других функций). Поэтому выносим ее в скрипт "Local _Reference".

8. Структура: При написании функций и методов необходимо четко обозначать конечные действия: необходимо оценивать специфику работы приложения в контексте того или иного скрипта (функции). Например, при редактировании свойств на одной из вкладок свойств какого-либо класса, возможны 2 различных направления продолжения действий: либо сохранить\отменить, либо перейти на другую вкладку и редактировать свойства там. В таком случае эффективнее, с точки зрения процесса, будет писать функцию редактирования свойств, которая будет лишь "редактировать" свойства, но не сохранять\отменять или переходить на другие вкладки, оставляя возможность выбора дальнейших действий и, соответственно, возможность использования этой функции в максимальном количестве скриптов.

9. Структура: все функции и методы должны иметь уникальные имена. В скрипте функций ("Reference")- "говорящее название" (например, function DeleteChildClass()). в основном скрипте ("Main")- неполный номер ТС после названия функции. (например, function DeleteChildClass11231(), где А0011231- номер ТС). Это нужно для того, чтобы не путать фукнкции из "Local _Reference" и "Reference" скриптов. А это возможно, потому что один скрипт может содержать в себе одинаковые проверки, но с, допустим, различными данными: в одном случае это будет стандартная проверка (вызов из "Reference"), в другом- специфическая (вызов из "Local _Reference"). Действия почти одни и те же, имена функций похожи, но обязаны различаться.

10. В функции первым комментом должно идти описание того, что эта функция делает. (например, "// Создание "testclass""). Чтобы не ломать голову читая сам скрипт.

11. В "Main" скрипте также должно быть описание того, что этот ТС делает ("// создание класса ").

12. Все скрипты, обращающиеся к другим скриптам должны иметь ссылки на них в начале скрипта. Особенность инструмента. Собственно, без этого ссылки работать не будут.

13. Все функции должны иметь структуру "try-catch". Весь набор скриптов не должен останавливаться при выпадании исключения приложения.

14. Скрипт должен быть написан в соответствии с ручным ТС. То есть с выделением и обозначением шагов (групп шагов), предустановок и постустановок. (допускается copy\paste описания шага из ручного ТС).

15. Отправляемые в лог сообщения и ошибки должны быть понятны всем участникам разработки. Не забываем, что результаты прогонов автотестов будут смотреть все желающие.

16. Функции в скрипте должны быть разграничены: "\\***". Просто для облегчения восприятия. Отлично работает "сворачивание".

17. Скрипт должен безопасно работать с приложением (метод "terminate()" недопустим в обычных тестах).

18. Верификация "внешнего" вида (GUI) должна быть сведена к минимуму. Тестирование основано на описании состояний системы.

19. Чем большее количество свойств системы верифицируется- тем лучше

20. Необходимо учитывать связанность выполнения съюта тесткомплитом. тем не менее должна быть возможность собирания отдельных съютов для тестирования тех или иных задач.

21. Обращение к процессам и их объектам должно осуществляться через переменные ("w1 = p1.QAdminForm; w2 = w1.treeViewClass;").

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

23. После выполнения каждого скрипта должны быть выполнены соответствующие действия по возврату к исходному сосоянию (за исключением оговоренных случаев).

24. Все имена объектов и значения свойств, используемых в методах и функциях- из Object Brouser Тestcomplete методом copy\paste. Так как не все символы видимы в Object Brouser. (такие как пробел). Хотя тут нужно пинать разработчиков.

25. Координатный клик допустим только в исключительных случаях.

26. Структура скрипта должна быть удобна для понимания и выделения отдельных методов и вызовов функций.

27. BuiltIn.Delay() допустим только в исключительных случаях. Пользуемся методами Wait...

28. В названии объекта (к которому обрщаемся) должно быть указано максимальное количество постоянных неизменяемых символов. Есть вероятность появления похожих по названию объектов.

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

30. При удалении, модификации объектов метаданных, должна быть проведена дополнительная верификация работы с "нужным" объектом, где должны отразиться эти изменения (сугубо специфично).

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

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

33. Все новые скрипты должны добавляться в VSS (потом TFS). в конце дня- check in.

34. Приоритеты: сначала поддержка скриптов в актуальном состоянии, потом - создание новых скриптов.

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

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

37. copy\paste кода скрипта недопустим! скорость создания скриптов обеспечивается использованием уже написанных функций, а не копированием кода.

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

39. Все дополнительные приложения, вызываемые из скрипта, должны быть приведены к общему виду (например, во весь экран, масштаб 100%), а затем сравнены с эталоном.

40. Все скрипты должны использовать только БД, созданную для автоматизированного тестирования. каждый вечер она автоматически бэкапится.

41. Лучше чаще использовать возможности Object Brouser (свойства и методы), чем Recorder.

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

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

44. Структура скрипта должна предусматривать возможность запуска и выполнения скрипта под различными ОС (XP, Vista, Serv 03, 08) (первоначально- Vista и XP); То есть методы и функции должны быть написаны с учетов всех соответствующих различий в ОСах- необходимо максимально стремиться к унификации функций относительно различных ОС, в тех случаях, где это невозможно- должны быть написаны различные функции под все необходимые ОС, и взависимости от вида ОС, должны выбираться те или иные функции, методы, переменные и т.д.

45. В скрипте должно содержаться максимально допустимое количество проверок свойств приложения. (У каждого объекта существует несколько свойств, пригодных для верификации, обычно существует большое количество таких объектов в любой момент времени).

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

47. При выборе объектов, например, в дереве (tree) должен использоваться метод Select(), а не Click() там, где это возможно.

48. Необходимо учитывать, что на разных ОСях, на виртуалках и при удаленном доступе могут быть задержки выполнения скрипта. Поэтому необходимо использовать "Wait*" методы при написании скрипта там, где это возможно.

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

Правила написания тест кейсов

2009-09-24T15:26:00.000+04:00

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

1. у каждого тест кейса (ТС) уникальное имя и ID (Без этого никуда- ибо различать и не путать тест кейсы необходимо, а при наборе их в тестран такие вещи не исключение. Не забываем, что на один юз кейс может быть написано достаточно много очень похожих тест кейсов, но проверяющих совсем разные вещи или работающих в разных условиях. Необходимо их различать.) Напомню, что нумерацию тест кейсов я вводил на стадии формирования дерева юз кейсов. Делалось это примерно так: Уникальный номер тест кейса состоит из буквы (С- клиент(client), A -администратор (admin))и семи цифр. Если в указанном ниже номере присутствует менее семи цифр, необходимо добавить нужное количество нулей в конец номера. Например, тест кейс, где производится верификация количества попыток логина при неправильном пароле (первый в списке), имеет номер C1111100, второй C1112100:
1. Общие тесты приложения:
1.1 Логин:
1.1.1 Некорректный:
1.1.1.1 Некорректный пароль:
1.1.1.1.1 Количество попыток;
1.1.1.2 Корректный пароль:
1.1.1.2.1 Количество попыток;
В моем случае основной состав дерева был уже сформирован, когда пришло время браться за нумерацию. Поэтому прикинуть необходимое количество цифр для номера труда не составило. Однако необходимо помнить о вероятных перестановках структуры дерева и практически 99%ных добавлениях новых тест кейсов, и предусмотреть возможные перекомбинации номеров.

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

3. Предустановки- обязательны. (как правило, каждый ТС должен быть доступен для выполнения как в составе съюта, так и в составе произвольного набора ТС; так и в отдельности от других ТС). Соответственно должны (могут) быть описаны действия по завершению ТС, но не входящие в его тело- "постустановки" (особенно для автоматизированного тестирования).

4. Версия ТС- обязательна для заполнения и отслеживания. Формируется от "0.01". Версии изменения самих шагов (непринципиальные): +0.01. Версии изменения последовательности шагов (наряду с изменениями внутри некоторых шагов): +0.1 (с округлением: 0.14->0.20).Версии глобальных изменений (или крупных и многочисленных изменений в соответствии с предыдущим вариантом) +1.00 (1.23->2.00).

5.нумерация шагов- по порядку. Без комментариев :)

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

7. Ожидаемый результат (Result)- конкретное описание состояния приложения или конкрентой его части. должно включать в себя не только описание текущего объекта(ов), но и окружающую среду. Например, при тестировании ввода текста в ворде должно быть описано не только то, что текст введен, но и то, что он имеет стандартный формат, не выделен, не курсив и т.д., а также, что ворд имеет стандартный вид (отображены стандартные кнопки\панели, и не имеет "специальных" "отклонений", которые могут быть вызваны дополнительными действиями пользователи или машины).

8. В Любом корректном ТС должно быть не более 10-12 шагов. Отдельные исключительные случаи оговариваются отдельно.

9. При написании ТС необходимо руководствовавться всей доступной информацией для отражения последних (и возможных!) изменений приложения. Необходимо закладывать на будущее вероятность изменений приложения и заранее обдумывать принцип построения ТС для последующей модификации (если таковая понадобиться) при наименьших временных и ресурсных затратах.

10. Шаги в ТС должны быть описаны четко и понятно даже для неподготовленного человека, но тем не менее должны быть описаны в соответствии с принятым глоссарием, который формируется параллельно. При принятии решений о переименовании того или иного объекта или действия все ТС должны быть модифицированы централизованно.

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

12. Поиск шагов(слов, действий) в ТС должен осуществляться автоматическими средствами поиска (например, ctrl+F). Здесь есть, конечно, некая зависимость от среды, где хранятся ТС.

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

14. Недопустим Copy\Paste и последующее сохранение ТС (при создании нового или модификации существующего ТС). Допустим вариант: создание, Copy\Paste, внесение изменений в атрибуты ТС (номер, название, цель, и тд), внесение изменений в тело ТС, и только потом сохранение. Хотя выгоднее писать каждый ТС с нуля, все мы помним о времени.

15. Все ТС должны быть структурированы и сгруппированы по тестируемому функционалу.

16. Допускается создание необходимого количества съютов, для регрессионного тестирования. Вопрос должен обсуждаться индивидуально для каждого случая. Помня о времени, затрачиваемом на разработку вообще и на тестирование в частности, правильнее будет собрать набор только из ТС, которые необходимо протестировать, а не из всех подряд.

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

18. Все баги, дефекты, недочеты должны быть сколлекционированы (баги в систему багтрекинга, по недочетам, неточностям- отсылка писем, сообщений, вопросов). ТС должен быть написан, даже если существует баг, непозволяющий его выполнить на данный момент. При этом в ТС ставится пометка, что он bloked by #### (номер бага) и незакончен для редактирования(в системе багтрекинга этому багу проставляются номера ТС, на которые он влияет, чтобы после фикса бага не искать их; теем не менее должен быть проведен автоматический поиск по ТС, так как на момент постинга бага в систему окончательно не известно- все ли ТС тестирующие эту область написаны.Могут быть написаны новые ТС.). Как только баг пофиксен- ТС должен быть закончен и включен в исполняемые съюты.

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

20. Все существенные изменения должны быть задокументированиы автором изменений и хранится в связке с каждым ТС, который был модифицирован. То есть должны быть: дата , автор, характер изменений (или сами изменения). Можно взять за основу комментарий к чекину, но чекинить за один раз придется по одному модифицированному ТС.

21. Все ТС должны быть в актуальном состоянии. Допускается "запаздывание" актуализации при неясном окончательном функционале. Не допускается начало работ по актуализации ТС при неясном окончательном функционале. Никому не нужна лишняя бесполезная работа.

22. Все баги должны быть покрыты ТС-ами. Все требования должны быть покрыты ТС-ами. Весь описанный функционал должен быть покрыт ТС-ами. В идеале :)

23. Все результаты выполнения тестирования должны хранится в системе учета и хранения результатов. Или в любом доступном, подходящем месте.

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

25. Сначала должны быть описаны положительные ТС, потом отрицательные. Допускается одновременное внесение в план обоих типов ТС.

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

Проект одного тестировщика часть 4

2009-09-23T16:04:00.000+04:00

Итак- конвейер заработал. Автотесты прогонялись, тест кейсы писались, скрипты автотестов совершенствовались, дополнялись и увеличивались в количестве. Конечно, это происходило не так быстро как хотелось бы, ведь были еще и задачи в рамках ручного тестирования, и в рамках других направлений. Поэтому, как и считается, лучше иметь выделенного тестировщика, который будет заниматься автотестами и только ими (ну может быть за редким исключением). Потому что даже просто переключиться между задачами по
кодированию и, например, по ручному тестрованию одного из множества приложений- осуществить быстро практически невозможно, на это в любом случае необходимо время. Необходимо помнить об этом и во время планирования работ отдела тестрования, но.. опять я забегаю вперед...
Примерно к этому моменту у нас появился TFS от всем известной конторы. Перенос багов, зарепорченных в старую систему, решено было не делать. Просто какое-то время использовались обе системы, а когда непофиксенных остались единицы (в старой системе)- перенес их ручками. Все проекты ТестКомплита перенес туда же- на хранение и отслеживание изменений в tfs. Очень удобно иметь систему, в которой можно залинковать все тестовые артефакты друг на друга. Есть встроенная система управления требованиями. Они линкуются на задачи, баги. Эти в свою очередь - на тест кейсы (скрипты автотестов) и т.д. Таким образом всегда можно увидеть почему те или иные автотесты не выполняются успешно; то есть посмотреть, какие баги необходимо пофиксить\задачи выполнить, для успешного прохождения тестрана, и, сответственно, для закрытия итерации разработки (если таковые венчаются успешным тестрованием). На основе этой же системы был организован билд сервер, который автоматически собирал билды после каждого чекина. Таким образом у нас уже имелся некоторый набор билдов, который можно было хранить и при необходимости на него ссылаться. Решено было хранить только релизные (итерационные) билды (итерация - каждую неделю). По поводу необходимости- в баг репорте ставится ссылка на билд, в котором найден этот баг, и при необходимости всегда можно на этот баг посмотреть. А также плезно всегда иметь под рукой версии, которые были отданы (здесь обычно пишут- заказчику, но у нас все гораздо сложнее)(зарелизены).
К этому моменту уже длительное время было ясно, что одному ворочать все это дело невозможно. Поэтому на начальство регулярно сыпались заявления, типа "сделаю по максимуму, но вот если бы у нас были еще тестировщики, мы бы такого наваяли, что ух...".
Когда стало ясно, что расширению быть, встал вопрос- как организовать свою работу так, чтобы и уделять время обучению новичков, введению их в курс дела, ответам на море вопросов, и успевать справляться с текущими делами. Были недолгие раздумия и воспоминания чего же мне было нужно самому, чтобы максимально быстро освоиться в новой компании и влиться в процесс разработки. Как результат- решил написать правила и регламенты по основным деятельностям в области тестирования. Лучше потратить немного времени на описание процесса, нежели несколько раз рассказать это нескольким людям, а потом еще и пересказывать по мере необходимости. Всегда проще и быстрее ткнуть туда, где можно прочитать. А потом при необходимости задать вопросы, причем в нужное (оговоренное) время. Потом получилась очень приличная экономия. Эти правила в
ближайшее время и выложу сюда. Но они будут достаточно специфичными, заточенными под конкретную организацию и конкретные инсрументы, хотя в их полезности не сомневаюсь. Может кому и сгодится. А вообще эти посты в первую очередь для меня самого и моих коллег:)
Правила разместил в общем доступе- в нашей вики. Там же разместил и список линков на инет источники, которые на мой взгляд содержат полезную информацию. Так как по тестированию вообще и по его частностям написано уже не мало литературы, решил не повторяться и создать на базе тфс библиотеку тестировщика, в которую вошли (и пополняются) произведения, подходящие под нашу специфику. В том числе и журналы по
тестрованию ПО, коих сейчас выпускается в достаточном количестве. Некоторые линки: http://it4business.ru/forum/forum192.html
http://software-testing.ru/
http://www.qatutor.com/
http://javascript.ru/tutorial/basic/types
http://alexeybulat.blogspot.com/2008/05/dynat.html
http://openquality.ru/news/
http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB46
http://blogs.msdn.com/micahel/archive/2004/06/09/151778.aspx
http://www.satisfice.com/blog/
http://www.satisfice.com/kaner/
http://bugsclock.blogspot.com/
http://www.protesting.ru/
http://www.stsc.hill.af.mil/crosstalk/2002/04/leishman.html
http://www.context-driven-testing.com/
http://www.stickyminds.com/testandevaluation.aspObjectType=MIXEDTA&function=Search&newtopcat=SWTST
http://googletesting.blogspot.com/
http://www.linuxtopia.org/online_books/javascript_guides/javascript_faq/index.htm
http://blog-of-roman.blogspot.com/2008/07/cmmi.html
http://pankratov.org.ua/
http://blogs.msdn.com/imtesty/default.aspx
http://zibsun.livejournal.com/

Проект одного тестировщика часть 3

2009-09-22T10:16:00.000+04:00

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

1. Этап подготовки, включающий в себя создание выделенного тестового окужения. На данном этапе ограничился лишь выделением БД, которые больше никем использоваться не будут, а также необходимо было решить вопрос их восстановления на начальный уровень. (Все остальные задачи, такие как выделение тестовых машин, серверов и др. решались позже). Напомню, что при работе приложения с БД, при автоматизированном тестировании необходимо иметь стабильные, зафиксированные данные для обеспечения возможности верификации. Этот вопрос решил созданием 2 баз- основная и ее бекап, и добавил политики безопасности, чтобы работать с ними никто кроме меня не мог. Запуск автотестов решено было организовать в ночь, чтобы не занимать мою тестовую машину днем, а также чтобы не слишком грузить сервер в течение дня, потому как выполнение автотестов требует до 60% процессора. Таким образом оставалось лишь сделать автоматическое восстановление базы с ее бекапа, и, так как это тоже требовало времени (в моем случае около 2 часов), рассчитать время запуска восстановления. Чтобы оно завершилось к моменту запуска автотестов. Что и было с успехом выполнено.

2. Написание тест кейсов по первым пунктам тест плана. Вернее сначала был написан сам тест план. Это было сделано следующим образом. Документация на тот момент уже имелась, работоспособное приложение- тоже. Поэтому решено было для начала выделить области приложения, которые будут содержать тесты одной функциональной группы. То есть сгруппировал юз кейсы (именно юз кейсы) по функциональным признакам. Юз кейсы писал используя спек и приложение. Таким образом получилось дерево юз кейсов. Примерный вид:
1. Общие тесты приложения
1.1 Логин:
1.1.1 Корректный;
1.1.2 Некорректный;
Далее производилось необходимое уточнение, более мелкая разбивка. А потом на каждый юз кейс осталось написать необходимое количество тест кейсов. Что и было сделано. Тут же следует отметить, что когда было готово дерево юз кесов (ну почти готово, так как изменения все равно впоследствии вносились), решено было задать номера юз кейсов, как на примере. Таким образом выстроилась система нумерации тест кейсов, что позволило избежать путаницы в будущем и оптимально разбить группы по номерам. Причем это было сделано так, что просто по номеру сразу можно было определить принадлежность конкретного тест кейса к той или иной группе, и при невыполнении его сразу прикинуть какой функционал неработоспособен. Во время написания тест кейсов возник стандартный вопрос- где их лучше всего хранить. Причем сразу заинтересовала возможность хранить где-нибудь рядом и результаты их выполнения. Но так как ТестКомплит предоставляет
отличный лог выполнения, который можно и экспортировать и отсылать на мыло автоматически, решено было хранить результаты все же отдельно от тест кейсов. (Обращу внимание, что ручного тестирования в больших количествах не предполагалось). Также хотелось сделать хранение в свободном доступе, с возможностью редактирования, журналирования. В результате остановился на той же вики. Были проблемы при размещении там таблиц, но они быстро решились установкой необходимых плагинов. А тест кейс у меня представляет собой таблицу с набором необходимых полей и их значений:
Имя: Название тест кейса
ID: С1312000
Приоритет: 1
Цель: верификация меню.
Источник: спек, требования...
Категория: Functional
Предустановки: Приложение запущено.
Type: Manual
Version 0.01
Исполнительная часть:
Action Expected Result

3. В итоге на некоторый момент имелся набор тест кейсов. Не забываем, что чем раньше будет введено в эксплуатацию автоматическое тестирование, тем лучше (это в моем конкретном случае). Поэтому решил выделить некоторую группу тест кейсов и написать по ним скрипты автотестов. О порядке формирования такой группы напишу отдельно, скажу сразу, что нужно было определиться с функционалом, который необходимо тестировать именно в первую очередь. Какие-то вещи могут и подождать. По мере написания скриптов вырабатывались некие правила, стандарты, о которых тоже напишу отдельно. Это включало в себя "стандартизацию" скриптовых элементов и вынесение этих элементов в отдельное хранилище для облегчения и укорения последующей модификации и ускорения написания новых скриптов. Это хранилище потом планировалось оформить в библиотеку длл. Затем была отладка скриптов, тестирование, анализ результатов, подготовка к автоматическому запуску.
Так же при написании необходимо было учесть, что прогоняться автотесты планировалось на нескольких ОС, что накладывало свой отпечаток. Отмечу, что разные Windows имеют разные особенности в таких моментах, как пути до вроде бы стандартных папок и каталогов, и самое главное- различные пути до объектов на форме приложения. Поэтому приходится придумывать решения, которые позволяют обойти такие моменты.
Еще один немаловажный фактор- я заранее знал, что интерфейсы наших приложений будут переделаны. Не уточнялось только- когда это будет. Тем не менее тестировать существующую реализацию тоже необходимо. Соответственно решено было писать скрипты так, чтобы при переделках интерфейса минимизировать апдейт скриптов ибо время-деньги, лень и т.д. Какое-то время раздумывал над возможностью такой реализации. Потом
принял рещение использовать Model Based Testing - тестирования, основанного на описаниях состояний системы и их изменениях (абстрагируемся от GUI). Это позволило мне иметь в каждый конкретный момент времени большинство работающих скриптов и минимизировать время на отладку остальных из-за изменений приложения.
В общем итоге - такой набор позволил мониторить состояние основных функций софта в каждый конкретный момент времени, что позволило постепенно переключаться на другие пункты тест плана, и другие задачи.

Проект одного тестировщика часть 2

2009-09-18T14:15:00.000+04:00

Продолжая, вспоминаю, "как все начиналось".
Поставил себе несколько целей на начальном этапе:

1. Побыстрее перезнакомиться со всеми разработчиками и
изменить их (существующее на тот момент) отношение к тестированию вообще и тестировщикам в частности. Благо некоторые из них все прекрасно понимали, некоторые получали команды сверху типа "оказывать всяческое содействие", ну а с некоторыми мы ходили пить пиво. Тут стоит упомянуть, что для этого необходимо было заранее заручиться 100% поддержкой сверху. Ибо если начальство не заинтересовано в
организации тестирования, если оно не видит в этом смысла или не может подсчитать ROI- ничего хорошего от внедрения процесса тестирования не получится.

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

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

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

5. Так как задумывалось регрессионное тестирование проводить в автоматическом режиме, необходимо было подобрать оптимальный инструмент для этого дела. Сразу скажу, что решение об использовании автоматизации принималось без меня. Но оно вполне обосновано, если учесть, что клиентских приложений второго типа (см.
предыдущий пост) планировалось великое множество. Про выбор средств автоматизации написано достаточно много, есть тренинги. Чем я с удовольствием и воспользовался. Итак- на входе были следущие требования в инструменту: бесплатный или максимально дешевый (дело было в разгар кризиса, который наложил свой
отпечаток :( ), обладал возможностью проведения тестирования Win приложений, web приложений, нагрузочного тестирования. Напомню, что требовалось тестировать: связка клиент-сервис-БД и 2 типа приложений (в первом
можно создавать второй). Здесь куча всяческих ограничений, которые необходимо было учесть при выборе, которые при необходимости опишу позже. Также должна была быть возможность интеграции с VSS (и TFS в будущем), а также с Visual Studio 2008.Наверное не все вспомнил, но пусть так будет. В результате бесплатные инструменты как-то отпали по мере ознакомления, а из доступных платных остались TestComplete и
QTP. Триальные версии обоих были успешно установлены и сравнивал уже непосредственно "в деле". К слову, у обоих достаточно понятная документация, некоторые вещи даже на русском языке есть, помог форум на ресурсе
it4business.ru Это позволило достаточно быстро разобраться и пробовать применять инструменты в необходимых направлениях. По итогам выбран был TestComplete 6*.
Завершилась эта задача намного позже, чем остальные. Все помнят простую истину- нельзя автоматизировать
то, чего нет.

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

Проект одного тестировщика

2009-09-17T12:47:00.000+04:00

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

Тут нужно прокомментировать особенность софта: клиентская часть представляла из себя: 1) толстого клиента, основная цель которого- создание прикладного ПО; и 2) толстого и веб клиентов, которые и представляли из себя это прикладное ПО, причем в неограниченном количестве приложений. Сервис представлял из себя сервис, через который работала вся эта прорва клиентов с другой прорвой-базами данных (реляционными и не реляционными, актуальными и не очень, популярными и редкими). Клиентов решили сделать кроссплатформными (Win\Unix). А создание клиентов типа 2) доступным для непрограммистов (по крайней мере на высокоуровневых языках).
И вот на этапе, когда по всем направлениям ведется разработка, сделаны достаточно большие наработки. И даже написано немного документов, описывающих реализацию, пришел тестировщик...

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

PS: Вообще думал написать статью, но опасаюсь ее размера. А "многа букаф", как известно, многие могут не осилить :) По частям и комментировать удобнее и обсуждать.

Время для первого сообщения

2009-09-17T12:20:00.000+04:00

Вот кажется и нашлось оно... время. Время для ведения блога.

Как известно: "Найди время, а не оправдания." Я нашел.)

Решил поделиться мыслями о тестировании ПО, но не только об этом. А также разбавить примерами из реального опыта одного тестировщика.