вторник, 17 апреля 2012 г.

Lesson 103

Напевает
Микросхемы терпят все,
Можешь делать все, что хочешь.


Что-то я много чего не понимаю. Нужна аргументация, а ее нет или мало.
Сейчас говорю не только о селениумных, но и о unit тестах, о статических анализаторах.

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

С одной стороны - культура разработки, теория разбитых окон и так далее.
Вывод - сработавшие тесты чинить первыми.

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

Дальше. Потом не наступит никогда. А я уже теперь знаю, что сломанные тесты равны куче багов в будущем. Значит для экономии времени самих же программистов - чинить надо.
Вывод - стопаем фичи, чиним тесты.

Затем. А давайте какие-то там тесты не будут управлять процессом разработки и приоритетами задач программистов. Давайте приоритетами задач программистов будет управлять менеджер проекта, который за все отвечает. Это правильно. Ему сейчас нужно фичи.
Он делает вывод - чиним потом, сейчас гоним фичи.

Вот дальше я шаги не делал
Но если попробовать:
- Сломанные тесты это не некритичные дефекты приложения, это критичные дефекты процесса. Надо чинить.
- Негоже из за пары тестов стопорить весь процесс разработки. Можно фигачить.

Ну и еще можно совсем пофантазировать.
- А вот в гугле есть ПМ, а есть начальник разработчика. И у них ПМ разработчику не начальник, а вполне себе заказчик. Можно и так относиться. Тогда - совсем другой коленкор, не так ли.

Короче.
Реквестирую ваши мнения. Даже опрос вставлю.



Помогите понять.



Слово Канеру:

Расширяй охват вместо повторения одних и тех же тестов.

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

Ты просто не сможешь запустить некоторые тесты без использования автоматизации. Другие тесты ты сможешь запустить в более серьезном масштабе. Вот несколько примеров:

Тестирование нагрузки Что случится, если 200 человек попробуйт использовать твой софт одновременно? А если 2000? Тебе необходима автоматизация для эмуляции такого кейса.

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

Конфигурационное тестирование ПО часто должно работать на разных платформах, в различных конфигурациях, используя различные периферийные устройства. Как можно покрыть все это? Автоматизация поможет увеличить покрытие. Чтоб сделать это, вам нужно запустить тесты на различных платформах.

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

Race condition Некоторые проблемы возникают только в особых временных условиях. Совпадение по времени работы двух потоков, претендующих на один ресурс в результате может привести к ошибке, именуемой кace condition. Такие ошибки сложно найти и воспроизвести. Автоматизация может помочь, так как вы можете запустить большое количество тестов в произвольные моменты времени, различными временными характеристиками работы.
Комбинированные ошибки Некоторые ошибки связаны с взаимодействием нескольких функций. Используй автоматизацию для прогона большого количества сложных тестов, каждый из которых использует несколько функций по-своему.

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

7 комментариев:

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


    Советы Канера на этот раз уж слишком сферические в вакууме, ИМХО

    ОтветитьУдалить
  2. Советы Канера: не сказал бы, напротив, согласованы с теорией познания.

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

    Мне нравится.
    Минусы: если тесты не чинить сразу - сложно искать сломавших, реакция позднее, починка медленней.

    ОтветитьУдалить
  3. Еще минус - лесом идет оперативность тестов.
    А это уже серьезно, надо подумать.

    ОтветитьУдалить
  4. В общем, тут два варианта:
    чиним сразу или не чиним сразу.

    Если это юнит-тесты — однозначно править. Сразу. Иначе дальше (с большой долей вероятности) начнется адъ.

    Если это, например, гуёвые селениумные тесты, и ничего критически важного в системе не сломалось, то заводим баг, требуем закрыть до конца итерации.


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

    ОтветитьУдалить
  5. Окей, мне нравится эта версия.
    Что делаем в случае, если юнит чинится не сразу? Если гуй-тесты не починили до конца итерации?

    ОтветитьУдалить
  6. Топать ногами, ругаться и пытать менеджера «Берешь на себя ответственность на непофикшенные баги?!»
    Других вариантов у меня нет :(

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

    ОтветитьУдалить