Lesson 103
Напевает
Микросхемы терпят все,
Можешь делать все, что хочешь.
Что-то я много чего не понимаю. Нужна аргументация, а ее нет или мало.
Сейчас говорю не только о селениумных, но и о unit тестах, о статических анализаторах.
Правильно ли фигачить новую функциональность, невзирая на сработавшие вышеперечисленные?
С одной стороны - культура разработки, теория разбитых окон и так далее.
Вывод - сработавшие тесты чинить первыми.
С другой стороны - а если бизнесу надо новые фичи прямо сейчас? Бизнес-цели они жеж важнее, так?
Вывод - хрен с ними, со сработавшими тестами, починим потом.
Дальше. Потом не наступит никогда. А я уже теперь знаю, что сломанные тесты равны куче багов в будущем. Значит для экономии времени самих же программистов - чинить надо.
Вывод - стопаем фичи, чиним тесты.
Затем. А давайте какие-то там тесты не будут управлять процессом разработки и приоритетами задач программистов. Давайте приоритетами задач программистов будет управлять менеджер проекта, который за все отвечает. Это правильно. Ему сейчас нужно фичи.
Он делает вывод - чиним потом, сейчас гоним фичи.
Вот дальше я шаги не делал
Но если попробовать:
- Сломанные тесты это не некритичные дефекты приложения, это критичные дефекты процесса. Надо чинить.
- Негоже из за пары тестов стопорить весь процесс разработки. Можно фигачить.
Ну и еще можно совсем пофантазировать.
- А вот в гугле есть ПМ, а есть начальник разработчика. И у них ПМ разработчику не начальник, а вполне себе заказчик. Можно и так относиться. Тогда - совсем другой коленкор, не так ли.
Короче.
Реквестирую ваши мнения. Даже опрос вставлю.
Poll Чинить тесты или фигачить фичи?
Помогите понять.
Слово Канеру:
Расширяй охват вместо повторения одних и тех же тестов.
Используй автоматизацию для расширения охвата и восприятия, чтоб видеть больше и больше.
Ты просто не сможешь запустить некоторые тесты без использования автоматизации. Другие тесты ты сможешь запустить в более серьезном масштабе. Вот несколько примеров:
Тестирование нагрузки Что случится, если 200 человек попробуйт использовать твой софт одновременно? А если 2000? Тебе необходима автоматизация для эмуляции такого кейса.
Измерение производительности Производительность системы улучшается или нет? Вы могли бы добавить в автоматизированные тесты измерение времени их прохождения. Собирая и анализируя эти данные вы могли бы обнаружить деградацию производительности системы. Используйте тот же подход для сравнения использования системой других ресурсов, таких как память и дисковое пространство.
Конфигурационное тестирование ПО часто должно работать на разных платформах, в различных конфигурациях, используя различные периферийные устройства. Как можно покрыть все это? Автоматизация поможет увеличить покрытие. Чтоб сделать это, вам нужно запустить тесты на различных платформах.
Тестирование выносливости Что случится, если подукт будет использоваться в течение недель или месяцев? Утечки памяти, повреждения стека, дикие указатели и другие подобные ошибки могут быть не очевидными в момент появления, но в конечном счете привести к беде. Одна из стратегий заключается в запуске серии тестов в течение длительного периода времени без перезапуска программы. Это требует автоматизации.
Race condition Некоторые проблемы возникают только в особых временных условиях. Совпадение по времени работы двух потоков, претендующих на один ресурс в результате может привести к ошибке, именуемой кace condition. Такие ошибки сложно найти и воспроизвести. Автоматизация может помочь, так как вы можете запустить большое количество тестов в произвольные моменты времени, различными временными характеристиками работы.
Комбинированные ошибки Некоторые ошибки связаны с взаимодействием нескольких функций. Используй автоматизацию для прогона большого количества сложных тестов, каждый из которых использует несколько функций по-своему.
Этот подход сосредоточен на использовании автоматизации для создания новых тестов или использовании продукта таким образом, чтоб выявить новые виды баг. Ни один из этих тестов не прост в реализации. Возможно, вам придется много работать над автоматизацией различных этапов тестирования и разработкой новых инструментов. Тем не менее, мы считаем, что эти цели автоматизации лучше тех, что предусматривают простой прогон одних и тех же тестов.
Микросхемы терпят все,
Можешь делать все, что хочешь.
Что-то я много чего не понимаю. Нужна аргументация, а ее нет или мало.
Сейчас говорю не только о селениумных, но и о unit тестах, о статических анализаторах.
Правильно ли фигачить новую функциональность, невзирая на сработавшие вышеперечисленные?
С одной стороны - культура разработки, теория разбитых окон и так далее.
Вывод - сработавшие тесты чинить первыми.
С другой стороны - а если бизнесу надо новые фичи прямо сейчас? Бизнес-цели они жеж важнее, так?
Вывод - хрен с ними, со сработавшими тестами, починим потом.
Дальше. Потом не наступит никогда. А я уже теперь знаю, что сломанные тесты равны куче багов в будущем. Значит для экономии времени самих же программистов - чинить надо.
Вывод - стопаем фичи, чиним тесты.
Затем. А давайте какие-то там тесты не будут управлять процессом разработки и приоритетами задач программистов. Давайте приоритетами задач программистов будет управлять менеджер проекта, который за все отвечает. Это правильно. Ему сейчас нужно фичи.
Он делает вывод - чиним потом, сейчас гоним фичи.
Вот дальше я шаги не делал
Но если попробовать:
- Сломанные тесты это не некритичные дефекты приложения, это критичные дефекты процесса. Надо чинить.
- Негоже из за пары тестов стопорить весь процесс разработки. Можно фигачить.
Ну и еще можно совсем пофантазировать.
- А вот в гугле есть ПМ, а есть начальник разработчика. И у них ПМ разработчику не начальник, а вполне себе заказчик. Можно и так относиться. Тогда - совсем другой коленкор, не так ли.
Короче.
Реквестирую ваши мнения. Даже опрос вставлю.
Poll Чинить тесты или фигачить фичи?
Помогите понять.
Слово Канеру:
Расширяй охват вместо повторения одних и тех же тестов.
Используй автоматизацию для расширения охвата и восприятия, чтоб видеть больше и больше.
Ты просто не сможешь запустить некоторые тесты без использования автоматизации. Другие тесты ты сможешь запустить в более серьезном масштабе. Вот несколько примеров:
Тестирование нагрузки Что случится, если 200 человек попробуйт использовать твой софт одновременно? А если 2000? Тебе необходима автоматизация для эмуляции такого кейса.
Измерение производительности Производительность системы улучшается или нет? Вы могли бы добавить в автоматизированные тесты измерение времени их прохождения. Собирая и анализируя эти данные вы могли бы обнаружить деградацию производительности системы. Используйте тот же подход для сравнения использования системой других ресурсов, таких как память и дисковое пространство.
Конфигурационное тестирование ПО часто должно работать на разных платформах, в различных конфигурациях, используя различные периферийные устройства. Как можно покрыть все это? Автоматизация поможет увеличить покрытие. Чтоб сделать это, вам нужно запустить тесты на различных платформах.
Тестирование выносливости Что случится, если подукт будет использоваться в течение недель или месяцев? Утечки памяти, повреждения стека, дикие указатели и другие подобные ошибки могут быть не очевидными в момент появления, но в конечном счете привести к беде. Одна из стратегий заключается в запуске серии тестов в течение длительного периода времени без перезапуска программы. Это требует автоматизации.
Race condition Некоторые проблемы возникают только в особых временных условиях. Совпадение по времени работы двух потоков, претендующих на один ресурс в результате может привести к ошибке, именуемой кace condition. Такие ошибки сложно найти и воспроизвести. Автоматизация может помочь, так как вы можете запустить большое количество тестов в произвольные моменты времени, различными временными характеристиками работы.
Комбинированные ошибки Некоторые ошибки связаны с взаимодействием нескольких функций. Используй автоматизацию для прогона большого количества сложных тестов, каждый из которых использует несколько функций по-своему.
Этот подход сосредоточен на использовании автоматизации для создания новых тестов или использовании продукта таким образом, чтоб выявить новые виды баг. Ни один из этих тестов не прост в реализации. Возможно, вам придется много работать над автоматизацией различных этапов тестирования и разработкой новых инструментов. Тем не менее, мы считаем, что эти цели автоматизации лучше тех, что предусматривают простой прогон одних и тех же тестов.