21 ноября, среда 19:32
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Организация процесса тестирования очередных релизов

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Организация процесса тестирования очередных релизов

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

    И еще один вопрос. Каким образом можно определить набор наиболее стабильно работающий набор SP под определенный модуль? Хочется не гадать на кофейной гуще, а поставить именно то, что будет работать, а не оттестированный сырой материал. Чтобы была чуть понятней мысль, поясню. Ставим новый релиз, к нему идет набор заплаток. Очередная заплатка добавляет какой-то новый функционал, но ломает то, что работает. Необходмо угадать такой набор заплаток, чтобы при их установке обеспечивался минимально необходимый для нормальной работы функционал и не возникало критических проблем.
    В терминах портала "Диасофта" версия это
    "Обновления сопровождаемых версий",
    накопительный SP - "Пакеты расширений для сопровождаемых релизов",
    заплатки под отдельные проблемы - "Пакеты исправлений для выпусков сопровождаемых релизов"
    Последний раз редактировалось zbc; 08.07.2009, 10:41.

  • #2
    Я обычно читаю, что они там поправили в релизе. Если мне это необдимо - то ставлю только то, что мне нужно (отдельно проливаю нужные мне скрипты). Муторно конечно, но зато имею почти "идеальную" сборку. Бывает конечно, что приходится проливать все.
    Но, от этого случая перестраховался:
    Сливаю все таблички, процедуры, вьюверы в репозитарий bzr, а затем в логах смотрю на сколько сильно изменилось.
    Примерно так....

    Комментарий


    • #3
      Организуем тестирование силами сотрудников соответствующих подразделений.
      То, что пишет sasaimns не всегда употребимо, поскольку после проливки нужного скрипта можно в процессе работы узнать, что из другого непролитого скрипта для какой-то там талички не хватило парочки столбцов.

      Раздаем ТЗ подразделениям, где указан перечень операций. До заданного срока ответственные (как правило руководители) пишут электронное письмо, если нашли что странное.

      Комментарий


      • #4
        Сообщение от Dolphina12 Посмотреть сообщение
        Раздаем ТЗ подразделениям, где указан перечень операций. До заданного срока ответственные (как правило руководители) пишут электронное письмо, если нашли что странное.
        А кто рулит процессом: кто что в каком графике и как проверяет?
        Я обычно читаю, что они там поправили в релизе. Если мне это необдимо - то ставлю только то, что мне нужно (отдельно проливаю нужные мне скрипты). Муторно конечно, но зато имею почти "идеальную" сборку. Бывает конечно, что приходится проливать все.
        Но, от этого случая перестраховался:
        Сливаю все таблички, процедуры, вьюверы в репозитарий bzr, а затем в логах смотрю на сколько сильно изменилось.
        Примерно так....
        Мысль приливать только то, что надо интересная.
        Но для этого надо хорошо знать, что надо и следить за всем...
        Хотя при правильном подходе метод позволит не проливать лишние баги.
        Также в данной методике неясно, как поступать в таком случае с файлами клиентской части - не все же изменения только в таблицах да скриптах, кое-чего и в bpl меняется. Если я проливаю только набор избранных патчей, с какого набора bpl это чудо запускать?

        И все ж интересует: с какого примерно SP после выпуска релиза начинается более-менее стабильная версия? Насколько мне известно, дельфины имеют обыкновение выкладывать скрипты, даже если сами вообще ничего не оттестировали (т.е полностью сырой, непригодный к использованию код). Потом под влиянием информации от взбешенных клиентов дыры начинают латать, и через некоторое время все временно устаканивается до новых доработок.
        Важно угадать, чем именно можно пользоваться. Есть какая либо статистика по этому вопросу?
        Последний раз редактировалось zbc; 09.07.2009, 10:58.

        Комментарий


        • #5
          Сообщение от Dolphina12 Посмотреть сообщение
          Организуем тестирование силами сотрудников соответствующих подразделений.
          То, что пишет sasaimns не всегда употребимо, поскольку после проливки нужного скрипта можно в процессе работы узнать, что из другого непролитого скрипта для какой-то там талички не хватило парочки столбцов.

          Раздаем ТЗ подразделениям, где указан перечень операций. До заданного срока ответственные (как правило руководители) пишут электронное письмо, если нашли что странное.
          А я не сказал, что тестирование отменяется
          Не думаю, чт оу всех банков куплены все модули и все настроены. И зачем проливать SP, если и так все устраивает? Проливка ради проливки?

          Комментарий


          • #6
            *****Хотя при правильном подходе метод позволит не проливать лишние баги.
            Также в данной методике неясно, как поступать в таком случае с файлами клиентской части - не все же изменения только в таблицах да скриптах, кое-чего и в bpl меняется. Если я проливаю только набор избранных патчей, с какого набора bpl это чудо запускать?


            Дык пишут же:
            3. 562087. Таблица "Внутренний контроль". Поле "Клиент" не всегда
            отображалось в таблице. Теперь поле "Клиент" отображается в таблице всегда.

            По данной задаче произведены следующие изменения:
            доработаны бинарные модули:
            * d5ntref.bpl

            Комментарий


            • #7
              Для определения перечня проверяемых операций, исходя из описания изменений и собственного многолетнего опыта попадания, на критические баги и их значимость, составляется перечень.
              В документе, где операции сгруппированы по подразделениям, просто указан ответственный. А уж он сам решает, кого привлекать и для чего.
              Сервис паки и новые релизы действительно отдаются клиенту без базового тестирования, ошибки бывают самые грубые.

              Одна из мыслей при обдумывании процесса тестирования для уменьшения времени отдачи такому процессу - общая ветка форума (подфорум), хоть на банкире, хоть на форуме Диасфта, где представитель банка указывал бы на найденные проблемы, и коллеги решали, проливать ли с такими ошибками, готовили обходные маневры, если изменения пролиты. Предпочтительней был бы форум Диасофта, где можно было бы по месту положить и уточняющую информацию, и Диасофт мог бы отчитаться по исправлению.
              Проливку ради проливки не делаем. Ставим патчи или обновляем версию, если для нас важны изменения в ней.
              Но другой вопрос, что копмания Диасофт неадекватно формирует описание к изменениям. В файле описания все изменения за множество релизов.

              Копаться и искать изменения в скриптах сравнением и выбирать нужные не готовы, нету столько времени.

              Комментарий


              • #8
                Сообщение от sasaimns Посмотреть сообщение
                Также в данной методике неясно, как поступать в таком случае с файлами клиентской части - не все же изменения только в таблицах да скриптах, кое-чего и в bpl меняется. Если я проливаю только набор избранных патчей, с какого набора bpl это чудо запускать?


                Дык пишут же:
                3. 562087. Таблица "Внутренний контроль". Поле "Клиент" не всегда
                отображалось в таблице. Теперь поле "Клиент" отображается в таблице всегда.

                По данной задаче произведены следующие изменения:
                доработаны бинарные модули:
                * d5ntref.bpl
                А если один и тот же бипиэль меняется по нескольким нужным нам патчам, какой брать?

                Комментарий


                • #9
                  Сообщение от zbc Посмотреть сообщение
                  А если один и тот же бипиэль меняется по нескольким нужным нам патчам, какой брать?
                  Берем по последнему...

                  Комментарий


                  • #10
                    Сообщение от Dolphina12 Посмотреть сообщение
                    Сервис паки и новые релизы действительно отдаются клиенту без базового тестирования, ошибки бывают самые грубые.
                    Хм, раз слабО качественный материал выкладывать, снабжали хотя-бы информацией о статистике: какой релиз с каким набором заплаток по каким модулям у скольких клиентов работает.
                    Чтобы шлак не проливать.
                    Меня эта лотерея начинает напрягать.
                    И почему в договорах нет требований к качеству? Удивляет: куда юристы смотрят?
                    Все ж элементарно: критичный баг в заплатках, приводящий к остановке или затруднению техпроцессов - сумма месячной оплаты за сопровождение автоматически уменьшается на 30%. И так далее в том же духе. Всё должно подсчитано и расписано. А то покупается фирменный продукт - а к нему еще клиенту приходится банду собственных тестировщиков держать. И автономно организовывать процессы тестирования. Абсурд какой-то.
                    Последний раз редактировалось zbc; 13.07.2009, 18:11.

                    Комментарий


                    • #11
                      Сообщение от zbc Посмотреть сообщение
                      И почему в договорах нет требований к качеству? Удивляет: куда юристы смотрят?
                      А кто тебе мешает это сделать?

                      Комментарий


                      • #12
                        Сообщение от CostYa Посмотреть сообщение
                        А кто тебе мешает это сделать?
                        Диасофт же и мешает
                        ОН не подписывает договора, на не удобных ему условиях
                        Проверено
                        Уже лет 7 общаюсь - все равно "наклоняют" к свом условиям

                        Комментарий


                        • #13
                          Сообщение от sasaimns Посмотреть сообщение
                          Диасофт же и мешает
                          ОН не подписывает договора, на не удобных ему условиях
                          Проверено
                          Вот это и странно. Один "Диасофт", несколько сот клиентов, и он всех "наклоняет" :-) Вообще-то клиенты должны его "наклонять" а не наоборот.
                          Сообщение от CostYa
                          Сообщение от zbc
                          И почему в договорах нет требований к качеству? Удивляет: куда юристы смотрят?
                          А кто тебе мешает это сделать?
                          Вообще говоря это не сфера моей компетенции. Договорами соотв. отдел занимается. Я могу только пожелания высказать - а в переговорах участвовать все равно будут другие.

                          Комментарий


                          • #14
                            Сообщение от zbc Посмотреть сообщение
                            Вот это и странно. Один "Диасофт", несколько сот клиентов, и он всех "наклоняет" :-) Вообще-то клиенты должны его "наклонять" а не наоборот.

                            Вообще говоря это не сфера моей компетенции. Договорами соотв. отдел занимается. Я могу только пожелания высказать - а в переговорах участвовать все равно будут другие.
                            Есть у меня друзья из весьма большого банка.
                            Так вот , я видел, как Диасофт сам плясал под их "дудку".
                            Но там, понятно чем обусловливается - они платят за поддержку в месяц, столько же, как мой банк за год.
                            Вот они и боятся потерять клиента.
                            Причем, как говорят друзья, у них бетта-версий от диасофта не поступает. ТОЛЬКО провереные релизы.
                            А мы с вами служим - тестерами

                            Комментарий


                            • #15
                              Коллеги! Вопросы решаются, но только объединением усилий. Если бы нам продружиться и сформировать нечто вроде комиссии и коллективно "наклонять" Диасофт, то думаю и условия договоров были бы подходящие и качество релизов.
                              Только как?
                              Обратная сторона медали внесения в договор требования качества программного продукта - физическая возможность реальных людей в рамках огромного продукта избежать ошибок или провести абсолютно полное тестирование. Нереально это в нынешних условиях сложностей программного кода. А вот идею перевоспитать подразделение тестирования Диасофта поддерживаю полностью.

                              Комментарий


                              • #16
                                Коллективный разум - вещь замечательная. Особенно если по делу. Прежде чем пытаться перевести Диасофт на сопровождение по публичной оферте (что ИМХО безнадежно по определению), постарайтесь сформулировать юридически грамотный текст этого самого "требования по качеству". А уж заставить диасофт вставить разумное требование в договор - это вполне реальная задача.
                                Serg Voronov

                                Комментарий


                                • #17
                                  Сообщение от Dolphina12
                                  Обратная сторона медали внесения в договор требования качества программного продукта - физическая возможность реальных людей в рамках огромного продукта избежать ошибок или провести абсолютно полное тестирование. Нереально это в нынешних условиях сложностей программного кода.
                                  Вы хотите сказать, что производственные процессы "Диасофта" и квалификация персонала столь совершенны, что количество ошибок минимально и не поддается уменьшению? У меня в этом большие сомнения.
                                  Личное мнение: отношение к ошибкам в "Диасофте" в корне неверное. Ошибка считается вполне допустимой вещью, причем считается нормальным, что специалисты клиента тратят существнное время на ее выявление, формилировку, помощь в устранении и т.п.
                                  В норме каждая ошибка должна приводить к прямым финансовым потерям "Диасофта" - только в этом случае у него будет стимул избегать их.
                                  Сообщение от Serg_FSB Посмотреть сообщение
                                  Прежде чем пытаться перевести Диасофт на сопровождение по публичной оферте (что ИМХО безнадежно по определению), постарайтесь сформулировать юридически грамотный текст этого самого "требования по качеству".
                                  Отличная мысль! Давайте устроим тут конкурс формулировок, раз юристы "спят в одном ботинке".
                                  Последний раз редактировалось zbc; 16.07.2009, 10:50.

                                  Комментарий


                                  • #18
                                    Сообщение от zbc Посмотреть сообщение
                                    Вы хотите сказать, что производственные процессы "Диасофта" и квалификация персонала столь совершенны, что количество ошибок минимально и не поддается уменьшению? .
                                    Мой личный ответ ( на собственном опыте)
                                    У меня на работе есть поддержка диасофта.
                                    Они считают диасофт чуть не божеством. Все что пришло о диасофта - есть "закон" и не подлежит обсуждению и, все попытки наглядные и не наглядные, указать на "просчеты" диасофта, принимаются в штыки.


                                    P.S. мысли в слух...

                                    Комментарий


                                    • #19
                                      Сообщение от sasaimns Посмотреть сообщение
                                      Мой личный ответ ( на собственном опыте)
                                      У меня на работе есть поддержка диасофта.
                                      Они считают диасофт чуть не божеством. Все что пришло о диасофта - есть "закон" и не подлежит обсуждению и, все попытки наглядные и не наглядные, указать на "просчеты" диасофта, принимаются в штыки.


                                      P.S. мысли в слух...
                                      Ну-ну... Ездил на встречу одноклассников, одна девица в банке работает. Дернул черт меня ляпуть, что занимаюсь в т.ч. поддержкой "Диасофта". Ответ был такой: - А-а-а, знаем. Это такое гнусное фуфло, вечно глючит, все плюются...
                                      Я не знал, что на это ответить.
                                      Вот такое божество. С приставкой У.

                                      Комментарий


                                      • #20
                                        Сообщение от zbc Посмотреть сообщение
                                        Ну-ну... Ездил на встречу одноклассников, одна девица в банке работает. Дернул черт меня ляпуть, что занимаюсь в т.ч. поддержкой "Диасофта". Ответ был такой: - А-а-а, знаем. Это такое гнусное фуфло, вечно глючит, все плюются...
                                        Я не знал, что на это ответить.
                                        Вот такое божество. С приставкой У.
                                        и смех и слезы

                                        Комментарий


                                        • #21
                                          Возвращаясь к процессу тестирования.
                                          Интересно: как именно проходит этот процесс?
                                          От внедрения у нас остался неплохой набор оформленных тест-кейсов.
                                          И теоретически перед сменой билда можно было бы силами специалистов, занимающихся учетом операций в соотв. модулях, прогонять эти тест-кейсы.
                                          Но при этом есть несколько проблем:
                                          1) Учетные сотрудники при этом занимаются не совсем привычной для себя деятельностью, и нужны дополнительные трудозатраты на разъяснения как именно и что им необходимо делать.
                                          2) Процесс может быть довольно трудоемкий, и сложно его организовать без ущерба для основной дейтельности.
                                          3) Покрытия тестов все равно может не хватить для выявления критичных
                                          проблем.
                                          4) Нужно руководство всеми действиями, координирующее деятельность учетных сотрудников, сотрудников отделов сопровождения и тестирования.
                                          У кого-нибудь есть опыт работы с тест-кейсами? Как все организовано и проходит? Сколько времени занимает?

                                          Комментарий

                                          Пользователи, просматривающие эту тему

                                          Свернуть

                                          Присутствует 1. Участников: 0, гостей: 1.

                                          Обработка...
                                          X