Комментарии 4
Почитаешь такое, потом подумаешь о своем проекте и хочется закрыть лицо рукой. Как-то не верю я, что где-то все идеально и гладко а у тебя все страшно и гадко. Проблемы в ай-ти проектах в общих чертах везде одинаковые. Вот начальник отдела аквиза нам такие удивительные вещи про нас расказывает, по его словам мы просто чудесны свежи и прелестны. А процессы у заказчика лучше не становятся. Заказчик доволен нашей работой, но это по сравнению с другими подрядчиками, мы действительно косячим меньше. Но мы так далеки от эталонных процессов в разработке как это только можно себе представить. Процессы есть, они соблюдаются, но большую часть времени ты или ждешь когда другие сделают свою работу, например напишут требования, или что-то сломано по чужой вине и проверка твоего функционала невозможна (у нас над системой работает более дюжины разных подрядчиков) или в тулчейне проблемы и т.п. Как я люблю в шутку говорить «мы не пишем ПО, мы решаем проблемы».
С нетерпением жду продолжения сказки про сказку :)
С нетерпением жду продолжения сказки про сказку :)
лично мне очень импонирует Ваш подход :) Однако охота подискутировать, так рождается истина
У меня не получилось рассмотреть за текстом процессов — не ясны контрольные точки и коммуникации на каждом этапе. А это значит, непонятно
— какие условия нужно было выстроить, чтобы все перечисленное работало, как положено. К примеру, не при всяких условиях можно узнать, что хочет заказчик и не в любой момент выяснить из каких компонентов состоит продукт.
— как именно вы понимаете, сделаны ли эти работы хорошо. Как сами тестировщики это понимают?
Или перечисленное скорее best practices отдела?
В деталях:
— Про требования. Мне кажется тут не хватает проверки на согласованность требований… с целями заказчика. Если проект живет дольше одного релиза, с архитектурой проекта, уже существующими в нем другими функциональностями, данными.
— Про риски. Есть такое убеждение, что риски могут быть не только регрессионными.
Для примера, вы разрабатываете новую функциональность, ммм… статус-кнопку, которая горит красным на ответ false от внешнего сервера и зеленым в случае true. Кнопка должна работать в режиме реального времени. Какие риски? Приложение может заспамить, а в худшем случае положить внешний сервер. Надо анализировать. Допустим риск оправдан. Очевидное решение — нужно кэшировать показатель кнопки, или реализовать очереди. Но тогда кнопка перестает работать в режиме реального времени — тоже риск, да такой, что надо обсуждать с заказчиком.
Другой пример, вы разрабатываете какую-то внутреннюю механику, положим выгрузчик. На каждом этапе, он может не обработать данные, не выгрузить их, не суметь сохранить в БД. В чем риск? Все это нельзя будет достоверно проверить, если не будет соответствующих ручек и логов. Это уже дополнительная активность, чтобы в тестирование передали тестопригодный продукт. Ничто из перечисленного не является регрессией, но вроде является работой с рисками.
У меня не получилось рассмотреть за текстом процессов — не ясны контрольные точки и коммуникации на каждом этапе. А это значит, непонятно
— какие условия нужно было выстроить, чтобы все перечисленное работало, как положено. К примеру, не при всяких условиях можно узнать, что хочет заказчик и не в любой момент выяснить из каких компонентов состоит продукт.
— как именно вы понимаете, сделаны ли эти работы хорошо. Как сами тестировщики это понимают?
Или перечисленное скорее best practices отдела?
В деталях:
— Про требования. Мне кажется тут не хватает проверки на согласованность требований… с целями заказчика. Если проект живет дольше одного релиза, с архитектурой проекта, уже существующими в нем другими функциональностями, данными.
— Про риски. Есть такое убеждение, что риски могут быть не только регрессионными.
Для примера, вы разрабатываете новую функциональность, ммм… статус-кнопку, которая горит красным на ответ false от внешнего сервера и зеленым в случае true. Кнопка должна работать в режиме реального времени. Какие риски? Приложение может заспамить, а в худшем случае положить внешний сервер. Надо анализировать. Допустим риск оправдан. Очевидное решение — нужно кэшировать показатель кнопки, или реализовать очереди. Но тогда кнопка перестает работать в режиме реального времени — тоже риск, да такой, что надо обсуждать с заказчиком.
Другой пример, вы разрабатываете какую-то внутреннюю механику, положим выгрузчик. На каждом этапе, он может не обработать данные, не выгрузить их, не суметь сохранить в БД. В чем риск? Все это нельзя будет достоверно проверить, если не будет соответствующих ручек и логов. Это уже дополнительная активность, чтобы в тестирование передали тестопригодный продукт. Ничто из перечисленного не является регрессией, но вроде является работой с рисками.
ekiyasheva и снова спасибо за ваш комментарий! =)
Постараюсь прояснить некоторые моменты процессов.
Мы аутсорс, и клиентоориентированность — основной аспект в нашей идеологии. Мы стараемся делать то, что нас просят, а не то, чего бы нам самим хотелось в связи со своими личными представлениями о прекрасном. Поэтому прежде, чем приступить к работе над новым скоупом работ на проекте — вне зависимости от того, первый это релиз или нет — тестировщик заполняет «опросник». В этом документе содержится информация о том, кто наш заказчик, какие у него бизнес-цели и бизнес-требования, какие приоритеты, кто наши пользователи и почему по мнению заказчика пользователь выберет именно этот продукт, а не аналоги на рынке. Так же в этом документе тестировщик кратко фиксирует информацию о сроках, планах, целях и роли тестирования на данном проекте, ссылки на перечисленные в начале статьи документы и прочие входные данные, необходимые для начала работ. Чаще всего тестировщик не общается с заказчиком напрямую, поэтому получить ответы на все перечисленные в опроснике вопросы — это целый квест. Тестировщик общается с аналитиком, менеджером проекта, продажником — со всеми, у кого есть доступ непосредственно к заказчику и понимание, что мы вообще должны в итоге получить. Иногда выявлением целей и сбором всей стартовой информации занимаюсь я как руководитель.
Этот документ выкладывается в общий доступ для всей команды разработки, чтобы у всех была единая картина. Без ответов на все эти вопросы мы, конечно, можем как-то работать, но риск сделать не то, чего от нас хотят, повышается. Поэтому если нам не хватает информации, мы задаем вопросы до тех пор, пока не получим удовлетворительный ответ.
Конечно, цели и приоритеты — вещь нестабильная, несмотря на все старания часто посреди итерации оказывается, что у заказчика изменились представления о продукте, кардинально поменялся основной юз-кейс или вообще критерии качества. Но в силу того, что тестировщик успел пристать со своими вопросами ко всем участникам процесса, команде становится понятно, что для нас важно, и доносят до нас информацию обо всех изменениях практически сразу. А мы редактируем свой документ, а вместе с этим — пересматриваем стратегию тестирования.
Касательно того, как понять, что аналитика проведена хорошо.
Во-первых, работает принцип «одна голова хорошо, а две лучше». Все работы в нашей компании обязательно проходят ревью, а в случае аналитики задействована вся команда. Например, упомянутые вами особенности архитектуры анализируются тем, кто выполняет на проекте роль архитектора, а мы лишь пытаемся задавать каверзные вопросы вместе с остальной командой. Перед каждой итерацией проводятся митинги, на которых обсуждается функциональность, риски, планы. В отделе тестирования мы так же устраиваем еженедельные митинги, на которых обсуждаем все проекты. Там мы тоже задаем друг другу каверзные вопросы, и если тестировщик не может ответить на какой-то вопрос — после митинга начинаем вместе разбираться.
Конечно, нельзя считать это метрикой, но когда вся команда разработки и весь отдел тестирования сделали ревью твоей работы и не нашли пробелов, вероятность, что работа сделана хорошо, повышается.
Во-вторых, если в чем-то мы все-таки накосячили — проводится ретроспектива, и в будущем этот опыт учитывается в работе и на тех же самых ревью. С учетом контекста, безусловно.
Что же касается рисков — согласна, вы правы, риски бывают не только регрессионные, и они так же нуждаются в анализе. В статье я не стала акцентировать на этом внимание, поскольку этот анализ не лежит целиком и полностью на плечах тестирования. Все перечисленные вами примеры — это риски, которые чаще всего обнаруживаются либо еще до написания какой-либо проектной документации аналитиком и архитектором, либо на этапе тестирования требований. Если нет, то здесь вступают упомянутые выше митинги — как вы и сказали, истина рождается в споре (диалоге).
В целом конечно, оценить, как именно нужно тестировать фичу, узкие места и рискованные области в новой функциональности, безусловно, необходимо — это является основной задачей любого тестировщика.
Постараюсь прояснить некоторые моменты процессов.
Мы аутсорс, и клиентоориентированность — основной аспект в нашей идеологии. Мы стараемся делать то, что нас просят, а не то, чего бы нам самим хотелось в связи со своими личными представлениями о прекрасном. Поэтому прежде, чем приступить к работе над новым скоупом работ на проекте — вне зависимости от того, первый это релиз или нет — тестировщик заполняет «опросник». В этом документе содержится информация о том, кто наш заказчик, какие у него бизнес-цели и бизнес-требования, какие приоритеты, кто наши пользователи и почему по мнению заказчика пользователь выберет именно этот продукт, а не аналоги на рынке. Так же в этом документе тестировщик кратко фиксирует информацию о сроках, планах, целях и роли тестирования на данном проекте, ссылки на перечисленные в начале статьи документы и прочие входные данные, необходимые для начала работ. Чаще всего тестировщик не общается с заказчиком напрямую, поэтому получить ответы на все перечисленные в опроснике вопросы — это целый квест. Тестировщик общается с аналитиком, менеджером проекта, продажником — со всеми, у кого есть доступ непосредственно к заказчику и понимание, что мы вообще должны в итоге получить. Иногда выявлением целей и сбором всей стартовой информации занимаюсь я как руководитель.
Этот документ выкладывается в общий доступ для всей команды разработки, чтобы у всех была единая картина. Без ответов на все эти вопросы мы, конечно, можем как-то работать, но риск сделать не то, чего от нас хотят, повышается. Поэтому если нам не хватает информации, мы задаем вопросы до тех пор, пока не получим удовлетворительный ответ.
Конечно, цели и приоритеты — вещь нестабильная, несмотря на все старания часто посреди итерации оказывается, что у заказчика изменились представления о продукте, кардинально поменялся основной юз-кейс или вообще критерии качества. Но в силу того, что тестировщик успел пристать со своими вопросами ко всем участникам процесса, команде становится понятно, что для нас важно, и доносят до нас информацию обо всех изменениях практически сразу. А мы редактируем свой документ, а вместе с этим — пересматриваем стратегию тестирования.
Касательно того, как понять, что аналитика проведена хорошо.
Во-первых, работает принцип «одна голова хорошо, а две лучше». Все работы в нашей компании обязательно проходят ревью, а в случае аналитики задействована вся команда. Например, упомянутые вами особенности архитектуры анализируются тем, кто выполняет на проекте роль архитектора, а мы лишь пытаемся задавать каверзные вопросы вместе с остальной командой. Перед каждой итерацией проводятся митинги, на которых обсуждается функциональность, риски, планы. В отделе тестирования мы так же устраиваем еженедельные митинги, на которых обсуждаем все проекты. Там мы тоже задаем друг другу каверзные вопросы, и если тестировщик не может ответить на какой-то вопрос — после митинга начинаем вместе разбираться.
Конечно, нельзя считать это метрикой, но когда вся команда разработки и весь отдел тестирования сделали ревью твоей работы и не нашли пробелов, вероятность, что работа сделана хорошо, повышается.
Во-вторых, если в чем-то мы все-таки накосячили — проводится ретроспектива, и в будущем этот опыт учитывается в работе и на тех же самых ревью. С учетом контекста, безусловно.
Что же касается рисков — согласна, вы правы, риски бывают не только регрессионные, и они так же нуждаются в анализе. В статье я не стала акцентировать на этом внимание, поскольку этот анализ не лежит целиком и полностью на плечах тестирования. Все перечисленные вами примеры — это риски, которые чаще всего обнаруживаются либо еще до написания какой-либо проектной документации аналитиком и архитектором, либо на этапе тестирования требований. Если нет, то здесь вступают упомянутые выше митинги — как вы и сказали, истина рождается в споре (диалоге).
В целом конечно, оценить, как именно нужно тестировать фичу, узкие места и рискованные области в новой функциональности, безусловно, необходимо — это является основной задачей любого тестировщика.
Есть над чем поразмыслить. Спасибо :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тест-анализ в мобильной разработке