Привет.
В этом блоге новых постов не предвидится, по крайней мере в ближайшее время.
Всё новое и интересное про тестинг в моей интерпретации теперь тут
среда, 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. Ряд тестов, которые проверяют смежные функциональности (или ту же функциональность в более общем или конкретном виде) - тесты не запланированные и не задокументированные, они разрабатываются, прогоняются и оцениваются в тот конкретный момент, когда тестируются смежные функциональности, а это – ИТ.
Качество такого тестирования будет сильно зависеть от способностей тестировщика создавать тесты и находить дефекты. Однако, такой подход к тестированию обозначает непрерывное совершенствование - чем больше тестировщик знает о системе и методах тестирования, тем лучше будет тестирование.
понедельник, 31 мая 2010 г.
Цена документации
Тестирование – процесс, имеющий огромное количество сложных ограничений. У тестировщиков есть бесконечность потенциальных тестов и в то же время весьма ограниченное время для того, чтобы придумать, создать, задокументировать, и оценить результаты некоторых из этой бесконечности прогнанных тестов.
Время, потраченное на создание, согласование, доработку... документации – это время, которое отнимается у разработки тестов, инвестигейта тест тулов, выполнения и оценки тестирования...
В идеале конечно оценить соотношение стоимость/ польза для каждого случая. Если какой-либо тип документа является настолько ценным для текущего проекта, что целесообразнее написать документ, чем закончить задачу (по девелопменту, тестированию,...), то – создавайте (пишите) документ.
Если вы всё же решили, что документ стоит писать, то я бы посоветовал писать его не «залпом», накануне срока сдачи, выискивыя необходимые данные, тратя тем самым ещё больше времени, а постепенно и непрерывно. Таким образом, к моменту, когда документ должен быть готов, его останется только просмотреть и обновить какую-то минимальную информацию.
На последок хочу сказать, что тестировщик всегда должен чётко осознавать смысл своей работы. Это поможет правильно приотизировать события и не погрязнуть в бумажной работе.
Время, потраченное на создание, согласование, доработку... документации – это время, которое отнимается у разработки тестов, инвестигейта тест тулов, выполнения и оценки тестирования...
В идеале конечно оценить соотношение стоимость/ польза для каждого случая. Если какой-либо тип документа является настолько ценным для текущего проекта, что целесообразнее написать документ, чем закончить задачу (по девелопменту, тестированию,...), то – создавайте (пишите) документ.
Если вы всё же решили, что документ стоит писать, то я бы посоветовал писать его не «залпом», накануне срока сдачи, выискивыя необходимые данные, тратя тем самым ещё больше времени, а постепенно и непрерывно. Таким образом, к моменту, когда документ должен быть готов, его останется только просмотреть и обновить какую-то минимальную информацию.
На последок хочу сказать, что тестировщик всегда должен чётко осознавать смысл своей работы. Это поможет правильно приотизировать события и не погрязнуть в бумажной работе.
воскресенье, 30 мая 2010 г.
Нет! Тестированию ради тестирования.
Рано или поздно в процессе работы тестировщика случается момент, когда его просят провести тестирование, цель которого не совсем ясна или логична - так называемое "тестирование ради тестирования". Цель и задача конечно же сформулированы иначе, но смысл именно такой.
В этом случае, тестировщик просто обязан объяснить, что тестирование ради тестирования не добавляет бизнес-стоимости тестируемой системе, и что целесообразнее направить усилия команды тестирования по другому вектору.
Перечень таких векторов представлен, но не ограничен примерами ниже:
- минимизация рисков стэйкходеров
- получение информации о статусе готовности заявленной функциональности
- поддержка принятия решений(помощь менеджеру в решении выпускать продукт или нет)
- оценка и/или улучшение безопасности (качество)
- выявление характера проблем, связанных с использованием продукта в долгосрочной перспективе
- препятские выпуску "сырого" продукта
- улучшение юзабилити и пользовательских впечатлений
- проверка соответствия стандартам и/или спецификациям
- ...
Резюмируя, важно - чётко понимать цель тестирования, ну и делать всё необходимое, и даже немного больше, чтобы эту цель достигнуть.
В этом случае, тестировщик просто обязан объяснить, что тестирование ради тестирования не добавляет бизнес-стоимости тестируемой системе, и что целесообразнее направить усилия команды тестирования по другому вектору.
Перечень таких векторов представлен, но не ограничен примерами ниже:
- минимизация рисков стэйкходеров
- получение информации о статусе готовности заявленной функциональности
- поддержка принятия решений(помощь менеджеру в решении выпускать продукт или нет)
- оценка и/или улучшение безопасности (качество)
- выявление характера проблем, связанных с использованием продукта в долгосрочной перспективе
- препятские выпуску "сырого" продукта
- улучшение юзабилити и пользовательских впечатлений
- проверка соответствия стандартам и/или спецификациям
- ...
Резюмируя, важно - чётко понимать цель тестирования, ну и делать всё необходимое, и даже немного больше, чтобы эту цель достигнуть.
вторник, 25 мая 2010 г.
Форсаж для тестирования
Обсуждая тестирование с разными людьми, я часто слышу такие фразы «тестирование занимает слишком много времени», «тестеры работают медленно», «тестирование очень сильно растягивает итерацию», «тестирование – узкое место на проекте» и т.п.
Если так случилось, что такую фразу вы услышали в свой адресс – надо незамедлительно решить этот вопрос. Я предлагаю такое решение:
Измерить то, как члены команды тестирования используют своё рабочее время. Не для отчётности конечно, а для того, чтобы понять что и как надо изменить, чтобы эффективность команды возросла. Итоги зачастую будут подходить под закон Парето – т.е. 80% времени тратится на сорбрания (meetings), документацию, согласование действий, емэйлы и прочий «хлам», которым обросло тестирование в большинстве формализованных и не очень подходов; а оставшиеся 20% - тратятся непосредственно на тестирование.
Форсаж для этой ситуации будет заключаться в превращении соотношения 80/20 в соотношение 60/40 – например, можно попытаться убедить менеджмент в том, что часть действий из упомянутых выше 80% снижает эффективность команды тестирования и предложить отказаться от этих действий.
Также следует обратить внимание и на тот факт, что ещё около 20% (входящих в упомянутые 80%) времени уходит на воспроизведение дефектов (для уточнения шагов и добавления скриншотов или видео), написание отчётов о найденых дефектах, верификацию исправленых дефектов и т.п. Суть в том, что это не совсем проблем тестирования – это скорее проблема разработки.
Форсажем в данном случае будет служить – вовлечение тестировщиков в процесс разработки на более ранних стадиях, что обеспечит уменьшение количества дефектов в коде к окончанию разработки функциональности (feature complete) и ускорит проект в целом.
На последок хочу сказать, что конечно же не стоит дожидаться пока возникнет такой вопрос. Повышение эффективности использования рабочего времени – процесс непрерывный и сложный, но результат оправдывает вложенные усилия.
Если так случилось, что такую фразу вы услышали в свой адресс – надо незамедлительно решить этот вопрос. Я предлагаю такое решение:
Измерить то, как члены команды тестирования используют своё рабочее время. Не для отчётности конечно, а для того, чтобы понять что и как надо изменить, чтобы эффективность команды возросла. Итоги зачастую будут подходить под закон Парето – т.е. 80% времени тратится на сорбрания (meetings), документацию, согласование действий, емэйлы и прочий «хлам», которым обросло тестирование в большинстве формализованных и не очень подходов; а оставшиеся 20% - тратятся непосредственно на тестирование.
Форсаж для этой ситуации будет заключаться в превращении соотношения 80/20 в соотношение 60/40 – например, можно попытаться убедить менеджмент в том, что часть действий из упомянутых выше 80% снижает эффективность команды тестирования и предложить отказаться от этих действий.
Также следует обратить внимание и на тот факт, что ещё около 20% (входящих в упомянутые 80%) времени уходит на воспроизведение дефектов (для уточнения шагов и добавления скриншотов или видео), написание отчётов о найденых дефектах, верификацию исправленых дефектов и т.п. Суть в том, что это не совсем проблем тестирования – это скорее проблема разработки.
Форсажем в данном случае будет служить – вовлечение тестировщиков в процесс разработки на более ранних стадиях, что обеспечит уменьшение количества дефектов в коде к окончанию разработки функциональности (feature complete) и ускорит проект в целом.
На последок хочу сказать, что конечно же не стоит дожидаться пока возникнет такой вопрос. Повышение эффективности использования рабочего времени – процесс непрерывный и сложный, но результат оправдывает вложенные усилия.
Выдающийся тестировщик
Что делает выдающего тестировщика выдающимся? Я думаю, что практически каждый тестировщик задавался этим вопросом хотя бы раз.
Большинство профессиональных тестировщиков сразу начнут вещать про то, что выдающимся тестировщика делает знание методологий, тулов, процессов и т.п. Это всё конечно немаловажно, но, я считаю, что не это главное. Это делает тестировщика хорошим, но не выдающимся.
В конце концов те самые упомянутые методологии и процессы были разработаны обычными людьми, а людям, как известно, свойственно ошибаться – в этом мы все преуспели.
Так каким же всё таки должен быть выдающийся тестировщик? Я считаю, что для этого тестировщик должен быть бунтарём - любознательным, ставящим под вопрос всех и вся, не доверяющим общепризнанным подходам и методологиям, лично «испытывающим на прочность» практики, проверенные временем, пере-изобретающим тестирование, совмещающим подходы из других областей знаний, не перестающим учиться и совершенствоваться...
Большинство профессиональных тестировщиков сразу начнут вещать про то, что выдающимся тестировщика делает знание методологий, тулов, процессов и т.п. Это всё конечно немаловажно, но, я считаю, что не это главное. Это делает тестировщика хорошим, но не выдающимся.
В конце концов те самые упомянутые методологии и процессы были разработаны обычными людьми, а людям, как известно, свойственно ошибаться – в этом мы все преуспели.
Так каким же всё таки должен быть выдающийся тестировщик? Я считаю, что для этого тестировщик должен быть бунтарём - любознательным, ставящим под вопрос всех и вся, не доверяющим общепризнанным подходам и методологиям, лично «испытывающим на прочность» практики, проверенные временем, пере-изобретающим тестирование, совмещающим подходы из других областей знаний, не перестающим учиться и совершенствоваться...
среда, 19 мая 2010 г.
Выбор тулы для скриншотинга
Каждому тестеру ежедневно создаёт отчёты о найденых дефектах – баг репорты или проще – баги. В этом блоге, я уже поднимал вопрос о том, насколько важно писать грамотный баг репорт. Однако очень часто срабатывает правило «лучше один раз увидеть, чем сто раз услышать» - тут на помощь тестерам приходят тулы для «захвата» содержимого экрана (screen capture tools). О них сегодня и пойдёт речь.
Естественно, что данная ниша рынка представлена очень широко и многообразно – ведь делать скриншоты приходится не только тетстировщикам.
На мой взгляд, оптимальными тулами для тестеров являются: 1. SnagIt и 2. Win7 Snipping Tool
1. SnagIt
SnagIt – очень мощная тула, позволяющая не только сделать скриншот, но и налепить на него кучу плюшек (сделать обводку «особо опасному» месту, понатыкать стрелочек, добавить текст и т.д. и т.п). SnagIt имеет большое число настроек для захватываемой области (область, окно, видимая часть контента – экран, область со скроллом, скрин с сохранением ссылок и т.п.), что позволяет приаттачить к баг репорту максимально точный скриншот. Помимо «захвата» картинок, можно ещё и видео записывать, которое после архивации имеет символический «вес». Тула также имеет широкие возможности по экспорту (Word, Excel, PowerPoint, IM), а также отсылке (email, FTP)
Резюмируя, имеем довольно мощный и удобный инструмент для создания идеальных скриншотов баг репортам.
2. Snipping Tool
Snipping tool – встроенная в Windows7 тула, являющая собой отличный пример минимализма в решении поставленой задачи. Тут нет большого числа настроек и твиков, но есть всё необходимое, чтобы сделать качественный скриншот. Виды захватываемой области представлены 4 опциями – свободная область (free-form), четырёхугольник, окно и экран, что в принципе покрывает 99% случаев скрин шотов. Также радует поддержка сохранения ссылок. Из плюшек есть только ручка и хайлайтер, что немного удручает, поскольку в 50% случаев этого явно не хватит. Экспорт напрямую из тулы невозможен, однако отослать полученный скрин непосредственно из тулы можно, но только по email.
Подводя итог, Snipping Tool – отличная тула для создания простых скриншотов.
Итак, если вам в работе чаще требуется создавать «сложные» скриншотов, следует обратить внимание на SnagIt, а в случае когда надо просто подтвердить степы картинкой – вполне хватит и Snipping Tool.
Естественно, что данная ниша рынка представлена очень широко и многообразно – ведь делать скриншоты приходится не только тетстировщикам.
На мой взгляд, оптимальными тулами для тестеров являются: 1. SnagIt и 2. Win7 Snipping Tool
1. SnagIt
SnagIt – очень мощная тула, позволяющая не только сделать скриншот, но и налепить на него кучу плюшек (сделать обводку «особо опасному» месту, понатыкать стрелочек, добавить текст и т.д. и т.п). SnagIt имеет большое число настроек для захватываемой области (область, окно, видимая часть контента – экран, область со скроллом, скрин с сохранением ссылок и т.п.), что позволяет приаттачить к баг репорту максимально точный скриншот. Помимо «захвата» картинок, можно ещё и видео записывать, которое после архивации имеет символический «вес». Тула также имеет широкие возможности по экспорту (Word, Excel, PowerPoint, IM), а также отсылке (email, FTP)
Резюмируя, имеем довольно мощный и удобный инструмент для создания идеальных скриншотов баг репортам.
2. Snipping Tool
Snipping tool – встроенная в Windows7 тула, являющая собой отличный пример минимализма в решении поставленой задачи. Тут нет большого числа настроек и твиков, но есть всё необходимое, чтобы сделать качественный скриншот. Виды захватываемой области представлены 4 опциями – свободная область (free-form), четырёхугольник, окно и экран, что в принципе покрывает 99% случаев скрин шотов. Также радует поддержка сохранения ссылок. Из плюшек есть только ручка и хайлайтер, что немного удручает, поскольку в 50% случаев этого явно не хватит. Экспорт напрямую из тулы невозможен, однако отослать полученный скрин непосредственно из тулы можно, но только по email.
Подводя итог, Snipping Tool – отличная тула для создания простых скриншотов.
Итак, если вам в работе чаще требуется создавать «сложные» скриншотов, следует обратить внимание на SnagIt, а в случае когда надо просто подтвердить степы картинкой – вполне хватит и Snipping Tool.
понедельник, 17 мая 2010 г.
Сделай жизнь ярче - раскрась свой powershell
Многим из тех, кому приходится часто работоать с powershell, не нравятся "родные цвета" этой оболочки. Что ж, это не проблема, поскольку всё можно настроить исключительно под себя - для удобства использования и для эстетического наслаждения.
Для того, чтобы раскрасить свой powershell много не надо - достаточно прописать в профиле следующую функцию (цвета и значки - по вкусу):
# Prompt
function prompt
{
$_locationStackDepthString = New-Object string ([char] '+'), (Get-Location -Stack).Count
$color = 'Cyan'
Write-Host '>> ' -nonewline -ForegroundColor $color
Write-Host $(Get-Date -Format T) -ForegroundColor 'DarkYellow' -NoNewLine
Write-Host " " $PWD.Path -ForegroundColor 'Green'
Write-Host ($_locationStackDepthString + '>') -nonewline -ForegroundColor $color
$host.UI.RawUI.WindowTitle = "POWERSHELL"
return " "
}
Ну, а если уж захочется чего-то большего, то начать можно отсюда.
Для того, чтобы раскрасить свой powershell много не надо - достаточно прописать в профиле следующую функцию (цвета и значки - по вкусу):
# Prompt
function prompt
{
$_locationStackDepthString = New-Object string ([char] '+'), (Get-Location -Stack).Count
$color = 'Cyan'
Write-Host '>> ' -nonewline -ForegroundColor $color
Write-Host $(Get-Date -Format T) -ForegroundColor 'DarkYellow' -NoNewLine
Write-Host " " $PWD.Path -ForegroundColor 'Green'
Write-Host ($_locationStackDepthString + '>') -nonewline -ForegroundColor $color
$host.UI.RawUI.WindowTitle = "POWERSHELL"
return " "
}
Ну, а если уж захочется чего-то большего, то начать можно отсюда.
четверг, 13 мая 2010 г.
HTML5 Тест браузеров
Коллега подкинул интересный ресурс - HTML5 тест для браузера.
Исходя из тех конфигурация, которые имею под рукой - получил следующие результаты:
Win7
Chrome beta (5...) - 142
Chrome 4.1.2 - 118
Opera 10.53 - 102
Firefox 3.6.3 - 101
IE8 - 19
Safari 4 - 70
Mac OS X 10.6
Safari 4 - 113
Firefox 3.6.3 - 101
Chrome beta (5...) - 137
iPad - 115
iPhone (3я прошивка)
Safari 4 - 113
Opera mini 5.0 - 14
Samsung GALAXY (android 1.5)
Chrome Light - 39
Провести Тест
Исходя из тех конфигурация, которые имею под рукой - получил следующие результаты:
Win7
Chrome beta (5...) - 142
Chrome 4.1.2 - 118
Opera 10.53 - 102
Firefox 3.6.3 - 101
IE8 - 19
Safari 4 - 70
Mac OS X 10.6
Safari 4 - 113
Firefox 3.6.3 - 101
Chrome beta (5...) - 137
iPad - 115
iPhone (3я прошивка)
Safari 4 - 113
Opera mini 5.0 - 14
Samsung GALAXY (android 1.5)
Chrome Light - 39
Провести Тест
пятница, 7 мая 2010 г.
Автоматизация Flex приложений на QTP
Некоторое время назад я столкнулся с проблемой автоматизации flex части проекта с помощью QTP.
Даже с установленным Flex 3.0.0 Add-in'м объекты flex части не распознавались, соответственно автоматизация не представлялась возможной.
Однако, после недолгих поисков наша проектная команда qa нашла приемлемое решение.
Шаги такие:
1. Запускаем Flex Builder.
2. Создаём новый Flex проект.
3. Выбираем его в навигаторе.
4. Выбираем Project > Properties > Flex Compiler.
5. В поле "Additional compiler arguments" прописываем следующее:
-include-libraries "flex_builder_dir\sdks\3.0.0\frameworks\libs\automation.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\automation_agent.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\qtp.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\automation_dmv.swc"
( -include-libraries работает с директорией Flex Builder'a (в Windows по дефолту "C:\Program Files\Adobe\Flex Builder 3\")
6. Кликаем OK,чтобы сохранить изменения, а потом ещё раз на OK, чтобы закрыть Properties проекта.
7. Компилим Flex приложение.
Негативные моменты этого подхода в том, что:
1. Придётся всегда параллельно собирать по 2 версии приложения (для продакшена и для тестирования), такое сработает далеко не на любом проекте
2. "probe effect", хоть и минимальный, но всё же присутствует
P.S. Работает с 7м IE, Flex 3.0.0 Add-in обязателен.
Даже с установленным Flex 3.0.0 Add-in'м объекты flex части не распознавались, соответственно автоматизация не представлялась возможной.
Однако, после недолгих поисков наша проектная команда qa нашла приемлемое решение.
Шаги такие:
1. Запускаем Flex Builder.
2. Создаём новый Flex проект.
3. Выбираем его в навигаторе.
4. Выбираем Project > Properties > Flex Compiler.
5. В поле "Additional compiler arguments" прописываем следующее:
-include-libraries "flex_builder_dir\sdks\3.0.0\frameworks\libs\automation.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\automation_agent.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\qtp.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\automation_dmv.swc"
( -include-libraries работает с директорией Flex Builder'a (в Windows по дефолту "C:\Program Files\Adobe\Flex Builder 3\")
6. Кликаем OK,чтобы сохранить изменения, а потом ещё раз на OK, чтобы закрыть Properties проекта.
7. Компилим Flex приложение.
Негативные моменты этого подхода в том, что:
1. Придётся всегда параллельно собирать по 2 версии приложения (для продакшена и для тестирования), такое сработает далеко не на любом проекте
2. "probe effect", хоть и минимальный, но всё же присутствует
P.S. Работает с 7м IE, Flex 3.0.0 Add-in обязателен.
среда, 28 апреля 2010 г.
ISTQB Certification
На прошлой неделе сдал экзамен на сертификацию ISTQB (Foundation Level).
Уже давно хотел это сделать, да всё руки не доходили.
Поскольку для меня эта процедура осталась позади, а результат успешен, - дам несколько советов.
1. Язык
Читать материалы для подготовки к экзамену лучше на английском языке. Это нужно для того, чтобы не "платить" за 'lost in translation' ошибки. При этом среднего уровня владения английским вполне хватит.
2. Материалы
Чтобы покрыть все вопросы экзамена - достаточно 3х документов: книга (Foundations of Software Testing) - собственно для изучения теории, словарь терминов (Glossary) - для изучения терминологии и "методичка" (Syllabus) - для повторения.
Я при подготовке использовал вопросники и других источников - например, отсюда, но особой пользы они не принесли. Однако если вы располагаете достаточным количеством времени, то и этот ресурс лишним не будет.
3. Время
Для подготовки не нужны месяцы. Я считаю, что достаточно 2-х недель по 1-2 часа в день.
Или если пересчитать на покрытие материала - одно прочтение книги, знание обязательных терминов (в книге они указаны), прохождение всех тестов и пробного экзамена (тоже есть в книге), повторение материала по "методичке".
4. Где и Когда
Для того, чтобы сдать экзамен в Беларуси следует обратиться в местную ветку ISTQB, которую можно найти тут и зарегистрироваться на сайте. А потом просто следовать инструкциям, которые будут приходить на ваш email.
Я лично считаю сертификацию весьма полезной вещью:
- она помогает обновить и структурировать знания по тестированию ПО
- расширить кругозор и получить полезные контакты
- добавить "галочку" в резюме
- в конечном итоге, просто как пункт в планах самореализации
Уже давно хотел это сделать, да всё руки не доходили.
Поскольку для меня эта процедура осталась позади, а результат успешен, - дам несколько советов.
1. Язык
Читать материалы для подготовки к экзамену лучше на английском языке. Это нужно для того, чтобы не "платить" за 'lost in translation' ошибки. При этом среднего уровня владения английским вполне хватит.
2. Материалы
Чтобы покрыть все вопросы экзамена - достаточно 3х документов: книга (Foundations of Software Testing) - собственно для изучения теории, словарь терминов (Glossary) - для изучения терминологии и "методичка" (Syllabus) - для повторения.
Я при подготовке использовал вопросники и других источников - например, отсюда, но особой пользы они не принесли. Однако если вы располагаете достаточным количеством времени, то и этот ресурс лишним не будет.
3. Время
Для подготовки не нужны месяцы. Я считаю, что достаточно 2-х недель по 1-2 часа в день.
Или если пересчитать на покрытие материала - одно прочтение книги, знание обязательных терминов (в книге они указаны), прохождение всех тестов и пробного экзамена (тоже есть в книге), повторение материала по "методичке".
4. Где и Когда
Для того, чтобы сдать экзамен в Беларуси следует обратиться в местную ветку ISTQB, которую можно найти тут и зарегистрироваться на сайте. А потом просто следовать инструкциям, которые будут приходить на ваш email.
Я лично считаю сертификацию весьма полезной вещью:
- она помогает обновить и структурировать знания по тестированию ПО
- расширить кругозор и получить полезные контакты
- добавить "галочку" в резюме
- в конечном итоге, просто как пункт в планах самореализации
вторник, 20 апреля 2010 г.
понедельник, 19 апреля 2010 г.
пятница, 2 апреля 2010 г.
I've got the Power...Shell
При тестировании своих проектов, мне зачастую надо выполнять набор каких-либо определённых действий. Чаще всего, действия эти простые, но требуют затрат некоторого количества времени.
Мне это дело изрядно надоело, поэтому я твёрдо решил автоматизировать эти действия.
На помощь пришёл PowerShell, а также разработчики, которые оказали содействие. Суть автоматизации - написать функцию, прописать её в профиле PowerShell на локальной и удалённой машинах и выполнять её, когда необходимо выполнять вышеупомянутые рутинные действия.
А дело происходит так:
Открываем PowerShell и cоздаём профиль(ну, если ещё не создан конечно): new-item -type file -path $profile -force
Открываем профиль: notepad $profile
Пишем функцию:
function DoSomething([string]$Param1 = "") {
if ($Param1 -eq "") {
Write-Host "You are an IDIOT!!!! You need to enter Param1 value!" -ForegroundColor Red
return
}
$A_OUTPUT = "D:\Destination\"
$B_INPUT = "D:\Files\Images\"
$C_FILE = "Info.txt"
$currentDate = Get-Date -Format yyyyMMdd
$destinationFolder = $A_OUTPUT + $currentDate
if ((Test-Path -path $destinationFolder) -ne $True)
{
New-Item $destinationFolder -type directory | Out-Null
}
$Destination = "$destinationFolder\$Param1"
if ((Test-Path -path $Destination) -ne $True)
{
New-Item $Destination -type directory | Out-Null
}
$files = ls $B_INPUT
$files | %{copy -path $_.FullName -Destination $Destination}
Write-Host "$($files.Count) files" -ForegroundColor Yellow -noNewLine
Write-Host " copied from $B_INPUT to $Destination"
New-Item ($Destination + "\" + $C_FILE) -itemType File -Force | Out-Null
Write-Host "$C_FILE" -ForegroundColor Yellow -noNewLine
Write-Host " is created"
Write-Host "Files $Param1 are reorganizes!" -ForegroundColor Green
}
Сохраняем профиль. Тут есть вопрос безопасности - если вам операционка говорит "низя" - её надо вежливо попросить:
1. Запустить PowerShell под админом
2. Прописать следующее: Set-ExecutionPolicy unrestricted
3. Согласиться на все, что предложит :)
Перезапускаем PowerShell.
Запускаем функцию DoSomething TestB13. И функция благополучно копирует файлы из D:\Files\Images\ в D:\Destination\\TestB13 и создаёт текстовый файл Info.txt для последующего ввода описания.
Ответ PowerShell'a будет такой (с учётом, что в ресурсе лежит 3 файла):
3 files copied from D:\Files\Images to D:\Destination\\TestB13
Info.txt is created
Files TestB13 are reorganized!
В итоге, экономия рабочего времени составила более 50% (точно не замерял), которое я могу тратить на более важные аспекты тестирования.
P.S. Курс молодого бойца PowerShell можно пройти тут
Мне это дело изрядно надоело, поэтому я твёрдо решил автоматизировать эти действия.
На помощь пришёл PowerShell, а также разработчики, которые оказали содействие. Суть автоматизации - написать функцию, прописать её в профиле PowerShell на локальной и удалённой машинах и выполнять её, когда необходимо выполнять вышеупомянутые рутинные действия.
А дело происходит так:
Открываем PowerShell и cоздаём профиль(ну, если ещё не создан конечно): new-item -type file -path $profile -force
Открываем профиль: notepad $profile
Пишем функцию:
function DoSomething([string]$Param1 = "") {
if ($Param1 -eq "") {
Write-Host "You are an IDIOT!!!! You need to enter Param1 value!" -ForegroundColor Red
return
}
$A_OUTPUT = "D:\Destination\"
$B_INPUT = "D:\Files\Images\"
$C_FILE = "Info.txt"
$currentDate = Get-Date -Format yyyyMMdd
$destinationFolder = $A_OUTPUT + $currentDate
if ((Test-Path -path $destinationFolder) -ne $True)
{
New-Item $destinationFolder -type directory | Out-Null
}
$Destination = "$destinationFolder\$Param1"
if ((Test-Path -path $Destination) -ne $True)
{
New-Item $Destination -type directory | Out-Null
}
$files = ls $B_INPUT
$files | %{copy -path $_.FullName -Destination $Destination}
Write-Host "$($files.Count) files" -ForegroundColor Yellow -noNewLine
Write-Host " copied from $B_INPUT to $Destination"
New-Item ($Destination + "\" + $C_FILE) -itemType File -Force | Out-Null
Write-Host "$C_FILE" -ForegroundColor Yellow -noNewLine
Write-Host " is created"
Write-Host "Files $Param1 are reorganizes!" -ForegroundColor Green
}
Сохраняем профиль. Тут есть вопрос безопасности - если вам операционка говорит "низя" - её надо вежливо попросить:
1. Запустить PowerShell под админом
2. Прописать следующее: Set-ExecutionPolicy unrestricted
3. Согласиться на все, что предложит :)
Перезапускаем PowerShell.
Запускаем функцию DoSomething TestB13. И функция благополучно копирует файлы из D:\Files\Images\ в D:\Destination\
Ответ PowerShell'a будет такой (с учётом, что в ресурсе лежит 3 файла):
3 files copied from D:\Files\Images to D:\Destination\
Info.txt is created
Files TestB13 are reorganized!
В итоге, экономия рабочего времени составила более 50% (точно не замерял), которое я могу тратить на более важные аспекты тестирования.
P.S. Курс молодого бойца PowerShell можно пройти тут
среда, 17 марта 2010 г.
Контекстное тестирование
Некоторое время назад, прочитал о контекстном тестировании (context-driven-testing). Оказалось, что то, как я работаю, по большому счёту – контекстное тестирование.
Что же такое контекстное тестирование и с чем его едят.
Школа контекстного тестирования – одна из пяти школ тестирования программного обеспечения (наряду с аналитической и стандартной школой, а также школой обеспечения качества и школой «гибкого» тестирования ).
Контекстное тестирование – это подход к тестированию ПО, суть которого описана семью основными принципами:
1. Ценность любых практик зависит он контекста.
2. Панацеи в тестировании не существует, существую оптимальные для данного тестирования практики
3. Проектная команда – самая важная часть контекста
4. То, как развивается проект с течением времени – зачастую непредсказуемо
5. Программный продукт – это решение какой-либо задачи. Если задача не решена – продукт не работает
6. Качественное тестирование – интеллектуальный и непростой процесс
7. Только с помощью рассудительности и профессиональных умений, применяемых на протяжении всей длительности проекта, мы сможем делать правильные действия в правильное время, чтобы эффективно протестировать продукт
вторник, 9 марта 2010 г.
Mind map как апгрейд для чек-листа
Любому, даже малоопытному, тестировщику знаком такой артефакт тестирования как «чек-лист» (checklist). Сей артефакт представляет собой список того, что необходимо проверить в ходе тестирования той или иной функциональности. Обычно он используется для тестирования функциональности, не покрытой тестами и требующего проверки большого количества объектов.
Одни тестировщики, в принципе, считают, что чек-лист хорош как есть. В большинстве случаев это – текстовый файл, с иерархией или без, в котором списком идёт перечисление пунктов, проверка которых обязатльна в рамках данной функциональности.
Другие же спецы ищут пути оптимизации процессов тестирования. К такой оптимизации можно отнести использование майнд-мэпов (mind maps) как апгрейд для тестирования по чек-листам. Суть сводится к тому, что пункты чек-листа представляются не списком, а в виде диаграммы, построенной вокруг центральной идеи (функциональности) с отображением связей между объектами внутри этой идеи (отображение связей между частями функциональности) .
Использование майнд-мэпов делает процесс тестирования по чек-листам более наглядным : можно сфокусироваться на определённой части функциональности, свернув остальные ветки диаграммы; на диаграмме хорошо видно текущей статус тестирования функциональности (например, путём выделения цветом или любым другим способом, статуса по отдельным частям: pass, fail, not ran, blocked, etc).
В вопросе выбора ПО для построения майнд-мапов я бы посоветовал либо "платный" Mindjet Mind Manager либо бесплатный FreeMind
пятница, 19 февраля 2010 г.
«Плавающие» дефекты
На любом проекте время от времени появляются дефекты, которые воспроизводятся не на постоянной основе – их ещё часто называют трудновоспроизводимыми или «плавающими». Однако, несмотря на то, что вероятность появления таких дефектов после поставки значительно ниже 100%, ущерб наносимый ими даже единожды, может иметь серьёзнейшие последствия. Чтобы минимизировать количество «плавающих» дефектов можно использовать следующие методы:
1. Добавление/изменение подходов к воспроизведению (и тестированию в целом)
- фокусировка на интуитивно выявленных критических местах
- привлечение помощи сторонних (возможно с другого проекта) тестировщиков для более (exploratory) или менее (ad-hoc) глубокого тестирования
2. «Bug bash» мероприятия
- суть в задействований как можно большего числа "глаз" на приложении с целью выявления дефектов. Большой плюс в привлечении для тестирования не тестировщиков - поскольку это помогает получить разносторонний взгляд на тестируемую систему. В данном случае алгоритм может быть следующим: тестировщик высказывает свои соображения по поводу того, где может находится дефект, остальные (тестировщики, привлечённые с других проектов, а также все остальные члены комады) тестируют систему, параллельно обсуждая вслух возможные варианты воспроизведения (по принципу «что если...») - получается своего рода брэйнсторминг.
3. Парное тестирование (тестировщик + тестировщик или тестировщик + разработчик)
Суть в том, что два тестировщика (или тестировщиу с разработчиком) в паре работают над некой функциональностью за одной машиной. Парное тестирование имеет ряд плюсов:
- в разы снижается риск того, что часть функциональности будет пропущена или недостаточно тщательно протестирована
- общение, возникающее во время парного тестирования, способствует обоюдному расширению знаний о проекте и обмен опытом в целом
- помимо повышения качества тестирования, увеличивается и его скорость
понедельник, 8 февраля 2010 г.
Латаем дыры в тестовом покрытии
На большинстве проектов, на которых мне довелось работать использовались тест кейсы. Однако не смотря на прогон полного набора тестов, багам всё-таки удётся проскакивать в лайф. Источников этих «утечек» довольно много, однако по большому счёту их можно отнести к одной из следующих групп:
Причина: Ошибки могут быть всевозможными - непосредственно в шагах, в настройках "железа", в настройках софта... и причины этих ошибок также могут быть весьма разнообразными.
Что делать: Писать конкретные, достаточно(на усмотрение) детализированные и недвусмысленные шаги и ожидаемые результаты, чтобы с тест кейсоми смог работать тестирвщик со средним знанием тестируемой системы. В написании по-настоящему хорошего теста огромную помощь может оказать разработчик той функциональности, тест к которой вы пишете. Ревизия теста разработчиком добавит в кейс шаги направленные на "узкие" места.
2. Неактуальный тест кейс
Причина: Тест кейс писался на ранних этапах разработки, когда ещё не совсем ясны детали; фунциональность проапдейтили, а тест нет; тестировщик недопонял фичу и написал тест с соответствии с ошибочной точкой зрения;...
Что делать: Регулярно проводить ревизию тест кейсов, причём опять же желательно, совместно в разработчиком, отвечающим за конкретную функциональность.
3. Отсутствует тест кейс
Причина: Если на написание тестов и выделяют время, то его, как правило, недостаточно для детального покрытия фич тестами. Поэтому не стоит удивлсяться случаю, когда на проскочивший баг не найдётся тест кейса, который мог бы его выявить.
Что делать: Разобраться детально в проблеме и создать тест кейс, покрывающий найденный баг плюс небольшую смежную область - так называемый work-around.
4. Ошибка в спеке
Причина: В моём понятии - спека - это, конечно, большая роскошь. Однкако, уж коль она есть, то и ошибки в ней, наверняка, присутствуют. Поэтому, если писать тест кейсы просто по спеке, то есть большой риск, что в них ещё до первого прогона будут содержаться ошибки.
Что делать: Читая спеку тестировщик должен всё ставить под сомнение - это поможет выявить ряд дефектов системы на раннем этапе и не допустить написания ошибочных тест кейсов.
5. Некорректный баг репорт
Причина: Такой баг был занесён в баг-трэккер, но "прошёл мимо" разработчиков - виной тому неверное выставление приоритета, версии, компонента, платформы и т.д. и т.п.
Что делать: Придерживаться установленных в компании/на проекте правил написания отчётов о дефектах. А если возникает ситуация в которой тестировщик сомневается к какому компоненту отнести тот или иной дефект, то не зазорно обратится к разработчикам или тех лиду.
понедельник, 1 февраля 2010 г.
Пишем отчёты о дефектах
В большинсве проектов используют те или иные багтрэкинговые сисемы. Это может быть кастомный (например, на базе SharePoint), бесплатный (например, Bugzilla) или платный (например, JIRA) продукт. Однако вне зависимости от выбора такой системы, шаблон, по которому пишутся отчёты о найденных дефектах будет очень похож. Конечно же очень важно выставлять багу правильный приоритет, версию ПО, ответственного разработчика и т.п., но я бы хотел обратить внимание на три поля, информация в которых повлияет на понимание дефекта, его восприятие и потребует от тестировщика некоторых усилий и определённых знаний тестируемой системы.
1. Summary
Резюме бага, оно же саммари (summary) - это лицо бага, это та самая "одёжка", по которой встречают. Очень многое зависит от того, насколько удачно сформулировано саммари. В идеале, прочтя саммари, разработчик должен на 80% понять суть проблемы.
Советую учесть следующие моменты при написании саммари для дефекта:
а) указание платформы (например, test или prod), если на проекте используется несколько платформ
б) указание компонента (например, аdmin, reports, upload и т.п.), если последующее описание может подойти нескольким компонентам
в) указание браузера (например, IE7), если ошибочное поведение наблюдается специфически под определённым браузером
г) указание частоты воспроизведение (например, occasionally или 4 of 10 times), если воспроизводится не на постоянной основе
д) использование терминологии, использующейся в тестируемой системе (например, не photos, а images или не scroll bar, а slider)
2. Description
Описание шагов (description) - по сути самое важное во всём отчёте, поскольку от того, как тестировщик сумеет объяснить суть бага и шаги к его воспроизведению, зависит его (бага) дальнейшая судьба. Слишком кратко - высока вероятность того, что баг вернётся к тестировщику для уточнения. Слишком детально - разработчик скорее всего отложит такой баг на потом, поскольку его даже читать лень, не говоря уже о качественном фиксе. Осюда вывод, что для того, чтобы избежать временных потерь, надо искать оптимальный размер описания.
Лично я, при написании баг репорта, советую выбрать довольно высокую степень детализации шагов, однако, по возможности, группировать несколько простых действий в один шаг.
Помните, что хорошо описанная проблема - проблема наполовину решённая.
3. Attachment
Правилом хорошего тона в данном случае будет добавление к описанию бага визуального подтверждения. Более распространённым видом такой визуализации является снимок экрана, он же скриншот (screenshot), однако с нынешним выбором ПО нет никакой проблемы прикрепить и заархивированное видео. Многие разработчики оценят такого рода апгрейд - ведь, как говорится, "лучше один раз увидеть, чем сто раз услышать два раза прочитать"
Задача тестировщика состоит не только в том, чтобы найти баг, но и в том, чтобы найденный баг был исправлен.
Помните, что если ваш баг вернулся к вам со статусом не Resolved, то скорее всего в этом виноваты вы.
P.S. Если вы не уверены в том, насколько хорошо вы справляетесь с перечисленными тремя пунктами - не стесняйтесь и спросите у тех, кому приходится непосредственно с этой информацией работать - вашу команду разработчиков
1. Summary
Резюме бага, оно же саммари (summary) - это лицо бага, это та самая "одёжка", по которой встречают. Очень многое зависит от того, насколько удачно сформулировано саммари. В идеале, прочтя саммари, разработчик должен на 80% понять суть проблемы.
Советую учесть следующие моменты при написании саммари для дефекта:
а) указание платформы (например, test или prod), если на проекте используется несколько платформ
б) указание компонента (например, аdmin, reports, upload и т.п.), если последующее описание может подойти нескольким компонентам
в) указание браузера (например, IE7), если ошибочное поведение наблюдается специфически под определённым браузером
г) указание частоты воспроизведение (например, occasionally или 4 of 10 times), если воспроизводится не на постоянной основе
д) использование терминологии, использующейся в тестируемой системе (например, не photos, а images или не scroll bar, а slider)
2. Description
Описание шагов (description) - по сути самое важное во всём отчёте, поскольку от того, как тестировщик сумеет объяснить суть бага и шаги к его воспроизведению, зависит его (бага) дальнейшая судьба. Слишком кратко - высока вероятность того, что баг вернётся к тестировщику для уточнения. Слишком детально - разработчик скорее всего отложит такой баг на потом, поскольку его даже читать лень, не говоря уже о качественном фиксе. Осюда вывод, что для того, чтобы избежать временных потерь, надо искать оптимальный размер описания.
Лично я, при написании баг репорта, советую выбрать довольно высокую степень детализации шагов, однако, по возможности, группировать несколько простых действий в один шаг.
Помните, что хорошо описанная проблема - проблема наполовину решённая.
3. Attachment
Правилом хорошего тона в данном случае будет добавление к описанию бага визуального подтверждения. Более распространённым видом такой визуализации является снимок экрана, он же скриншот (screenshot), однако с нынешним выбором ПО нет никакой проблемы прикрепить и заархивированное видео. Многие разработчики оценят такого рода апгрейд - ведь, как говорится, "лучше один раз увидеть, чем сто раз услышать два раза прочитать"
Задача тестировщика состоит не только в том, чтобы найти баг, но и в том, чтобы найденный баг был исправлен.
Помните, что если ваш баг вернулся к вам со статусом не Resolved, то скорее всего в этом виноваты вы.
P.S. Если вы не уверены в том, насколько хорошо вы справляетесь с перечисленными тремя пунктами - не стесняйтесь и спросите у тех, кому приходится непосредственно с этой информацией работать - вашу команду разработчиков
пятница, 29 января 2010 г.
Огранизация команды тестирования
Успешность работы команды тестирования (QA team) во многом зависит от её лидера (QA lead). Неоспоримо, что большую роль играет профессиональный и личностный уровень членов команды, однако не стоит недооценивать и то, насколько успешной её может сделать хороший QA Lead (в дальнейшем - лидер).
Я попробовал сформулировать несколько принципов, которые должен использовать лидер в своей работе.
1. Team spirit
Лидер - часть команды. И подчинённые должны это видеть. В противном случае они просто потеряют желание работать в такой команде и приносить пользу проекту.
Многие лидеры забывают, что ступив на чуть более высокую ступень и получив приставку Lead к должности, они по прежнему остаются QA.
2. QA Lead – tester…
Лидер и сам должен тестировать. Это не значит, что он обязан тратить всё своё время на тестирование. Однако следует уделять задачам тестирования хотя бы некоторую часть (в зависимости от размера команды) времени.
3. Writing Test Cases
Лидеру не стоит оставлять написание тестов исключительно подчинённым. В противном случае члены команды могут посчитать написание тестов менее важной задачей, что приведёт к ухудшению тестового покрытия в качестенном и количественном выражении. В добавок к этому, регулярное написание тестов позволит чётко представлять состояние базы тестов на проекте.
4. Learn Together
Лидер должен избегать тенденции к исследованию новой функциональности первым. Члены команды должны видеть, что их лидер изучает функциональности и учится вместе с ними наровне.
5. Everybody makes mistakes
Лидер должен обличать свои ошибки. Ошибки делают все. Это потребует некоторой смелости, поскольку никто не любит выглядеть неподобающим образом и не каждый осмелится на такое.
6. No Monopoly on Ideas
Лидер просто обязан избегать "монополизации" идей. Он должен иногда давать право членам команды брать инициативу на себя. Также в отдельных случаях необходимо поощрять принятие решений (конечно если компетенции членов команды позволяют принимать решения).
7. Trusted team
Лидер должен создать команду, на которую он сможет полностью положиться. Да, лидер должен быть осторожен, но не настолько, чтобы не вовлекать своих подчинённых в решение сложных задач. Лидер должен таким образом организовать взаимодействие с подчинёнными, что они почувстуют свою значимость - факт, что они делают свой вклад в проект.
8. Input Appreciation
Лидер должен поощрять не только выдающиеся результаты, но и просто хорошую работу. Даже простого упоминания на собрании хватит, чтобы члены команды почувствовали себя значимыми. Лидер должен ставить членам команды цели и вознаграждать за их достижение.
9. Proactivity is Welcomed
Лидер должен приветсвовать проактивность. Проактивность должна вести к расширенным полномочиям.
10. No Knowledge Ownership
Лидер должен избегать "приватизирования знаний". Каждый член команды должен знать большую часть функциональности системы (насколько это позволяет размер проекта - в идеале 100%). Также каждый член команды должен хорошо ориентироваться во всей базе тестов - принцип тот же.
Я попробовал сформулировать несколько принципов, которые должен использовать лидер в своей работе.
1. Team spirit
Лидер - часть команды. И подчинённые должны это видеть. В противном случае они просто потеряют желание работать в такой команде и приносить пользу проекту.
Многие лидеры забывают, что ступив на чуть более высокую ступень и получив приставку Lead к должности, они по прежнему остаются QA.
2. QA Lead – tester…
Лидер и сам должен тестировать. Это не значит, что он обязан тратить всё своё время на тестирование. Однако следует уделять задачам тестирования хотя бы некоторую часть (в зависимости от размера команды) времени.
3. Writing Test Cases
Лидеру не стоит оставлять написание тестов исключительно подчинённым. В противном случае члены команды могут посчитать написание тестов менее важной задачей, что приведёт к ухудшению тестового покрытия в качестенном и количественном выражении. В добавок к этому, регулярное написание тестов позволит чётко представлять состояние базы тестов на проекте.
4. Learn Together
Лидер должен избегать тенденции к исследованию новой функциональности первым. Члены команды должны видеть, что их лидер изучает функциональности и учится вместе с ними наровне.
5. Everybody makes mistakes
Лидер должен обличать свои ошибки. Ошибки делают все. Это потребует некоторой смелости, поскольку никто не любит выглядеть неподобающим образом и не каждый осмелится на такое.
6. No Monopoly on Ideas
Лидер просто обязан избегать "монополизации" идей. Он должен иногда давать право членам команды брать инициативу на себя. Также в отдельных случаях необходимо поощрять принятие решений (конечно если компетенции членов команды позволяют принимать решения).
7. Trusted team
Лидер должен создать команду, на которую он сможет полностью положиться. Да, лидер должен быть осторожен, но не настолько, чтобы не вовлекать своих подчинённых в решение сложных задач. Лидер должен таким образом организовать взаимодействие с подчинёнными, что они почувстуют свою значимость - факт, что они делают свой вклад в проект.
8. Input Appreciation
Лидер должен поощрять не только выдающиеся результаты, но и просто хорошую работу. Даже простого упоминания на собрании хватит, чтобы члены команды почувствовали себя значимыми. Лидер должен ставить членам команды цели и вознаграждать за их достижение.
9. Proactivity is Welcomed
Лидер должен приветсвовать проактивность. Проактивность должна вести к расширенным полномочиям.
10. No Knowledge Ownership
Лидер должен избегать "приватизирования знаний". Каждый член команды должен знать большую часть функциональности системы (насколько это позволяет размер проекта - в идеале 100%). Также каждый член команды должен хорошо ориентироваться во всей базе тестов - принцип тот же.
Подписаться на:
Сообщения (Atom)
