Как снизить количество ошибок после очередной доработки системы?
Здравствуйте
Ситуация такая: есть система 1с предприятие.
Программисты, на основании заданий бизнес-аналитиков, дорабатывают объекты системы 1с, пишут новые компоненты (новые документы, регистры и т.д.).
Размещают доработки в хранилище и обновляет тестовую базу.
В итоге часто, но не всегда, получаем:
-Новую доработку
-Новые ошибки которые пришли вместе с доработкой
Каким образом можно наладить работу программистов, таким образом чтобы снизить количество ошибок в системе которые произошли после новой доработки? Может какой-либо инструмент или методику работы внедрить? Подскажите пожалуйста.
Прошу прощения, что пишу здесь, но ваш вопрос был закрыт и я не успел ответить вам в комментариях.
Так вот. Честно говоря я пока сам не считаю себя достаточно опытным чтобы глобально рассуждать о полиморфизме, но, возвращаясь непосредственно к интерфейсам и наследованию... Наследование все же принято использовать в ситуациях, когда между классами имеется так называемое IS-A отношение, то есть когда можно сказать, что B является A (например: кошка (класс наследник) является млекопитающим (класс предок), млекопитающие в свою очередь являются животными и т.д), в то время как интерфейсы призваны скорее дополнять функционал. К тому же в Java не поддерживается множественное наследование, т.е предок может быть только один, а вот количество реализуемых интерфейсов не ограничено.
За примером далеко ходить не нужно. В Java есть интерфейс AutoCloseable, он позволяет использовать реализующие его объекты в блоках try-with-resources. Если посмотреть документацию и взглянуть на перечень классов, которые его реализуют, то там можно встретить стримы, ридеры, врайтеры, сокеты и т.д, то есть классы не просто разные, а зачастую кардинально разные и не имеющих общих предков. Если бы интерфейсов не было, то у каждого из этих классов должен был бы быть некий общий AutoCloseable-предок, а так как множественное наследование не поддерживается, то этого предка пришлось бы засунуть в вершину иерархии, но тогда абсолютно все его наследники станут autocloseable, хотя фактически эта функция нужна лишь единичным классам. В общем это был бы ужаснейший костыль. Но раз у нас есть интерфейс, то мы спокойно можем заимплементить его именно в тех классах, где он нужен, дополняя тем самым их функционал, а не видоизменяя его в корне.
не совсем понял, это метод в вашем примере или переменная? Вы пишите что метод, а приведенном к примеру кода, указано что это число Int numberOfEmployers
Или вы имели ввиду что у интерфейса есть еще поле numberOfEmployers, в котором хранится данные о количестве сотрудников И метод numberOfEmployers, который считает количество сотрудников?
// Subdivision это тот самый интерфейс "Подразделение"
int getFoodCost(Subdivision subdivision) {
// допустим, что на каждого человека тратится по 300 руб в день
return subdivision.numberOfEmployers() * 300;
}
В результате мы получаем метод, который может работать абсолютно с любыми классами, которые реализуют интерфейс Subdivision. А вот если бы вы не использовали интерфейс, а просто добавили бы в каждый класс по методу numberOfEmployers(), то для каждого класса пришлось бы писать свою версию getFoodCost().
Конкретно в моём примере метод getFoodCost не является частью интерфейса и реализующих его классов, это некий внешний метод
interface Subdivision {
int numberOfEmployers();
}
class Workshop implements Subdivision {
@Override
public int numberOfEmployers() {
// тут должна быть реализация интерфейса
}
}
class Department implements Subdivision {
@Override
public int numberOfEmployers() {
// тут должна быть реализация интерфейса
}
}
class Service {
public static void main(String[] args) {
Workshop workshop1 = new Workshop();
Department department1 = new Department();
// some code
int sum1 = getFoodCost(workshop1);
int sum2 = getFoodCost(department1);
}
public static int getFoodCost(Subdivision subdivision) {
return subdivision.numberOfEmployers() * 300;
}
}
Спасибо. А какой из них подойдет для группы в которой есть только РП, бизнес-аналитик, программист?
Тестированием кому заниматься? Программисту, у которого задач выше крыши (но при этом выкатывает новые баги при доработках), или Аналитику которые не знает язык программирования, для написания сценариев теста на языке программирования
А какой из них подойдет для группы в которой есть только РП
- это не варианты, а идеальная ситуация, когда у вас есть все сразу. От тестирования самых простых методов, до автоматизированного прогона конкретного use-case
Программисту, у которого задач выше крыши
вот с этим к РП. Просто закидать задачами на разработку - это не управление проектом. Такими вопросами на планировании нужно обязательно задаваться, как тестировать
или Аналитику которые не знает язык программирования
- я понимаю, ситуация тяжелая. Но, давайте честно, не уникальная. Есть BDD практики, когда разработчик описывает в коде простые операции (нажать кнопку, проверить значение и т.д.), а аналитик/тестировщик/менеджер пишет на вполне человеко читаемом языке тестовые сценарии, все это связывается и исполняется
Тестированием кому заниматься
- ну остается вариант нанять тестировщика (уверен, в вашем городе их чуть меньше, чем юристов и SMMщиков). Если нет такого, возьмите удаленного.
Меня, например. Я автоматизирую тестирование =)
Что не выбери, исход один - нужно выделять ресрсы на тестирование: или еще человека искать или оставлять команде время на тестирование.
Но сами собой баги не перестанут появляться, вы же понимаете
Дмитрий Еремин: Вы автоматизируете тестирование? Что это значит? Т.е. что вы сделаете?
Есть возможность автоматизировать тестирование таким образом, чтобы система сама на этапе разработки программисту подсказывала, что данная доработка негативно повлияет на другой объект. К примеру: При реализации описанного кода (метода), поле "Полное наименование" справочника Номенклатура становится недоступной для редактирования!
- эта деятельность подразумевает написание кода, который тестирует код (т.е. вызов методов с разными параметрами и проверка результатов)
и/или код, который иммитирует действия пользователя в системе (жмет на кнопки, вводит значения и т.д.)
Есть возможность автоматизировать тестирование таким образом, чтобы система сама на этапе разработки программисту подсказывала, что данная доработка негативно повлияет на другой объект.
- из коробки, такого решения нет. Ведь, никто, кроме вас не знает, что является негативным влиянием, а что позитивным. Вдруг, вам так и надо, чтобы после новой доработки, справочник стал недоступным для редактирования?
Очевидно, вам, как минимум, потребуется база знаний, что хорошо, а что плохо для вашего продукта. Но, при этом:
К примеру: При реализации описанного кода (метода), поле "Полное наименование" справочника Номенклатура становится недоступной для редактирования!
Представьте, перед запуском в прод, вы запускаете 200 автотестов (которые вы или вам написали)
И вдруг падает тест, который проверяет, что можно в справочник добавлять новую запись. Вот, пожалуйста, автотест выявил недоступность справочника для редактирования.
Наличие ошибок - это отсутствие или неполноценное тестирование.
Вызывает вопросы ваша тестовая база - зачем она вам, если она не защищает от ошибок? Кто обнаруживает ошибки в рабочей базе и почему вы не даете этим людям возможность увидеть эти ошибки еще во время обновления тестовой базы?
1. В проекте тестировщик нет.
Функциональным тестированием занимаются сами бизнес-аналитики
2. Ошибки конечно же обнаруживаются в тестовой базе.
3. Хотел бы исключить ошибки которые затрагивают другие объекты 1с.
Пример: Задача: нужно было добавить новое поле с типом "Ссылка на справочник Единица измерения" в справочник "Номенклатура". Программист поле добавил, доработал справочник Номенклатур.
а) Но теперь при попытке записать форму элемента Номенклатура, система ругается, не записывает, выводит сообщение
б) или теперь при попытке открыть список номенклатур, система выводит ошибку.
Итог, вместо того, чтобы бизнес-аналик протестировал работу нового поля, он занимается фиксацией нового бага, при этом протестить новую доработку он не сможет, пока не исправят баг.
4. И еще вопрос всплыл, Тестированием кому заниматься? Программисту, у которого задач выше крыши (но при этом выкатывает новые баги при доработках), или Аналитику которые не знает язык программирования, для написания сценариев теста на языке программирования
5. Было бы неплохо, если система позволяла на этапе написания кода, проверять и подсказывать программисту, что указанная доработка негативно влияет на работу другого справочника и т.д.
kiru:
1. Наймите.
2. Сделайте так, чтобы данные в тестовой базе были как можно ближе к реальным. в идеале - копия реальной базы.
3. Чтобы исключить эти ошибки, нужно проводить более полное тестирование. В приведённом примере я считаю, что это косяк программиста, слишком очевидная функциональность сломана. Но в других случаях это будет работа тестировщика.
4. Тестировщику.
5. Это 1С, а не какая то там серьёзная среда для разработки.
Резюмируя:
1. Более квалифицированные разработчики оставляют после себя меньше багов и лучше тестируют (да, это так).
2. Возьмите/обучите тестировщиков.
Разработчиков можно обучить/повысить квалификацию. Можно обучить бизнес-аналитиков быть тестировщиками. Но это только в случае, если люди сами хотят этим заниматься (нечастый случай).
Игорь: Спасибо за развернутый ответ.
Не совсем понял ответ по 5 пункту.
5. Было бы неплохо, если система позволяла на этапе написания кода, проверять и подсказывать программисту, что указанная доработка негативно влияет на работу другого справочника и т.д.
Цитата: Это 1С, а не какая то там серьёзная среда для разработки. ///Т.е. вы имеете ввиду в конфигураторе можно настроить таким образом, чтобы она проверяла и подсказывала указанная доработка негативно влияет на работу другого справочника? Если да. то можете подсказать в каком направлении поиска двигаться подобного решения? Есть ли такие системы?
kiru: я имею в виду, что платформа 1С не предназначена для создания каких то серьёзных систем (изначально). Её конструкция не подходит для больших систем. Продвинутых инструментов (в т.ч. для отладки и тестирования) в ней, как у других платформ типа java и т.д. нет.
Поэтому делать аналогичные вещи на 1С сложнее, а какие-то фичи невозможно или становится с невозможно с определённого момента.
kiru: Вы не посмотрели ссылки, которые я привел? Это как раз самые популярные инструменты для автоматического (без участия выделенного тестировщика) тестирования.
Тут два решения от самой 1С. Сценарное тестирование - часть КИПа (платная функциональность от 1С для крупных корпоративных внедрений), применяемая со времен 8.1. Недавно появившаяся функциональность в самой платформе, которая позволяет записать и "проиграть" сценарий работы пользователя.
Далее решения от энтузиастов. "Серебренная пуля" наворотила что-то очень страшно крутое, что многим нравится (но еще большее количество 1С-программистов не понимают и половины слов из описания их инструментов). Далее решение от Дмитрия Решитко, где все сделано на базе конфигурации с тестами - довольно просто и понятно.
Лично ни разу не применял данные инструменты. Но общая концепция следующая. В момент приемки работ от программиста можно запускать батник, который:
1) Разворачивает из архива эталонную базу, на которую есть написанные тесты (создание справочников, документов, формирование отчетов, запуски обработок и так далее по типовому рабочему дню компании).
2) На базу автоматически накатывается тестируемая конфигурация.
3) Запускаются автоматические тесты.
4) Или говорим программисту "Спасибо" или выдаем ему список найденных ошибок.
Программист поле добавил, доработал справочник Номенклатур. ...теперь при попытке открыть список номенклатур, система выводит ошибку.
Для меня все это звучит дико. Объясняю:
1) После доработки форм я всегда открываю и тестирую свою работу. Если я делаю новое поле, то я гарантирую, что данные в него заносятся согласно ТЗ - со всеми требуемыми проверками ввода, выпадающими списками с подсказками и изменением связанных полей; сохарняются и при повторном открытии все еще видны.
2) Я дергаю получившуюся форму в разные стороны, что бы убедится, что привязки не нарушились и все элементы формы доступны пользователям.
Для меня минимальное тестирование своей работы священно, даже если я вижу конфигурацию в первый раз и не догадываюсь о назначении части элементов на форме.
В вашем случае я вижу штатного программиста, который должен знать конфигурацию как свои 5 пальцев, но который делает какую-то хрень и спихивает вашему аналитику даже не задумываясь о том что он сделал (иначе бы он заметил неработающий список, который не даст попасть ему на доработанную форму элемента). Это какой-то проходимец. Может он вообще ничего не программирует, а копирует случайный код из интернета?
P.S. Кстати, на одном внедрении я работал в паре с аналитиком. Было просто супер. Аналитик собирал требования и описывал в виде перечня доработок отчетов и форм, я программировал, а аналитик тестировал, писал инструкции и отдавал пользователям. Работали как конвейер. Очень эффективная схема.
Дмитрий Кинаш: смотрел, спасибо большое. Однако для того чтобы автоматически тестировалось, надо сначала написать на языке программирования этот сценарий теста) (если говорить об 1с тестирование)
Есть только один способ - наймите программистов более высокой квалификации (ну или доучите существующих). Это единственный способ кардинально уменьшить количество ошибок. Никакие тесты даже близко не дадут сопоставимого результата.
как уже выше ответил FreeBa, только более квалифицированные специалисты, которые умеют грамотно планировать разработку и делать грамотный рефакторинг, спасут вас от бесчисленных ошибок
или вы платите за тонны тестирования и исправление ошибок, или за грамотных специалистов
Коллеги выше уже по большей части ответили.
Если вы работаете с управляемыми формами, я бы посоветовал вам внедрить в отдел программирования программу Тестер (test1c.com), полностью бесплатная, с документацией.
Средний
Сложный
