Привет.
В этом блоге новых постов не предвидится, по крайней мере в ближайшее время.
Всё новое и интересное про тестинг в моей интерпретации теперь тут
среда, 16 июня 2010 г.
четверг, 10 июня 2010 г.
Рынок труда: что делает тестировщика востребованным
На написание этого поста меня натолкнул один из постов на STC.
Вопрос звучал так "Что работодатели хотят от кандидатов на позицию тестировщика". Однако, вопрос поставленный таким образом не имеет конкретного ответа. Это обусловлено тем, что заказчики, позиции и проекты - разные и каждая уникальная комбинация этих состовляющих может требовать от кандидата определённый набор навыков и умений.
Я осмелюсь переформулировать вопрос: "Что делает тестировщика востребованным?"
Не вдаваясь в глубокие размышления, я бы выделил следующие 10 пунктов (естественно список не конечный):
01. Способность и желание обучаться (тестировщик должен быть про-активным, он должен всё время развивать и усиливать свои навыки)
02. Сильные коммуникативные навыки (общение внутри команды, общение с заказчиком, обучение менее опытных коллег "по цеху" - например, в виде воркшопов, семинаров, презентаций и т.п.)
03. Понимание процессов и методов тестирования и обеспечения качества (причём, чем глубже понимание, тем лучше; хороший тестировщик должен бысть способен изучить и поанализировать процесс, чтобы предлогать различного рода улучшения)
04. Знание смежных областей (таких как: разработка, менеджмент, маркетинг - это помогает понять бизнес идеи проектов и эффективно направлять усилия тестирования)
05. Ответственность (тестировщик должен быть не только в состоянии отвечать за свои непосредственные обязанности, но и брать инициативу на выполнение более сложных комплексных задач, тем самым принося больше пользы в рамках всего проекта)
06. Внимание к деталям (не только в тестировании, но и во всём проекте)
07. Организованность (умение организовать свою деятельность (в различных её аспектах) высвобождает время, которое можно использовать для высокоуровневых задач, таких как улучшения процессов, изучение передовых практик, оптимизацию выполнения имеющихся задач...)
08. Октрытость новым идеям (умение мыслить вне ограничений и рамок, выдающийся тестировщик не только использует методы и теории других, но и пытается что-то улучшить, придумать новое - переизобретает тестирование)
09. Желание делиться знаниями (чтобы приносить максимальную пользу, знания должны быть достоянием всей команды, а не только отдельных её членов)
10. Энтузиазм и желание "ломать" ("An enthusiasm for breaking things" как сказал Джеймс Виттакер (J. Whittaker), описывая качества хорошего тестировщика).
Так что, если вы осознаёте, что обладаете всем вышеперечисленным - поздравляю, вы востребованный специалист на рынке тестирования ПО.
Вопрос звучал так "Что работодатели хотят от кандидатов на позицию тестировщика". Однако, вопрос поставленный таким образом не имеет конкретного ответа. Это обусловлено тем, что заказчики, позиции и проекты - разные и каждая уникальная комбинация этих состовляющих может требовать от кандидата определённый набор навыков и умений.
Я осмелюсь переформулировать вопрос: "Что делает тестировщика востребованным?"
Не вдаваясь в глубокие размышления, я бы выделил следующие 10 пунктов (естественно список не конечный):
01. Способность и желание обучаться (тестировщик должен быть про-активным, он должен всё время развивать и усиливать свои навыки)
02. Сильные коммуникативные навыки (общение внутри команды, общение с заказчиком, обучение менее опытных коллег "по цеху" - например, в виде воркшопов, семинаров, презентаций и т.п.)
03. Понимание процессов и методов тестирования и обеспечения качества (причём, чем глубже понимание, тем лучше; хороший тестировщик должен бысть способен изучить и поанализировать процесс, чтобы предлогать различного рода улучшения)
04. Знание смежных областей (таких как: разработка, менеджмент, маркетинг - это помогает понять бизнес идеи проектов и эффективно направлять усилия тестирования)
05. Ответственность (тестировщик должен быть не только в состоянии отвечать за свои непосредственные обязанности, но и брать инициативу на выполнение более сложных комплексных задач, тем самым принося больше пользы в рамках всего проекта)
06. Внимание к деталям (не только в тестировании, но и во всём проекте)
07. Организованность (умение организовать свою деятельность (в различных её аспектах) высвобождает время, которое можно использовать для высокоуровневых задач, таких как улучшения процессов, изучение передовых практик, оптимизацию выполнения имеющихся задач...)
08. Октрытость новым идеям (умение мыслить вне ограничений и рамок, выдающийся тестировщик не только использует методы и теории других, но и пытается что-то улучшить, придумать новое - переизобретает тестирование)
09. Желание делиться знаниями (чтобы приносить максимальную пользу, знания должны быть достоянием всей команды, а не только отдельных её членов)
10. Энтузиазм и желание "ломать" ("An enthusiasm for breaking things" как сказал Джеймс Виттакер (J. Whittaker), описывая качества хорошего тестировщика).
Так что, если вы осознаёте, что обладаете всем вышеперечисленным - поздравляю, вы востребованный специалист на рынке тестирования ПО.
понедельник, 7 июня 2010 г.
Обучение на новом уровне: Транспекция
Выдающиеся тестировщики всегда ищут пути и способы для само- и просто образования. В качестве таких путей обычно выступают: профессиональная и не очень литература, конференции, семинары/вебинары, обучение у более опытных коллег, форумы, сообщества, блоги...
Однако сейчас я хочу обратить внимание на такой способ самообучения, как Транспекция (Transpection). В общих чертах Транспекция – обучение путём взгляда на предмет изучения с позиции другого человека.
В наиболее распространённом варианте (например, у Джеймса Баха и Майкла Болтона) транспекция проводится в виде диалога (живого или через клиенты IM), в котором человек, проводящий транспекцию задаёт вопросы собеседнику, чтобы узнать, оценить и понять восприятие проблемы последним. В тоже время первый избегает выражения своего мнения, чтобы не влиять на субъективное мнение своего собеседника – тем самым максимизируя полезность транспекции.
Транспективные диалоги проводятся для того, чтобы использовать знания, точку зрения и методы другого профессионала в противопоставление своим собственным, чтобы найти оптимальное решение поставленной задачи.
Этот метод понимания вещей был придуман Магоро Маруямой (Magoroh Maruyama) в далёком 1969 году. Более развёрнуто и подробно можно прочитать у Джеймса Баха тут.
Подводя итог, хочу сказать, что если в споре рождается истина, то в транспективном диалоге – более глубокое понимание.
Однако сейчас я хочу обратить внимание на такой способ самообучения, как Транспекция (Transpection). В общих чертах Транспекция – обучение путём взгляда на предмет изучения с позиции другого человека.
В наиболее распространённом варианте (например, у Джеймса Баха и Майкла Болтона) транспекция проводится в виде диалога (живого или через клиенты IM), в котором человек, проводящий транспекцию задаёт вопросы собеседнику, чтобы узнать, оценить и понять восприятие проблемы последним. В тоже время первый избегает выражения своего мнения, чтобы не влиять на субъективное мнение своего собеседника – тем самым максимизируя полезность транспекции.
Транспективные диалоги проводятся для того, чтобы использовать знания, точку зрения и методы другого профессионала в противопоставление своим собственным, чтобы найти оптимальное решение поставленной задачи.
Этот метод понимания вещей был придуман Магоро Маруямой (Magoroh Maruyama) в далёком 1969 году. Более развёрнуто и подробно можно прочитать у Джеймса Баха тут.
Подводя итог, хочу сказать, что если в споре рождается истина, то в транспективном диалоге – более глубокое понимание.
среда, 2 июня 2010 г.
Тестирование ПО и содействие в обеспечении качества
В отрасли информационных технологий очень широко распространено мнение, что обеспечение качества – задача тестировщиков. На мой взгляд, мнение – довольно спорное, поскольку тестировщик не может напрямую влиять на качество, соответственно – обеспечить его не может.
Я так считаю потому что, в большинстве случаев (беру страны пост-СССР), тестировщик:
- не задействован в коммуникации с заказчиком
Т.е. он не может вносить никаких изменений на уровне полльзовательских историй (например, не может изменить форму пользовательских историй, не участвует в выборе более качественных, не влияет на декомпозицию (разбиение) пользовательских историй, ...)
- не может контролировать объём работ (scope)
Список функциональности к разработке на итерацию в большинстве случаев согласовывается между тремя участиками: заказчик, менеджер и лидером команды разработки (тех. лид)
- не влияет на расписание/планирование
Я имею ввиту то, что при планировании разработки функциональности очень редко учитывается точка зрения тестировщика, который рассматривает скоуп с точки зрения оптимальной последовательности тестирования функциональностей
- не контролирует бюджет
Т.е. не имеет возможности при необходимости привлечь дополнительные человеческие или временные ресурсы (за редким исключением)
- не участвует в наборе/отборе кадров
Тут конечто не совсем всё плачевно, поскольку иногда на собеседование кандидатов приглашают тест лида проекта, однако для рядовых тестировщиков это поле деятельности остаётся вне компетении
- не имеет возможности изменять исходный код
Во-первых, потому что у основной массы тестировщиков на постсоветском пространстве просто не хватает для этого навыков. Во-вторых, потому что даже если навыки есть, доступ к исходному коду не всегда легко/возможно получить кому-то кроме команды разработки
- не влияет на расположение продукта на рынке
Для этого у заказчика есть маркетинговая команда, которая делает всю рабоду по позиционированию продукта
- не может вносить изменения в модель разработки
Тут, я думаю, комментарии излишни
Так как же тестировщик может обеспечить качество при таком раскладе?
На самом деле, тестировщик не может обеспечить качество, ему даже пытаться не стоит. Решения касательно качества и его обеспесения принимаются разработчиками, которые пишут код и менеджерами, которые ведут проект.
С этой точки зрения , когда тестировщик делает работу хорошо, он – предоставляем ценную, своевременную информацию о фактичестком состоянии продукта и проекта. Не тестировщик отвечает за качество, тестировщик лишь помогает людям, ответственным за качество и влияющие на него факторы, принимать грамотные решения.
Резюмируя, фраза «тестирование ПО и обеспечение качества» (Software Testing and Quality Assurance) будет правильнее в виде: «тестирование ПО и содействие в обеспечении качества» (Software Testing and QA Assistance)
Я так считаю потому что, в большинстве случаев (беру страны пост-СССР), тестировщик:
- не задействован в коммуникации с заказчиком
Т.е. он не может вносить никаких изменений на уровне полльзовательских историй (например, не может изменить форму пользовательских историй, не участвует в выборе более качественных, не влияет на декомпозицию (разбиение) пользовательских историй, ...)
- не может контролировать объём работ (scope)
Список функциональности к разработке на итерацию в большинстве случаев согласовывается между тремя участиками: заказчик, менеджер и лидером команды разработки (тех. лид)
- не влияет на расписание/планирование
Я имею ввиту то, что при планировании разработки функциональности очень редко учитывается точка зрения тестировщика, который рассматривает скоуп с точки зрения оптимальной последовательности тестирования функциональностей
- не контролирует бюджет
Т.е. не имеет возможности при необходимости привлечь дополнительные человеческие или временные ресурсы (за редким исключением)
- не участвует в наборе/отборе кадров
Тут конечто не совсем всё плачевно, поскольку иногда на собеседование кандидатов приглашают тест лида проекта, однако для рядовых тестировщиков это поле деятельности остаётся вне компетении
- не имеет возможности изменять исходный код
Во-первых, потому что у основной массы тестировщиков на постсоветском пространстве просто не хватает для этого навыков. Во-вторых, потому что даже если навыки есть, доступ к исходному коду не всегда легко/возможно получить кому-то кроме команды разработки
- не влияет на расположение продукта на рынке
Для этого у заказчика есть маркетинговая команда, которая делает всю рабоду по позиционированию продукта
- не может вносить изменения в модель разработки
Тут, я думаю, комментарии излишни
Так как же тестировщик может обеспечить качество при таком раскладе?
На самом деле, тестировщик не может обеспечить качество, ему даже пытаться не стоит. Решения касательно качества и его обеспесения принимаются разработчиками, которые пишут код и менеджерами, которые ведут проект.
С этой точки зрения , когда тестировщик делает работу хорошо, он – предоставляем ценную, своевременную информацию о фактичестком состоянии продукта и проекта. Не тестировщик отвечает за качество, тестировщик лишь помогает людям, ответственным за качество и влияющие на него факторы, принимать грамотные решения.
Резюмируя, фраза «тестирование ПО и обеспечение качества» (Software Testing and Quality Assurance) будет правильнее в виде: «тестирование ПО и содействие в обеспечении качества» (Software Testing and QA Assistance)
вторник, 1 июня 2010 г.
Исследовательское Тестирование: констатирование фактов
Общаясь с коллегами тестировщиками, я очень часто слышу такие термины, как "тестирование методом свободного поиска" и "исследовательское тестирование". Под обоими терминами подразумевается Exploratory Testing - термин, который официально ввёл Кейнер (Cem Kaner) в 1983м, а позже стал использоваться основоположниками школы контестного тестирования для замены термина "ad hoc", снискавшего дурную славу в то время.
В русском эквиваленте я предпочитаю называть Exploratory Testing Исследовательским Тестированием (далее ИТ). Определение Кейнера звучит примерно так: ИТ – процесс тестирования заключающий в себе единовременно: разработку тестов (test design), их выполнение (test execution), и получение знаний о тестируемой системе (learning). Процесс тестирования в данном случае выглядит не как создание тестов и их последующее выполнение, а скорее протекает по следующему алгоритму:
1. Тестировщик тестирует систему, тем самым получае некоторые знания о ней.
2. Восполняет пробелы в информации о системе из других источников (документация, команда разработки, менеджер...)
3. На основе собранных знаний, тестировщик разрабатывает новые тесты.
Т.е. получается, что оракул (Oracle – своего рода набор оценочных критериев) эволюционирует каждый раз, когда тестировщик тестирует (часть ИТ, где он получает знания о системе).
Более современное определение (опять же Кейнера), ИТ - стиль тестирования ПО, в котором особо сильное значение имеет личная свобода и ответственность индивидуального тестировщика, направленная на непрерывное повышение качества его работы, и рассматривающий обучение во время тестирования, разработку тестов, их выполнение и интерпретацию результатов как взаимодополняющие активности, которые выполняются параллельно на протяжении всего проекта.
Исследовательское Тестирование – очень распространённый вид тестирования, которым пользуется каждый компетентный тестировщик. Например, после того как разработчик исправил дефект (выставил ему Fixed) и переназначил его обратно на тестировщика, который написал отчёт об этом дефекте – тестировщик не только убеждается, что дефект исправлен, но и проводит тестирование смежных функциональностей (workaround).
Тут имеем:
1. Изначально – заранее запланированный и подготовленный тест, который выявил дефект.
2. Ряд тестов, которые проверяют смежные функциональности (или ту же функциональность в более общем или конкретном виде) - тесты не запланированные и не задокументированные, они разрабатываются, прогоняются и оцениваются в тот конкретный момент, когда тестируются смежные функциональности, а это – ИТ.
Качество такого тестирования будет сильно зависеть от способностей тестировщика создавать тесты и находить дефекты. Однако, такой подход к тестированию обозначает непрерывное совершенствование - чем больше тестировщик знает о системе и методах тестирования, тем лучше будет тестирование.
В русском эквиваленте я предпочитаю называть Exploratory Testing Исследовательским Тестированием (далее ИТ). Определение Кейнера звучит примерно так: ИТ – процесс тестирования заключающий в себе единовременно: разработку тестов (test design), их выполнение (test execution), и получение знаний о тестируемой системе (learning). Процесс тестирования в данном случае выглядит не как создание тестов и их последующее выполнение, а скорее протекает по следующему алгоритму:
1. Тестировщик тестирует систему, тем самым получае некоторые знания о ней.
2. Восполняет пробелы в информации о системе из других источников (документация, команда разработки, менеджер...)
3. На основе собранных знаний, тестировщик разрабатывает новые тесты.
Т.е. получается, что оракул (Oracle – своего рода набор оценочных критериев) эволюционирует каждый раз, когда тестировщик тестирует (часть ИТ, где он получает знания о системе).
Более современное определение (опять же Кейнера), ИТ - стиль тестирования ПО, в котором особо сильное значение имеет личная свобода и ответственность индивидуального тестировщика, направленная на непрерывное повышение качества его работы, и рассматривающий обучение во время тестирования, разработку тестов, их выполнение и интерпретацию результатов как взаимодополняющие активности, которые выполняются параллельно на протяжении всего проекта.
Исследовательское Тестирование – очень распространённый вид тестирования, которым пользуется каждый компетентный тестировщик. Например, после того как разработчик исправил дефект (выставил ему Fixed) и переназначил его обратно на тестировщика, который написал отчёт об этом дефекте – тестировщик не только убеждается, что дефект исправлен, но и проводит тестирование смежных функциональностей (workaround).
Тут имеем:
1. Изначально – заранее запланированный и подготовленный тест, который выявил дефект.
2. Ряд тестов, которые проверяют смежные функциональности (или ту же функциональность в более общем или конкретном виде) - тесты не запланированные и не задокументированные, они разрабатываются, прогоняются и оцениваются в тот конкретный момент, когда тестируются смежные функциональности, а это – ИТ.
Качество такого тестирования будет сильно зависеть от способностей тестировщика создавать тесты и находить дефекты. Однако, такой подход к тестированию обозначает непрерывное совершенствование - чем больше тестировщик знает о системе и методах тестирования, тем лучше будет тестирование.
Подписаться на:
Сообщения (Atom)
