С легаси кодом не просто.
Это такой специальный код, который был написан в доисторические времена (кажется, в прошлую пятницу). В нём много всего занятного, но мало понятного с первого взгляда. Он что-то делает, но как ему это удаётся - поди разберись. В нём немало странностей, а то и багов, но эти странности благополучно пережили уже несколько версий продукта.
Это такой код, который, с одной стороны, хочется радикально улучшить, а с другой - лучше к нему не прикасаться.
Так вот знаешь, что? Уважай его.
Он не просто так появился в системе, и он честно работает уже несколько лет. Продукт работал всё это время благодаря ему - и приносил деньги. Он, может, странно выглядит, но в свое время это было лучшее из доступных решений (или просто достаточно неплохое). Он дожил до сегодняшнего дня, значит он вполне работоспособен и решает свою задачу: он не так уж плох. Он спокойно работал и давал возможность развивать другие стороны продукта.
Серьёзно, без него у тебя не было бы этой работы.
Он окончательно устарел и пришло-таки время всё исправить? ОК, не вопрос, давай исправлять. Но смотри внимательно: шрамы на старом коде - это следы древних багов. Будешь небрежен - и те же баги повторятся уже в новом коде.
Это легаси. Уважай его.
пятница, 13 ноября 2015 г.
четверг, 29 октября 2015 г.
Сказка о неразобранных автотестах
Жил был проект, а в проекте делали продукт, а у продукта была веб-морда, и нужно было ту веб-морду тестировать, и были автотесты ("Selenium" - подумал Штирлиц) для всех и всяческих сценариев. Автотесты регулярно запускали на свежих билдах, они достаточно быстро выполнялись и радовали всех "зелёными" результатами. "Красные" результаты быстро исследовали, чинили проблему, и каждый следующий запуск был "зеленее" предыдущего. Скоро сказка сказывается, да не скоро дело делается.
У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk'ов зашла речь про автотесты, и выяснилось, что "в реальном мире это не работает". Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема - разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста - вот это всё. Не хотят люди результаты разбирать - неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет "заставить" слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?
Сразу хочется задать кучу уточняющих вопросов, что же именно не работает и почему не работает и какой мир считается реальным и т.п., но не могу: не коллегу же спрашивать про чужие проблемы (слышал я эти Битлз - мне друг по телефону напел). Но понятно, что если на результаты автотестов не смотреть, то можно тогда автотесты и не использовать вообще. С точки зрения бездушной математики это то же самое.
С другой стороны, если сесть и вспомнить, то - ну да, всё так. Разбирать автотесты - это не вдохновляет. Как возникает эта задача, так сразу хочется чем-то другим заняться. На такой случай всегда найдётся Важное Дело, Которое Надо Сделать. То есть проблема не совсем выдуманная, и как-то же её решают те, кто живёт в нереальном мире.
Итак, возможные решения, только здесь и сейчас, спешить узнать.
Возможны противопоказания, проконсультируйтесь со своей командой.
У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk'ов зашла речь про автотесты, и выяснилось, что "в реальном мире это не работает". Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема - разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста - вот это всё. Не хотят люди результаты разбирать - неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет "заставить" слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?
Сразу хочется задать кучу уточняющих вопросов, что же именно не работает и почему не работает и какой мир считается реальным и т.п., но не могу: не коллегу же спрашивать про чужие проблемы (слышал я эти Битлз - мне друг по телефону напел). Но понятно, что если на результаты автотестов не смотреть, то можно тогда автотесты и не использовать вообще. С точки зрения бездушной математики это то же самое.
С другой стороны, если сесть и вспомнить, то - ну да, всё так. Разбирать автотесты - это не вдохновляет. Как возникает эта задача, так сразу хочется чем-то другим заняться. На такой случай всегда найдётся Важное Дело, Которое Надо Сделать. То есть проблема не совсем выдуманная, и как-то же её решают те, кто живёт в нереальном мире.
Итак, возможные решения, только здесь и сейчас, спешить узнать.
Возможны противопоказания, проконсультируйтесь со своей командой.
вторник, 13 октября 2015 г.
Разработка и Продажи
Продажи (падают из-за кулис на сцену и смирно лежат).
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь): Вот черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес
P.S. Основано на вымышленных событиях
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь): Вот черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес
P.S. Основано на вымышленных событиях
суббота, 25 октября 2014 г.
Связанные многочисленными ниточками
В больших компаниях и проектах, тем более распределенных, часто трудно согласовать работу между несколькими людьми и/или командами. Команда А ждет чего-то от команды Б, а та ожидает чего-то от А и от В, а В делает нечто важное, после чего нужно будет потрудиться еще нескольким командам. Это дополнительно усугубляется временными поясами, ролевыми разделениями, иерархией, личными отношениями им много чем еще.
Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.
Стоит потратить пять минут на чтение.
Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.
Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.
Стоит потратить пять минут на чтение.
Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.
среда, 3 октября 2012 г.
100500 конфигураций.
Знакомая многим проблема: тестируя, мы настраиваем продукт и окружение не совсем так, как это делают пользователи. Причин для этого масса – нет того оборудования, недостаточно времени, неучтенные сочетания настроек, более приоритетные задачи и так далее.
Сопутствующая проблема: если покупателей продукта сколько-то больше, чем один, приходится проверять огромный комбинаторный массив конфигураций продукта. Конечно, далеко не все параметры влияют друг на друга, зато порой бывают неочевидные зависимости.
В результате мы рискуем пропустить баги, а пользователи получают шанс их найти, что всегда неприятно.
Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).
Итак, мы хотим тестировать продукт в таких же условиях, в каких он будет работать, или хотя бы в похожих. Одновременно мы хотим проверять допустимые настройки продукта, но не утонуть в многообразии их сочетаний. Как приблизиться к этой цели?
Сопутствующая проблема: если покупателей продукта сколько-то больше, чем один, приходится проверять огромный комбинаторный массив конфигураций продукта. Конечно, далеко не все параметры влияют друг на друга, зато порой бывают неочевидные зависимости.
В результате мы рискуем пропустить баги, а пользователи получают шанс их найти, что всегда неприятно.
Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).
Итак, мы хотим тестировать продукт в таких же условиях, в каких он будет работать, или хотя бы в похожих. Одновременно мы хотим проверять допустимые настройки продукта, но не утонуть в многообразии их сочетаний. Как приблизиться к этой цели?
понедельник, 10 сентября 2012 г.
4k+ знаков про ТО
Тестовое окружение – неизменный спутник тестирования. Неважно, какое ПО мы тестируем, без разницы, какую используем методологию: если мы выполняем тест, то, как минимум, нам нужен объект тестирования в подходящем состоянии. И как только этот объект появляется, появляется и оно, тестовое окружение.
Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).
Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).
понедельник, 16 апреля 2012 г.
Привет, Аноним в поисках вопросов
Внезапно мне пришёл комментарий:
Анонимный прокомментировал(а) ваше сообщение:
Добрый день, Павел.
Решил себя попробовать в тестировании, как мне казалась вещь очень интересная (знания брал из знаменитой для тестировщиков книги Савина), устроился в компанию, которая разрабатывает свой програмный продукт, проработав меньше месяца сбежал, т.к.было настолько скучно (тестирование - черный ящик, метод назывался "свободный поиск").
О чем спрашивать работодателя, когда принимают на работу? какие вопросы задавать по тестированию (чтобы потом не было так скучно)?
Комментарий к комментарию получился длинноват, так что публикую его отдельным постом.
пятница, 20 мая 2011 г.
Новая версия доступна. Обновить?
В жизни приложений, помимо "просто работы", есть масса интересных, пусть и относительно редких событий.
Приложение должно корректно устанавливаться – и нам нужно проверять это.
Приложение должно корректно удаляться (а вдруг!) – и нам нужно проверять это.
Приложение должно корректно обновляться до новой версии – и нам… подождите-подождите… нужно проверять это!
Об апгрейдах и пойдет речь.
Приложение должно корректно устанавливаться – и нам нужно проверять это.
Приложение должно корректно удаляться (а вдруг!) – и нам нужно проверять это.
Приложение должно корректно обновляться до новой версии – и нам… подождите-подождите… нужно проверять это!
Об апгрейдах и пойдет речь.
четверг, 7 апреля 2011 г.
Всего лишь пара изменений
Чем хороши изменения требований - они, пусть даже и возникают неожиданно, а все равно пройдут весь традиционный круг оценок и планирования. Ну ладно, должны проходить. Но все равно об изменениях мы узнаем заранее.
Но не всегда тестировщик заранее знает, что что-то в поведении продукта изменится. Приходит он на работу, берет свежий билд приложения и видит, что добавились/пропали/переехали контролы в GUI. Или поменялась очередность шагов визарда. Или изменилась давно привычная логика работы. Да мало ли что. А чтоб такие изменения планировались, он и не слышал. Баг писать? Или так и должно быть теперь?
В целом понятно, что если оснований для изменений нет, то со стороны тестировщика честно будет написать баг. Возможно, этот баг потом выкинут, но зато хоть повод для обсуждений появится.
Другой вопрос - как такая ситуация могла возникнуть. Есть варианты, да. Возможно, потихоньку идет процесс улучшения GUI и юзабилити продукта. Или - прилетел баг от клиента, и его починили в продукте, а тестировщик этого бага и не видел пока. Или - над продуктом работают несколько команд разработчиков и тестировщиков, каждая в своей песочнице, и время от времени их наработки добавляются в новые билды. Много чего возможно.
И вопрос - как эти изменения контролировать?
В маленьких командах этот вопрос, наверное, не очень актуален, но чем больше людей, тем сложнее работать с изменениями. Тем более, что разным людям и в разное время нужны разные данные об изменениях. Но в любом случае, первое, что приходит на ум - это
пятница, 11 марта 2011 г.
Баг для лога
В предыдущем посте речь шла о пользе чтения логов при исследовании и описании дефектов ПО. Сегодня я хочу зайти немного с другой стороны.
Логи, безусловно, помогают исследовать поведение приложения, но в то же время логи – часть тестируемого продукта. То есть – их тоже можно тестировать. И вокруг них тоже могут водиться баги, а как же.
Предположим, что худшего не случилось, приложение работает и даже пишет логи в положенное место. Перечислю несколько направлений, в которых можно искать проблемы.
Подписаться на:
Сообщения (Atom)