Правильно ли исправлять ошибки без добавления новых функций при выпуске программного обеспечения для тестирования системы?

Этот вопрос к опытным тестировщикам или тестовым проводникам. Это сценарий из программного проекта:

Скажем, команда разработчиков завершила первую итерацию из 10 функций и выпустила ее для тестирования системы. Команда тестирования создала тестовые наборы для этих 10 функций и приблизительно 5 дней для тестирования. Команда разработчиков, конечно, не может бездействовать в течение 5 дней, и она начинает создавать 10 новых функций для следующей итерации. За это время команда тестирования обнаружила дефекты и выявила некоторые ошибки. Ошибки имеют приоритет, и некоторые из них должны быть исправлены до следующей итерации. Суть в том, что они не примут новую версию с какими-либо новыми функциями или изменениями существующих функций, пока все эти ошибки не будут исправлены. Команда тестирования говорит, что именно так мы можем гарантировать стабильную версию для тестирования, если мы также представим новые функции наряду с исправлением ошибки. Они также не могут выполнять регрессионные тесты всех своих тестов на каждой итерации.

Это означает, что команда разработчиков должна создать ветку кода исключительно для исправления ошибок и другую ветку, где они продолжают разработку. Это дополнительные затраты на слияние, особенно с рефакторингом и архитектурными изменениями.

Можете ли вы согласиться, если это общий принцип тестирования. Действительна ли проблема испытательной группы? Сталкивались ли вы с этим на практике в своем проекте.

Вместо этого я бы сказал, что каждый выпуск новых функций должен находиться в отдельной ветке. Это позволяет отделить разработку и релизы.

Как ваш релиз для конечных пользователей работает в этом процессе? Ваша группа по тестированию системы должна меньше заботиться о графике разработки и вместо этого сосредоточиться на графике выпуска клиента.

Нет смысла пытаться официально тестировать новые функции, пока продолжается разработка, потому что велика вероятность, что ваши следующие 10 функций будут касаться той же функциональности и потребуют от них повторного тестирования этих областей.

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

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

Мы используем гибридный подход. Для выпуска клиента у нас определенно есть собственная ветка, предназначенная исключительно для исправления критических ошибок.

Продолжается регулярная разработка нескольких версий программного обеспечения. Например, предположим, что последняя стабильная версия - 2.0. Все рискованные функции будут добавлены в ветку 3.0. Только исправления ошибок идут в ветки 2.0. Тестирование специальной командой QA проводится только на стабильных ветках. Релизы для клиентов, конечно, сделаны из другой ветки, основанной на 2.0. Долгосрочные функции, такие как разработка платформы следующего поколения, будут реализованы в 4.0, а не в 3.0.

Все это хорошо выглядит на бумаге. Но если клиенту нужна определенная функция, ее необходимо добавить в саму ветку 2.0, поскольку версия 3.0 недостаточно стабильна для выпуска клиентам. Это означает, что команда QA должна будет повторно запустить весь набор регрессии.

Одна вещь, которую мы делаем - это покрытие кода каждого регрессионного теста. Выполняются только те регрессионные тесты, на которые повлияют изменения кода функции. Конечно, для выпуска клиента запускается полный набор регрессий.

Это действительно зависит от того, насколько тесно новые функции связаны с частями, требующими исправления ошибок. Например, если вы добавите новую функцию перетаскивания в одну небольшую часть пользовательского интерфейса, это «не должно» влиять на ошибку, связанную с разбором файла, загруженного пользователем.

Сказав это, вполне понятно (не обязательно оправдано), что тестировщики хотят проверить исправления «При прочих равных» (при прочих равных условиях).

Могут быть и другие проблемы со способом выпуска и ожиданиями конечных пользователей. Например, вам может понадобиться выпустить только после одной итерации исправления ошибок + тестирования и еще одной новой функции + тестирования, потому что пользователи ТОЛЬКО хотят переустановить или обновить, когда появятся новые функции. Некоторые могут потребовать исправления как приоритетные задачи как можно скорее.

Вы можете решить эту (общую) проблему, объединив объединение обеих команд.

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

Я предлагаю вам прочитать эту прекрасную запись в блоге Хенрик Книберг , что объясняет Кабан . Вы найдете много идей в процессе Scrum (бесплатная книга также Хенрика Книберга ).

Он также написал отличную статью Kanban VS Scrum в своем блоге.

Наслаждаться.

У команды тестирования определенно есть веская проблема, но я бы поставил под сомнение необходимость нескольких итераций тестирования для каждого выпуска. Зачем проходить полный цикл тестирования на версию кода, которую пользователи никогда не увидят?

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

Если это просто для того, чтобы помочь в их «процессах» на нормальных этапах разработки и гарантировать, что список ошибок не выходит из-под контроля, то, не решая его, спросите руководителя тестирования, можно ли немного ослабить это ограничение, пока мы приближаемся к точке выпуска.

Подумайте об изменении вашей системы контроля версий на распределенный продукт. Это значительно облегчит доставку такого релиза.

«Можете ли вы согласиться, если это общий принцип тестирования.

Yes

Действительна ли проблема испытательной команды?

Yes

Сталкивались ли вы с этим на практике в своем проекте ».

Yes

:

and Yes Merging is the downside of it 

Вы не спрашивали, кто это, но это ответственность Configuration Manager. Эта потоковая стратегия должна быть в его CMP. В противном случае уволить его / ее. Я думаю, что ответ от Пьера 303 также очень хороший, но, конечно, по возможности, технически (например, думая о выпуске Siebel ...) и организационно.

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

Здесь нет правильного ответа, но несколько вещей, которые вы должны рассмотреть:

• Могут ли эти выпуски ошибок (без новой функциональности) когда-либо передаваться пользователям? Если так, то да, это должно быть разветвлено и проверено, и каждый должен принять это как накладные расходы.

• Можно ли разделить новую функциональность таким образом, чтобы она существовала в совершенно отдельных областях приложения для предыдущих частей, над которыми работали? Если это так, это дает вам возможность - тестеры могут проводить повторные тесты ошибок и части приложения. Это не идеально, но это компромисс, который может сработать и дать им то, что они хотят.

• Сколько на самом деле стоит разветвить их релиз? Обычно это боль, но фактический объем работы обычно не так велик. Очевидно, вам нужно, чтобы они подтвердили, что для них это не просто больше работы (смотрите первое, что я скажу), но я видел, как места делают эту работу.

• Есть ли лучший способ использовать контроль версий здесь? Что-то вроде Mercurial (см. Http://hginit.com/ - прочитайте это, это хорошо) или другая распределенная система контроля версий разветвляется и сливается по-другому и может позволить вам обойти проблему. Действительно, взгляните на это, потому что я думаю, что это может быть ответом на вашу проблему.

Но удачи, это боль. Прежде всего помните, что наилучший путь продвижения вперед будет зависеть от вашей компании, продукта и ситуации, поэтому убедитесь, что вы думаете об этом, а не просто вытаскиваете что-то с полки и считаете, что вы должны придерживаться этого на 100%.

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

Если вы строите новые функции поверх известных ошибок, вы создаете карточный домик. Скорее всего, вы разрабатываете хрупкое, непредсказуемое программное обеспечение. В зависимости от уровня изоляции между ошибочным кодом и вашими новыми функциями, ошибки могут повлиять и на ваши новые функции. Если да, как вы узнаете, правильно ли работают ваши новые функции?

Если вы сначала исправите ошибки, у вас будет более прочная основа для любых новых функций, которые вы добавите.

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

Всегда старайтесь исправлять ошибки, прежде чем добавлять новые функции!

Там, где я работаю, мы работаем с этим сценарием, в котором каждый запланированный выпуск для производства имеет свою собственную ветку. Например, предположим, что на секунду будет релиз в конце июня, а еще один - в конце июля. Июньская версия получит свою собственную ветку, и все функции будут добавлены туда и отправлены в QA. На этом этапе мы начинаем работать над выпуском в июле и переходом из филиала в июне. Когда QA находит ошибки, мы исправляем их в июньской ветке, и как только исправления переносятся в QA, они объединяются в июльскую ветку выпуска. Это добавляет немного накладных расходов для обработки этих слияний, но обычно слияния довольно безболезненны. Время от времени это большая боль в том, что вы знаете что, но это происходит только тогда, когда производятся оптовые изменения, и это не должно происходить во время цикла QA (но они случаются, больше, чем я хотел бы признать). Но благодаря хорошему набору тестов (модуль и интеграция), покрытию кода и всем остальным модным словам TDD риски немного снижаются. Чтобы помочь, у нас обычно есть один человек, который обрабатывает слияния для каждого проекта.