ekiyasheva и снова спасибо за ваш комментарий! =)
Постараюсь прояснить некоторые моменты процессов.
Мы аутсорс, и клиентоориентированность — основной аспект в нашей идеологии. Мы стараемся делать то, что нас просят, а не то, чего бы нам самим хотелось в связи со своими личными представлениями о прекрасном. Поэтому прежде, чем приступить к работе над новым скоупом работ на проекте — вне зависимости от того, первый это релиз или нет — тестировщик заполняет «опросник». В этом документе содержится информация о том, кто наш заказчик, какие у него бизнес-цели и бизнес-требования, какие приоритеты, кто наши пользователи и почему по мнению заказчика пользователь выберет именно этот продукт, а не аналоги на рынке. Так же в этом документе тестировщик кратко фиксирует информацию о сроках, планах, целях и роли тестирования на данном проекте, ссылки на перечисленные в начале статьи документы и прочие входные данные, необходимые для начала работ. Чаще всего тестировщик не общается с заказчиком напрямую, поэтому получить ответы на все перечисленные в опроснике вопросы — это целый квест. Тестировщик общается с аналитиком, менеджером проекта, продажником — со всеми, у кого есть доступ непосредственно к заказчику и понимание, что мы вообще должны в итоге получить. Иногда выявлением целей и сбором всей стартовой информации занимаюсь я как руководитель.
Этот документ выкладывается в общий доступ для всей команды разработки, чтобы у всех была единая картина. Без ответов на все эти вопросы мы, конечно, можем как-то работать, но риск сделать не то, чего от нас хотят, повышается. Поэтому если нам не хватает информации, мы задаем вопросы до тех пор, пока не получим удовлетворительный ответ.
Конечно, цели и приоритеты — вещь нестабильная, несмотря на все старания часто посреди итерации оказывается, что у заказчика изменились представления о продукте, кардинально поменялся основной юз-кейс или вообще критерии качества. Но в силу того, что тестировщик успел пристать со своими вопросами ко всем участникам процесса, команде становится понятно, что для нас важно, и доносят до нас информацию обо всех изменениях практически сразу. А мы редактируем свой документ, а вместе с этим — пересматриваем стратегию тестирования.
Касательно того, как понять, что аналитика проведена хорошо.
Во-первых, работает принцип «одна голова хорошо, а две лучше». Все работы в нашей компании обязательно проходят ревью, а в случае аналитики задействована вся команда. Например, упомянутые вами особенности архитектуры анализируются тем, кто выполняет на проекте роль архитектора, а мы лишь пытаемся задавать каверзные вопросы вместе с остальной командой. Перед каждой итерацией проводятся митинги, на которых обсуждается функциональность, риски, планы. В отделе тестирования мы так же устраиваем еженедельные митинги, на которых обсуждаем все проекты. Там мы тоже задаем друг другу каверзные вопросы, и если тестировщик не может ответить на какой-то вопрос — после митинга начинаем вместе разбираться.
Конечно, нельзя считать это метрикой, но когда вся команда разработки и весь отдел тестирования сделали ревью твоей работы и не нашли пробелов, вероятность, что работа сделана хорошо, повышается.
Во-вторых, если в чем-то мы все-таки накосячили — проводится ретроспектива, и в будущем этот опыт учитывается в работе и на тех же самых ревью. С учетом контекста, безусловно.
Что же касается рисков — согласна, вы правы, риски бывают не только регрессионные, и они так же нуждаются в анализе. В статье я не стала акцентировать на этом внимание, поскольку этот анализ не лежит целиком и полностью на плечах тестирования. Все перечисленные вами примеры — это риски, которые чаще всего обнаруживаются либо еще до написания какой-либо проектной документации аналитиком и архитектором, либо на этапе тестирования требований. Если нет, то здесь вступают упомянутые выше митинги — как вы и сказали, истина рождается в споре (диалоге).
В целом конечно, оценить, как именно нужно тестировать фичу, узкие места и рискованные области в новой функциональности, безусловно, необходимо — это является основной задачей любого тестировщика.
Большое спасибо за Ваш комментарий! Приятно знать, что такой подход используется кем-то еще.
Могли бы Вы подробнее рассказать о ситуациях, в которых таблицы оказались быстрее и удобнее — и почему?
Заранее спасибо.
Спасибо за Ваш комментарий! Постараюсь ответить на Ваши вопросы:
Мы используем плагины для Jira — Structure и Zephyr. Structure позволяет формировать вложенные списки, а Zephyr используем только в контексте отдельного вида тикетов с возможностью добавления в тикет таблицы с кейсами. Соответственно, есть возможность приоретизации и выставления тегов тестам. Structure умеет фильтровать кейсы по любым параметрам какие нужно и при этом не терять структуру дерева.
Повторюсь, Zephyr для нас — это только отдельный вид тикетов, остальные его возможности мы не используем. Тест сьюты формируем фильтрами или «на глаз» — во время прогона принимаем решение, стоит ли идти по данной ветке, и вообще каким будет обход дерева. Это сделано специально — при таком тестировании всегда есть элемент исследования, человек не должен отключать голову, бездумно гоняя описанные шаги, и эффект пестицида снижается.
Необходимости в жесткой отчетности по прогонам у нас нет — по итогам тестирования тестировщик пишет отчет для менеджера в свободной форме о том, что было сделано и какой результат. Это обосновано культурой управления в самой компании — такая информация будет для менеджмента полезнее, чем набор пройденных и не пройденных тестов в нашем тестовом наборе. Для своего удобства тестировщик при желании может менять статусы тикетов и ликовать баги к тестам, но никто, кроме него самого, смотреть на это не будет.
Касательно черного и серого ящиков — в описанном Вами смысле мы тестируем черным ящиком. Я упоминала это в предыдущей статье https://habrahabr.ru/company/touchinstinct/blog/329000/ — для оценки рисков используем отдельный документ, если есть необходимость их задокументировать.
Безусловно, мне стоит подумать, как вписать это в текущую структуру тестовой документации, спасибо.
Элемент серого ящика в нашем тестировании присутствует в том смысле, что мы всегда отслеживаем взаимодействие клиент-сервера через сниффер, и в тестах это взаимодействие мы так же прописываем — где какой запрос должен отправляться, какой ответ должен прийти, какие ошибки может вернуть сервер и как приложение должно на это отреагировать.
Разработка продуктов итеративная, по 1-2 недели спринт в зависимости от того, как часто заказчик хочет видеть промежуточный билд. В начале итерации, пока пишется код, мы пишем тесты. Тесты регулярно уточняются и рефакторятся, каждая правка тестов проходит ревью у лида или второго тестировщика на проекте. Чаще всего промежуточные билды в итерацию тестируются исследовательским методом, написанная документация служит лишь картой, и тестовая документация не обязана иметь финальный готовый вид. Когда реализована вся функциональность, перед релизом проводится финальный багфикс и регрессионное тестирование. Соответственно, к регрессионному тестированию вся документация должна быть полностью готова. Оценка на финальную итерацию и подход к регрессии каждый раз переопределяется и зависит от состояния проекта, приоритетов заказчика, дедлайна и многих других факторов.
Вроде все) Надеюсь, я смогла ответить на все, что Вас интересовало.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Усредненная предварительная оценка на написание тестовой документации 0.25 от времени разработки.
Постараюсь прояснить некоторые моменты процессов.
Мы аутсорс, и клиентоориентированность — основной аспект в нашей идеологии. Мы стараемся делать то, что нас просят, а не то, чего бы нам самим хотелось в связи со своими личными представлениями о прекрасном. Поэтому прежде, чем приступить к работе над новым скоупом работ на проекте — вне зависимости от того, первый это релиз или нет — тестировщик заполняет «опросник». В этом документе содержится информация о том, кто наш заказчик, какие у него бизнес-цели и бизнес-требования, какие приоритеты, кто наши пользователи и почему по мнению заказчика пользователь выберет именно этот продукт, а не аналоги на рынке. Так же в этом документе тестировщик кратко фиксирует информацию о сроках, планах, целях и роли тестирования на данном проекте, ссылки на перечисленные в начале статьи документы и прочие входные данные, необходимые для начала работ. Чаще всего тестировщик не общается с заказчиком напрямую, поэтому получить ответы на все перечисленные в опроснике вопросы — это целый квест. Тестировщик общается с аналитиком, менеджером проекта, продажником — со всеми, у кого есть доступ непосредственно к заказчику и понимание, что мы вообще должны в итоге получить. Иногда выявлением целей и сбором всей стартовой информации занимаюсь я как руководитель.
Этот документ выкладывается в общий доступ для всей команды разработки, чтобы у всех была единая картина. Без ответов на все эти вопросы мы, конечно, можем как-то работать, но риск сделать не то, чего от нас хотят, повышается. Поэтому если нам не хватает информации, мы задаем вопросы до тех пор, пока не получим удовлетворительный ответ.
Конечно, цели и приоритеты — вещь нестабильная, несмотря на все старания часто посреди итерации оказывается, что у заказчика изменились представления о продукте, кардинально поменялся основной юз-кейс или вообще критерии качества. Но в силу того, что тестировщик успел пристать со своими вопросами ко всем участникам процесса, команде становится понятно, что для нас важно, и доносят до нас информацию обо всех изменениях практически сразу. А мы редактируем свой документ, а вместе с этим — пересматриваем стратегию тестирования.
Касательно того, как понять, что аналитика проведена хорошо.
Во-первых, работает принцип «одна голова хорошо, а две лучше». Все работы в нашей компании обязательно проходят ревью, а в случае аналитики задействована вся команда. Например, упомянутые вами особенности архитектуры анализируются тем, кто выполняет на проекте роль архитектора, а мы лишь пытаемся задавать каверзные вопросы вместе с остальной командой. Перед каждой итерацией проводятся митинги, на которых обсуждается функциональность, риски, планы. В отделе тестирования мы так же устраиваем еженедельные митинги, на которых обсуждаем все проекты. Там мы тоже задаем друг другу каверзные вопросы, и если тестировщик не может ответить на какой-то вопрос — после митинга начинаем вместе разбираться.
Конечно, нельзя считать это метрикой, но когда вся команда разработки и весь отдел тестирования сделали ревью твоей работы и не нашли пробелов, вероятность, что работа сделана хорошо, повышается.
Во-вторых, если в чем-то мы все-таки накосячили — проводится ретроспектива, и в будущем этот опыт учитывается в работе и на тех же самых ревью. С учетом контекста, безусловно.
Что же касается рисков — согласна, вы правы, риски бывают не только регрессионные, и они так же нуждаются в анализе. В статье я не стала акцентировать на этом внимание, поскольку этот анализ не лежит целиком и полностью на плечах тестирования. Все перечисленные вами примеры — это риски, которые чаще всего обнаруживаются либо еще до написания какой-либо проектной документации аналитиком и архитектором, либо на этапе тестирования требований. Если нет, то здесь вступают упомянутые выше митинги — как вы и сказали, истина рождается в споре (диалоге).
В целом конечно, оценить, как именно нужно тестировать фичу, узкие места и рискованные области в новой функциональности, безусловно, необходимо — это является основной задачей любого тестировщика.
Могли бы Вы подробнее рассказать о ситуациях, в которых таблицы оказались быстрее и удобнее — и почему?
Заранее спасибо.
Мы используем плагины для Jira — Structure и Zephyr. Structure позволяет формировать вложенные списки, а Zephyr используем только в контексте отдельного вида тикетов с возможностью добавления в тикет таблицы с кейсами. Соответственно, есть возможность приоретизации и выставления тегов тестам. Structure умеет фильтровать кейсы по любым параметрам какие нужно и при этом не терять структуру дерева.
Повторюсь, Zephyr для нас — это только отдельный вид тикетов, остальные его возможности мы не используем. Тест сьюты формируем фильтрами или «на глаз» — во время прогона принимаем решение, стоит ли идти по данной ветке, и вообще каким будет обход дерева. Это сделано специально — при таком тестировании всегда есть элемент исследования, человек не должен отключать голову, бездумно гоняя описанные шаги, и эффект пестицида снижается.
Необходимости в жесткой отчетности по прогонам у нас нет — по итогам тестирования тестировщик пишет отчет для менеджера в свободной форме о том, что было сделано и какой результат. Это обосновано культурой управления в самой компании — такая информация будет для менеджмента полезнее, чем набор пройденных и не пройденных тестов в нашем тестовом наборе. Для своего удобства тестировщик при желании может менять статусы тикетов и ликовать баги к тестам, но никто, кроме него самого, смотреть на это не будет.
Касательно черного и серого ящиков — в описанном Вами смысле мы тестируем черным ящиком. Я упоминала это в предыдущей статье https://habrahabr.ru/company/touchinstinct/blog/329000/ — для оценки рисков используем отдельный документ, если есть необходимость их задокументировать.
Безусловно, мне стоит подумать, как вписать это в текущую структуру тестовой документации, спасибо.
Элемент серого ящика в нашем тестировании присутствует в том смысле, что мы всегда отслеживаем взаимодействие клиент-сервера через сниффер, и в тестах это взаимодействие мы так же прописываем — где какой запрос должен отправляться, какой ответ должен прийти, какие ошибки может вернуть сервер и как приложение должно на это отреагировать.
Разработка продуктов итеративная, по 1-2 недели спринт в зависимости от того, как часто заказчик хочет видеть промежуточный билд. В начале итерации, пока пишется код, мы пишем тесты. Тесты регулярно уточняются и рефакторятся, каждая правка тестов проходит ревью у лида или второго тестировщика на проекте. Чаще всего промежуточные билды в итерацию тестируются исследовательским методом, написанная документация служит лишь картой, и тестовая документация не обязана иметь финальный готовый вид. Когда реализована вся функциональность, перед релизом проводится финальный багфикс и регрессионное тестирование. Соответственно, к регрессионному тестированию вся документация должна быть полностью готова. Оценка на финальную итерацию и подход к регрессии каждый раз переопределяется и зависит от состояния проекта, приоритетов заказчика, дедлайна и многих других факторов.
Вроде все) Надеюсь, я смогла ответить на все, что Вас интересовало.