Lesson 292
В минувшие выходные боец @Raspberries жгла. Результат примерно такой:
Альбом: Ingress
Подробности и фоточки.
И еще история про кота от Александра Селяева.
Слово Канеру
Создайте стратегию тестирования как ответ на особенности и риски проекта
Хорошая стратегия тестирования формируется не только рисками, но и особенностями проекта. Вот несколько принципов формирования стратегий. Основанных на деталях проекта:
- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция - протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом - протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок - прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.
Альбом: Ingress
Подробности и фоточки.
И еще история про кота от Александра Селяева.
Слово Канеру
Создайте стратегию тестирования как ответ на особенности и риски проекта
Хорошая стратегия тестирования формируется не только рисками, но и особенностями проекта. Вот несколько принципов формирования стратегий. Основанных на деталях проекта:
- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция - протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом - протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок - прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.