среда, 15 сентября 2010 г.

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

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

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

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

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

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

пятница, 28 мая 2010 г.

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

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

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

четверг, 15 апреля 2010 г.

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

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

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

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

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

среда, 24 марта 2010 г.

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

оцениваем:

http://www.computerpowertest.com/

пятница, 12 марта 2010 г.

440 Web Test Tools

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

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


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

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

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

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

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

суббота, 27 февраля 2010 г.

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

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

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

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

необходимые:
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. :)

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

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

четверг, 11 февраля 2010 г.

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

Для тех, кто еще не знает, зачем пишутся спецификации- 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;
обнаружение ошибок и восстановление после сбоев;
использование памяти;
внешние БД и СУБД;
распределенные данные и контроль над всей сетью распределения;
основные подходы к контролю;
распараллеливание и синхронизация;
механизмы взаимодействия;
управление другими ресурсами.


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

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

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


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

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


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

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

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


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


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

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

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

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

Глоссарий:

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

среда, 10 февраля 2010 г.

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

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

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


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

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

четверг, 4 февраля 2010 г.

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

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

Болтон предлагает использовать его так:
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."
Скоро закончу перевод очередной статьи.
Также на подходе много новых статей и заметок.

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