Комментарии 51
Спасибо за проявленный интерес к статье.
Постараюсь развернуто ответить на все ваши вопросы.
По поводу автоматизации:
В статье затронут пласт крупных проектов ГИС с 2009 по 2019 включительно.
В то время, когда мы начинали тестировать свой первый крупный ГИС — автоматизация была не развита, тестирование как отрасль была в самом зародыше.
Такого объема информации, как сейчас не было. Сроки были сильно сжатые и все тестировщики крутились, как могли. Нам было важно, хотя бы популярные браузеры покрыть smok-тестами.
Вопроса о выделении отдельной команды автоматизации в тот момент не стояло, т.к. не было представления как это организовать правильно, да еще и чтоб это работало эффективно.
В тот момент считали, что ручные функциональные тестировщики, участвовавшие в тесте плановых релизов и хот-фиксов, могут, хотят и должны одновременно каким-то чудом еще и автоматизировать. Но это было физически невозможно.
Конечно мы пытались все это делать одновременно, но итоги были печальные.
Первые затраты на автоматизацию были очень велики и пошли все в корзину. После неудачной первой попытки мы приостановили автоматизацию на какое-то время.
Позже, на других проектах, уже более осознанно подходили к этому вопросу и мои коллеги в статьях, на которые я давала ссылки выше, написали, как это делали.
Как шло распределение команд?
Команда была распределенной как по тестированию, так и по аналитике и разработке.
Основные коммуникации – проектных чаты в skype, telegram или slack. Команды были распределенными и по часовым поясам, но большая часть все-таки работали по Московскому времени. Вопрос часовых поясов был решен договоренностями. К примеру, многие с удовольствием соглашались работать по Московскому времени, а кто не мог, подключались по своему часовому поясу и часто это было удобно, кто-то готов был менять график работы со смещением во времени. Всегда решалось индивидуально и по договоренностям. Регулярное общение в чатах и регулярные созвоны, снимали все вопросы и не требовали наличия всей команды в офисе, сидящей спина к спине.
Распределение по функционалу делалось после проведения собеседования, учитывались опыт и навыки каждого тестировщика. Я не сторонник ставить на тестирование веб-сервисов тестировщика, который никогда не тестировал веб-сервисы, если только он сам не выразил желание изучить этот вид тестирования. Но, даже если он сам проявил инициативу, его обязательно прикрепляла к старшему тестировщику, который его обучал и передавал опыт и знания не только принципов тестирования веб-сервисов, но и погружал в бизнес процесс своей подсистемы. Желающим сменить подсистему предоставлялась такая возможность и принцип погружения был таким же. Сначала более опытный тестировщик передавал свои знания, затем по возможности проходило собеседование с аналитиком по подсистеме (это не обязательно, но если есть такая возможность, это прекрасно), когда все этапы погружения в новую область пройдены, менялась матрица знаний и тестировщик развивался на проекте, совершенствуя свои навыки в новой подсистеме.
Если рассматривать вопрос с точки зрения опыта тестировщиков, то на больших проектах, где команды более 15-20 человек и больше, старалась делить их на группы по 3-5-8 тестировщиков в группе, при этом, компетенции в каждой группе рекомендую делать сбалансированными. Под сбалансированностью компетенций подразумеваю следующее – 1 ведущий тестировщик, два старших, три младших (например для команды из 5 человек). Такое соотношение на мой взгляд, рабочее и эффективное.
Конечно бывали ситуации, когда подсистема была очень объемной по функционалу и часто дорабатываемой, в этом случае распределение компетенций могло отличаться в сторону усиления группы и увеличения ее численности.
На валидацию дефектов и погружение в проект, а также для наработки опыта, часто привлекались стажеры и как раз на такого рода задачах они очень быстро погружались в проект и вливались в команду, спустя 3-6 месяцев они уже становились младшими тестировщиками, полноценно участвовали в тестировании новых доработок.
Касаемо бюджета на тестирование.
Т.к. речь в статье в большей степени о ГИС, то после того, как выигран конкурс на разработку системы, бюджет тестирования заложен в контракт и он включает в себя определенные риски, в том числе, связанные с изменением законодательства или нормативной документации.
Острого недостатка в бюджете не было, но вопрос об оптимальности работы команды возникает всегда и мы стараемся совершенствоваться в процессе тестирования, чтобы не тратить впустую бюджет на ненужные телодвижения или неоптимальную работу, обычно это заслуга всей проектной команды.
На рабочих совещаниях обсуждаются планы всей проектной команды и тестирования в том числе. Если тестирование выбивается из сроков релиза, каждый случай обсуждаем и анализируем, вырабатываем оптимальный вариант решения ситуации, при необходимости меняем планы или объем работ, расширяем команду, если это возможно и целесообразно. Внедряем автоматизацию, естественно.
Постараюсь развернуто ответить на все ваши вопросы.
По поводу автоматизации:
В статье затронут пласт крупных проектов ГИС с 2009 по 2019 включительно.
В то время, когда мы начинали тестировать свой первый крупный ГИС — автоматизация была не развита, тестирование как отрасль была в самом зародыше.
Такого объема информации, как сейчас не было. Сроки были сильно сжатые и все тестировщики крутились, как могли. Нам было важно, хотя бы популярные браузеры покрыть smok-тестами.
Вопроса о выделении отдельной команды автоматизации в тот момент не стояло, т.к. не было представления как это организовать правильно, да еще и чтоб это работало эффективно.
В тот момент считали, что ручные функциональные тестировщики, участвовавшие в тесте плановых релизов и хот-фиксов, могут, хотят и должны одновременно каким-то чудом еще и автоматизировать. Но это было физически невозможно.
Конечно мы пытались все это делать одновременно, но итоги были печальные.
Первые затраты на автоматизацию были очень велики и пошли все в корзину. После неудачной первой попытки мы приостановили автоматизацию на какое-то время.
Позже, на других проектах, уже более осознанно подходили к этому вопросу и мои коллеги в статьях, на которые я давала ссылки выше, написали, как это делали.
Как шло распределение команд?
Команда была распределенной как по тестированию, так и по аналитике и разработке.
Основные коммуникации – проектных чаты в skype, telegram или slack. Команды были распределенными и по часовым поясам, но большая часть все-таки работали по Московскому времени. Вопрос часовых поясов был решен договоренностями. К примеру, многие с удовольствием соглашались работать по Московскому времени, а кто не мог, подключались по своему часовому поясу и часто это было удобно, кто-то готов был менять график работы со смещением во времени. Всегда решалось индивидуально и по договоренностям. Регулярное общение в чатах и регулярные созвоны, снимали все вопросы и не требовали наличия всей команды в офисе, сидящей спина к спине.
Распределение по функционалу делалось после проведения собеседования, учитывались опыт и навыки каждого тестировщика. Я не сторонник ставить на тестирование веб-сервисов тестировщика, который никогда не тестировал веб-сервисы, если только он сам не выразил желание изучить этот вид тестирования. Но, даже если он сам проявил инициативу, его обязательно прикрепляла к старшему тестировщику, который его обучал и передавал опыт и знания не только принципов тестирования веб-сервисов, но и погружал в бизнес процесс своей подсистемы. Желающим сменить подсистему предоставлялась такая возможность и принцип погружения был таким же. Сначала более опытный тестировщик передавал свои знания, затем по возможности проходило собеседование с аналитиком по подсистеме (это не обязательно, но если есть такая возможность, это прекрасно), когда все этапы погружения в новую область пройдены, менялась матрица знаний и тестировщик развивался на проекте, совершенствуя свои навыки в новой подсистеме.
Если рассматривать вопрос с точки зрения опыта тестировщиков, то на больших проектах, где команды более 15-20 человек и больше, старалась делить их на группы по 3-5-8 тестировщиков в группе, при этом, компетенции в каждой группе рекомендую делать сбалансированными. Под сбалансированностью компетенций подразумеваю следующее – 1 ведущий тестировщик, два старших, три младших (например для команды из 5 человек). Такое соотношение на мой взгляд, рабочее и эффективное.
Конечно бывали ситуации, когда подсистема была очень объемной по функционалу и часто дорабатываемой, в этом случае распределение компетенций могло отличаться в сторону усиления группы и увеличения ее численности.
На валидацию дефектов и погружение в проект, а также для наработки опыта, часто привлекались стажеры и как раз на такого рода задачах они очень быстро погружались в проект и вливались в команду, спустя 3-6 месяцев они уже становились младшими тестировщиками, полноценно участвовали в тестировании новых доработок.
Касаемо бюджета на тестирование.
Т.к. речь в статье в большей степени о ГИС, то после того, как выигран конкурс на разработку системы, бюджет тестирования заложен в контракт и он включает в себя определенные риски, в том числе, связанные с изменением законодательства или нормативной документации.
Острого недостатка в бюджете не было, но вопрос об оптимальности работы команды возникает всегда и мы стараемся совершенствоваться в процессе тестирования, чтобы не тратить впустую бюджет на ненужные телодвижения или неоптимальную работу, обычно это заслуга всей проектной команды.
На рабочих совещаниях обсуждаются планы всей проектной команды и тестирования в том числе. Если тестирование выбивается из сроков релиза, каждый случай обсуждаем и анализируем, вырабатываем оптимальный вариант решения ситуации, при необходимости меняем планы или объем работ, расширяем команду, если это возможно и целесообразно. Внедряем автоматизацию, естественно.
Да, года были не те для полной автоматизации. Самое главное, осознали, что тестирование уже на анализе требований вводить необходимо! Как шло распределение команд? Кто посильнее писал кейсы, чек-листы и обдумывал логику подхода? А с разрабами как общались? Hangouts или что-то наподобие? Ещё вопрос по бюджету, т.к. система государственная, выделение денежных ресурсов и времени было не заморочным? Не скажешь ведь на собрании: нам надо 2 недели тестов и полного анализа, а за это время всё 3 раза поменялось и бюджет слит, мы ничего не сделали
Спасибо за проявленный интерес к статье.
Постараюсь развернуто ответить на все ваши вопросы.
По поводу автоматизации:
В статье затронут пласт крупных проектов ГИС с 2009 по 2019 включительно.
В то время, когда мы начинали тестировать свой первый крупный ГИС — автоматизация была не развита, тестирование как отрасль была в самом зародыше.
Такого объема информации, как сейчас не было. Сроки были сильно сжатые и все тестировщики крутились, как могли. Нам было важно, хотя бы популярные браузеры покрыть smok-тестами.
Вопроса о выделении отдельной команды автоматизации в тот момент не стояло, т.к. не было представления как это организовать правильно, да еще и чтоб это работало эффективно.
В тот момент считали, что ручные функциональные тестировщики, участвовавшие в тесте плановых релизов и хот-фиксов, могут, хотят и должны одновременно каким-то чудом еще и автоматизировать. Но это было физически невозможно.
Конечно мы пытались все это делать одновременно, но итоги были печальные.
Первые затраты на автоматизацию были очень велики и пошли все в корзину. После неудачной первой попытки мы приостановили автоматизацию на какое-то время.
Позже, на других проектах, уже более осознанно подходили к этому вопросу и мои коллеги в статьях, на которые я давала ссылки выше, написали, как это делали.
Как шло распределение команд?
Команда была распределенной как по тестированию, так и по аналитике и разработке.
Основные коммуникации – проектных чаты в skype, telegram или slack. Команды были распределенными и по часовым поясам, но большая часть все-таки работали по Московскому времени. Вопрос часовых поясов был решен договоренностями. К примеру, многие с удовольствием соглашались работать по Московскому времени, а кто не мог, подключались по своему часовому поясу и часто это было удобно, кто-то готов был менять график работы со смещением во времени. Всегда решалось индивидуально и по договоренностям. Регулярное общение в чатах и регулярные созвоны, снимали все вопросы и не требовали наличия всей команды в офисе, сидящей спина к спине.
Распределение по функционалу делалось после проведения собеседования, учитывались опыт и навыки каждого тестировщика. Я не сторонник ставить на тестирование веб-сервисов тестировщика, который никогда не тестировал веб-сервисы, если только он сам не выразил желание изучить этот вид тестирования. Но, даже если он сам проявил инициативу, его обязательно прикрепляла к старшему тестировщику, который его обучал и передавал опыт и знания не только принципов тестирования веб-сервисов, но и погружал в бизнес процесс своей подсистемы. Желающим сменить подсистему предоставлялась такая возможность и принцип погружения был таким же. Сначала более опытный тестировщик передавал свои знания, затем по возможности проходило собеседование с аналитиком по подсистеме (это не обязательно, но если есть такая возможность, это прекрасно), когда все этапы погружения в новую область пройдены, менялась матрица знаний и тестировщик развивался на проекте, совершенствуя свои навыки в новой подсистеме.
Если рассматривать вопрос с точки зрения опыта тестировщиков, то на больших проектах, где команды более 15-20 человек и больше, старалась делить их на группы по 3-5-8 тестировщиков в группе, при этом, компетенции в каждой группе рекомендую делать сбалансированными. Под сбалансированностью компетенций подразумеваю следующее – 1 ведущий тестировщик, два старших, три младших (например для команды из 5 человек). Такое соотношение на мой взгляд, рабочее и эффективное.
Конечно бывали ситуации, когда подсистема была очень объемной по функционалу и часто дорабатываемой, в этом случае распределение компетенций могло отличаться в сторону усиления группы и увеличения ее численности.
На валидацию дефектов и погружение в проект, а также для наработки опыта, часто привлекались стажеры и как раз на такого рода задачах они очень быстро погружались в проект и вливались в команду, спустя 3-6 месяцев они уже становились младшими тестировщиками, полноценно участвовали в тестировании новых доработок.
Касаемо бюджета на тестирование.
Т.к. речь в статье в большей степени о ГИС, то после того, как выигран конкурс на разработку системы, бюджет тестирования заложен в контракт и он включает в себя определенные риски, в том числе, связанные с изменением законодательства или нормативной документации.
Острого недостатка в бюджете не было, но вопрос об оптимальности работы команды возникает всегда и мы стараемся совершенствоваться в процессе тестирования, чтобы не тратить впустую бюджет на ненужные телодвижения или неоптимальную работу, обычно это заслуга всей проектной команды.
На рабочих совещаниях обсуждаются планы всей проектной команды и тестирования в том числе. Если тестирование выбивается из сроков релиза, каждый случай обсуждаем и анализируем, вырабатываем оптимальный вариант решения ситуации, при необходимости меняем планы или объем работ, расширяем команду, если это возможно и целесообразно. Внедряем автоматизацию, естественно.
Постараюсь развернуто ответить на все ваши вопросы.
По поводу автоматизации:
В статье затронут пласт крупных проектов ГИС с 2009 по 2019 включительно.
В то время, когда мы начинали тестировать свой первый крупный ГИС — автоматизация была не развита, тестирование как отрасль была в самом зародыше.
Такого объема информации, как сейчас не было. Сроки были сильно сжатые и все тестировщики крутились, как могли. Нам было важно, хотя бы популярные браузеры покрыть smok-тестами.
Вопроса о выделении отдельной команды автоматизации в тот момент не стояло, т.к. не было представления как это организовать правильно, да еще и чтоб это работало эффективно.
В тот момент считали, что ручные функциональные тестировщики, участвовавшие в тесте плановых релизов и хот-фиксов, могут, хотят и должны одновременно каким-то чудом еще и автоматизировать. Но это было физически невозможно.
Конечно мы пытались все это делать одновременно, но итоги были печальные.
Первые затраты на автоматизацию были очень велики и пошли все в корзину. После неудачной первой попытки мы приостановили автоматизацию на какое-то время.
Позже, на других проектах, уже более осознанно подходили к этому вопросу и мои коллеги в статьях, на которые я давала ссылки выше, написали, как это делали.
Как шло распределение команд?
Команда была распределенной как по тестированию, так и по аналитике и разработке.
Основные коммуникации – проектных чаты в skype, telegram или slack. Команды были распределенными и по часовым поясам, но большая часть все-таки работали по Московскому времени. Вопрос часовых поясов был решен договоренностями. К примеру, многие с удовольствием соглашались работать по Московскому времени, а кто не мог, подключались по своему часовому поясу и часто это было удобно, кто-то готов был менять график работы со смещением во времени. Всегда решалось индивидуально и по договоренностям. Регулярное общение в чатах и регулярные созвоны, снимали все вопросы и не требовали наличия всей команды в офисе, сидящей спина к спине.
Распределение по функционалу делалось после проведения собеседования, учитывались опыт и навыки каждого тестировщика. Я не сторонник ставить на тестирование веб-сервисов тестировщика, который никогда не тестировал веб-сервисы, если только он сам не выразил желание изучить этот вид тестирования. Но, даже если он сам проявил инициативу, его обязательно прикрепляла к старшему тестировщику, который его обучал и передавал опыт и знания не только принципов тестирования веб-сервисов, но и погружал в бизнес процесс своей подсистемы. Желающим сменить подсистему предоставлялась такая возможность и принцип погружения был таким же. Сначала более опытный тестировщик передавал свои знания, затем по возможности проходило собеседование с аналитиком по подсистеме (это не обязательно, но если есть такая возможность, это прекрасно), когда все этапы погружения в новую область пройдены, менялась матрица знаний и тестировщик развивался на проекте, совершенствуя свои навыки в новой подсистеме.
Если рассматривать вопрос с точки зрения опыта тестировщиков, то на больших проектах, где команды более 15-20 человек и больше, старалась делить их на группы по 3-5-8 тестировщиков в группе, при этом, компетенции в каждой группе рекомендую делать сбалансированными. Под сбалансированностью компетенций подразумеваю следующее – 1 ведущий тестировщик, два старших, три младших (например для команды из 5 человек). Такое соотношение на мой взгляд, рабочее и эффективное.
Конечно бывали ситуации, когда подсистема была очень объемной по функционалу и часто дорабатываемой, в этом случае распределение компетенций могло отличаться в сторону усиления группы и увеличения ее численности.
На валидацию дефектов и погружение в проект, а также для наработки опыта, часто привлекались стажеры и как раз на такого рода задачах они очень быстро погружались в проект и вливались в команду, спустя 3-6 месяцев они уже становились младшими тестировщиками, полноценно участвовали в тестировании новых доработок.
Касаемо бюджета на тестирование.
Т.к. речь в статье в большей степени о ГИС, то после того, как выигран конкурс на разработку системы, бюджет тестирования заложен в контракт и он включает в себя определенные риски, в том числе, связанные с изменением законодательства или нормативной документации.
Острого недостатка в бюджете не было, но вопрос об оптимальности работы команды возникает всегда и мы стараемся совершенствоваться в процессе тестирования, чтобы не тратить впустую бюджет на ненужные телодвижения или неоптимальную работу, обычно это заслуга всей проектной команды.
На рабочих совещаниях обсуждаются планы всей проектной команды и тестирования в том числе. Если тестирование выбивается из сроков релиза, каждый случай обсуждаем и анализируем, вырабатываем оптимальный вариант решения ситуации, при необходимости меняем планы или объем работ, расширяем команду, если это возможно и целесообразно. Внедряем автоматизацию, естественно.
1. В России много разных ГИС. Правильно ли я понимаю, что в данном случае речь идёт прежде всего о ГИС ЖКХ?
2. Вы много пишете о том, как выбираете тесты с учётом изменений, вошедших в ту или иную версию. Разработчик поменял реализацию — вы переделываете свои тесты под новую реализацию. Не пытались ли Вы вместо этого исходить из той документации, которая доступна пользователям ГИС, больше думать об обратной совместимости, и от разработчиков тоже, по возможности, требовать сохранения обратной совместимости? Иначе говоря, я предлагаю в первую очередь сосредоточиться на тестировании стабильных/старых форматов обмена информацией, используемых пользователями ГИС. Если у вас, профессиональных тестеров, возникают проблемы с тем, чтобы подстроиться под очередную тестируемую версию, то представьте, каково реальным пользователям.
3. Пытаетесь ли вы прогонять сценарии тестирования, сформулированные в терминах реальной жизни? Ну, например, «От имени председателя ТСЖ „Берёзка“ разместить платёжные документы за очередной месяц. Расход ресурсов такой-то, тарифы такие-то».
4. Задействуете ли Вы в тестировании популярный сторонний софт, предназначенный для размещения информации в ГИС? Что делаете, если обнаруживается несовместимость этого софта с тестируемой версией ГИС?
5. Я заметил, что на главной странице недавно появилась информация о состоянии очереди обработки запросов. Следует ли из этого, что на производительность ГИС стали обращать больше внимания, и можно ожидать ускорения обработки размещаемой информации?
2. Вы много пишете о том, как выбираете тесты с учётом изменений, вошедших в ту или иную версию. Разработчик поменял реализацию — вы переделываете свои тесты под новую реализацию. Не пытались ли Вы вместо этого исходить из той документации, которая доступна пользователям ГИС, больше думать об обратной совместимости, и от разработчиков тоже, по возможности, требовать сохранения обратной совместимости? Иначе говоря, я предлагаю в первую очередь сосредоточиться на тестировании стабильных/старых форматов обмена информацией, используемых пользователями ГИС. Если у вас, профессиональных тестеров, возникают проблемы с тем, чтобы подстроиться под очередную тестируемую версию, то представьте, каково реальным пользователям.
3. Пытаетесь ли вы прогонять сценарии тестирования, сформулированные в терминах реальной жизни? Ну, например, «От имени председателя ТСЖ „Берёзка“ разместить платёжные документы за очередной месяц. Расход ресурсов такой-то, тарифы такие-то».
4. Задействуете ли Вы в тестировании популярный сторонний софт, предназначенный для размещения информации в ГИС? Что делаете, если обнаруживается несовместимость этого софта с тестируемой версией ГИС?
5. Я заметил, что на главной странице недавно появилась информация о состоянии очереди обработки запросов. Следует ли из этого, что на производительность ГИС стали обращать больше внимания, и можно ожидать ускорения обработки размещаемой информации?
Спасибо за вопросы.
Смогу ответить только на часть вопросов, и далее вы поймете почему.
Вопрос 1
Нет, вы поняли не правильно. Речь не про ГИС ЖКХ. Как писала в комментарии выше, речь идет о целом пласте проектов, создаваемых в нашем департаменте с 2009-2019 года. В первую очередь речь шла о самой первой ГИС и бОльшая часть проблем, относилась к системам 2009-2015 годов. Это НЕ ГИС ЖКХ. Однако, наработанные в те годы практики, грабли на которые мы наступали на своем пути при тестировании систем такого масштаба, были учтены, и лучшие практики применены и на проекте ГИС ЖКХ в том числе. Лично мое участие в ГИС ЖКХ тоже было, меня привлекали как эксперта для решения задач по оптимизации процесса тестирования на ГИС ЖКХ и улучшения качества тестирования. Мое участие в проекте было 2016-2017 годы, я выполнила поставленные задачи и далее переключилась на другие задачи департамента.
Вопрос 2.
Вижу, что основная ваша боль – ГИС ЖКХ, а в частности интеграция с этой системой. Я не в контексте текущих процессов на проекте ГИС ЖКХ, т.к. руководит тестированием мой коллега. Поэтому отвечать за то, как устроено интеграционное взаимодействие на проекте в данный момент, при этом не участвовать в проекте более 2 лет будет не правильно.
У нас есть отдельные статьи по ГИС ЖКХ на хабр, где вы можете задать вопрос, касаемый этой темы.
По поводу проблем, с которыми сталкиваются конечные пользователи при обновлении крупных ГИС, если вдруг серьезно изменился бизнес процесс или интерфейс.
Я прекрасно понимаю боль пользователей, т.к. сама не очень люблю перемены, особенно в интерфейсе, но это неизбежность, зачастую вызвана изменением законодательства или же переработкой интерфейса в рамках требований от Заказчика. Как правило это направлено на улучшение или вынужденные изменения (поменялись НПА или закон), никто заранее не ставит перед собой цель поиздеваться над пользователем. В статье я описывала проблемы на начальном этапе, когда мы только начинали разрабатывать ГИС (2009-2010 года), потом мы приняли ситуацию и научились оптимально с ней работать/жить. В рамках производственного процесса разработки программного обеспечения, проблема разрешилась, т.к. были найдены пути, как с этим работать.
Вопрос 3.
Да, всегда тестовые сценарии создаются в терминах той предметной области, для которой они разрабатываются. Вы снова приводите конкретный пример из ГИС ЖКХ :). Не могу точно сказать, используют ли коллеги в тест-кейсах ТСЖ «Березка», но точно могу сказать, что любые тест-кейсы мы составляем с учетом предметной области и ее особенностей.
Вопрос 4.
Простите, не совсем понимаю о каком софте вы спрашиваете, прошу уточнить ваш вопрос с примером.
Вопрос 5.
Из контекста, могу догадаться, что вопрос касается снова конкретной системы ГИС ЖКХ, который правильнее адресовать коллегам. Что касается производительности ГИС систем, то ответ да, всегда уделяется внимание производительности и проводится нагрузочное тестирование такого рода систем перед каждым релизом. Информацию о том, как технически устроен процесс автоматизации на наших проектах, можно также прочитать в недавних статьях моих коллег.
Смогу ответить только на часть вопросов, и далее вы поймете почему.
Вопрос 1
Нет, вы поняли не правильно. Речь не про ГИС ЖКХ. Как писала в комментарии выше, речь идет о целом пласте проектов, создаваемых в нашем департаменте с 2009-2019 года. В первую очередь речь шла о самой первой ГИС и бОльшая часть проблем, относилась к системам 2009-2015 годов. Это НЕ ГИС ЖКХ. Однако, наработанные в те годы практики, грабли на которые мы наступали на своем пути при тестировании систем такого масштаба, были учтены, и лучшие практики применены и на проекте ГИС ЖКХ в том числе. Лично мое участие в ГИС ЖКХ тоже было, меня привлекали как эксперта для решения задач по оптимизации процесса тестирования на ГИС ЖКХ и улучшения качества тестирования. Мое участие в проекте было 2016-2017 годы, я выполнила поставленные задачи и далее переключилась на другие задачи департамента.
Вопрос 2.
Вижу, что основная ваша боль – ГИС ЖКХ, а в частности интеграция с этой системой. Я не в контексте текущих процессов на проекте ГИС ЖКХ, т.к. руководит тестированием мой коллега. Поэтому отвечать за то, как устроено интеграционное взаимодействие на проекте в данный момент, при этом не участвовать в проекте более 2 лет будет не правильно.
У нас есть отдельные статьи по ГИС ЖКХ на хабр, где вы можете задать вопрос, касаемый этой темы.
По поводу проблем, с которыми сталкиваются конечные пользователи при обновлении крупных ГИС, если вдруг серьезно изменился бизнес процесс или интерфейс.
Я прекрасно понимаю боль пользователей, т.к. сама не очень люблю перемены, особенно в интерфейсе, но это неизбежность, зачастую вызвана изменением законодательства или же переработкой интерфейса в рамках требований от Заказчика. Как правило это направлено на улучшение или вынужденные изменения (поменялись НПА или закон), никто заранее не ставит перед собой цель поиздеваться над пользователем. В статье я описывала проблемы на начальном этапе, когда мы только начинали разрабатывать ГИС (2009-2010 года), потом мы приняли ситуацию и научились оптимально с ней работать/жить. В рамках производственного процесса разработки программного обеспечения, проблема разрешилась, т.к. были найдены пути, как с этим работать.
Вопрос 3.
Да, всегда тестовые сценарии создаются в терминах той предметной области, для которой они разрабатываются. Вы снова приводите конкретный пример из ГИС ЖКХ :). Не могу точно сказать, используют ли коллеги в тест-кейсах ТСЖ «Березка», но точно могу сказать, что любые тест-кейсы мы составляем с учетом предметной области и ее особенностей.
Вопрос 4.
Простите, не совсем понимаю о каком софте вы спрашиваете, прошу уточнить ваш вопрос с примером.
Вопрос 5.
Из контекста, могу догадаться, что вопрос касается снова конкретной системы ГИС ЖКХ, который правильнее адресовать коллегам. Что касается производительности ГИС систем, то ответ да, всегда уделяется внимание производительности и проводится нагрузочное тестирование такого рода систем перед каждым релизом. Информацию о том, как технически устроен процесс автоматизации на наших проектах, можно также прочитать в недавних статьях моих коллег.
Спасибо за ответ. За внедрением ГИС ЖКХ я наблюдаю со стороны, поскольку интересуюсь темой ЖКХ вообще. При этом я слышу множество нареканий, и как разработчику ПО, мне интересно было бы разобраться в причинах их возникновения.
Я понял, что Вы отошли от проекта ГИС ЖКХ, но всё-таки попробую уточнить/дополнить вопросы в надежде на то, что Вы или кто-то из Ваших коллег сможет ответить.
2. Я понимаю, что сохранить обратную совместимость во всех случаях невозможно. Законодательство требует предоставлять новые данные, ГИС перестаёт принимать форматы, не содержащие этих данных. Однако в некоторых случаях речь идёт о внесении косметических изменений. Новый формат данных может быть чем-то лучше, содержать какие-то дополнительные поля, но при этом и старый формат вполне можно было бы продолжать обрабатывать. Судя по жалобам, которые я слышу, с этим часто бывают проблемы. В чём дело?
4. Любая ГИС существует не в вакууме. Поставщики данных пользуются разнообразным софтом для размещения данных. Это и какие-то конфигурации 1С, и софт, используемый в чужих информационных системах, и даже весь зоопарк версий MS Excel и OpenOffice/LibreOffice. Приведу в пример Microsoft: они не стесняются запускать на Windows в процессе тестирования самое разнообразное _чужое_ ПО и следить за сохранением совместимости. Они не стесняются уведомлять сторонних разработчиков о проблемах в их ПО, если проблема приводит к несовместимости с новой версией. Пытается ли Ланит делать что-то подобное? Открыты ли для сторонних разработчиков стенды, на которых установлена не текущая версия ГИС, а бета следующей версии?
Я понял, что Вы отошли от проекта ГИС ЖКХ, но всё-таки попробую уточнить/дополнить вопросы в надежде на то, что Вы или кто-то из Ваших коллег сможет ответить.
2. Я понимаю, что сохранить обратную совместимость во всех случаях невозможно. Законодательство требует предоставлять новые данные, ГИС перестаёт принимать форматы, не содержащие этих данных. Однако в некоторых случаях речь идёт о внесении косметических изменений. Новый формат данных может быть чем-то лучше, содержать какие-то дополнительные поля, но при этом и старый формат вполне можно было бы продолжать обрабатывать. Судя по жалобам, которые я слышу, с этим часто бывают проблемы. В чём дело?
4. Любая ГИС существует не в вакууме. Поставщики данных пользуются разнообразным софтом для размещения данных. Это и какие-то конфигурации 1С, и софт, используемый в чужих информационных системах, и даже весь зоопарк версий MS Excel и OpenOffice/LibreOffice. Приведу в пример Microsoft: они не стесняются запускать на Windows в процессе тестирования самое разнообразное _чужое_ ПО и следить за сохранением совместимости. Они не стесняются уведомлять сторонних разработчиков о проблемах в их ПО, если проблема приводит к несовместимости с новой версией. Пытается ли Ланит делать что-то подобное? Открыты ли для сторонних разработчиков стенды, на которых установлена не текущая версия ГИС, а бета следующей версии?
Добрый день, Сергей!
Во-первых спасибо за проявленный к теме интерес.
Во-вторых рад, что далеко не всем безразлична судьба отечественного ПО)
Что касается Ваших вопросов.
Безусловно мы стараемся поддерживать обратную совместимость как можно дольше. К сожалению, по объективным причинам (как вы верно отметили) это не всегда возможно. К тому же заблаговременно на портале в информационном разделе выкладываются перспективные форматы взаимодействия. Тем не менее все жалобы, если они поступают разбираются экспертами тех. поддержки и пользователям направляются квалифицированные ответы.
Что касается второго вопроса, могу вас заверить, что все пожелавшие этого разработчики ПО для интеграции в полной мере обеспечены стендами с текущей и перспективной версией приложения для отладки своего ПО.
Во-первых спасибо за проявленный к теме интерес.
Во-вторых рад, что далеко не всем безразлична судьба отечественного ПО)
Что касается Ваших вопросов.
Безусловно мы стараемся поддерживать обратную совместимость как можно дольше. К сожалению, по объективным причинам (как вы верно отметили) это не всегда возможно. К тому же заблаговременно на портале в информационном разделе выкладываются перспективные форматы взаимодействия. Тем не менее все жалобы, если они поступают разбираются экспертами тех. поддержки и пользователям направляются квалифицированные ответы.
Что касается второго вопроса, могу вас заверить, что все пожелавшие этого разработчики ПО для интеграции в полной мере обеспечены стендами с текущей и перспективной версией приложения для отладки своего ПО.
С удивлением узнал, что у Ланита есть тестировщики как класс. Являюсь пользователем одной из ГИС — ГИС ЖКХ и могу сказать, что судя по количеству ошибок, возникающих после каждой новой версии был уверен, что тестировщиками считают нас, простых пользователей.
Рады, что смогли вернуть Вам веру во все доброе и светлое) К сожалению не могу согласиться с таким огульным заявлением. Так что если есть конкретная фактура — приносите через форму связи с поддержкой, обязательно все разберут и ответят.
Спасибо, я отправлял невообразимое количество раз, собственно в связи с чем и вызвано такое «огульное» заявление.
Я могу понять когда какой-то функционал не реализован, могу понять когда он криво реализован (этого всего в достатке в ГИС ЖКХ, но речь не об этом), но когда какой-то функционал в прошлой в версии был, а в новой его сломали и так случается буквально после каждого релиза, то да, появляются сомнения в наличии тестировщиков, ощущение, что вывалили релиз и ждут когда «приносите через форму связи...»
Еще одно сомнение возникает из-за того, что при любом запросе через форму связи, знаете какой получаем ответ — пришлите скрин, подтверждающий ошибку. То есть опять же понятно, что нет тестировщиков с ролью УК, которые могли бы воспроизвести ее самостоятельно.
Я могу понять когда какой-то функционал не реализован, могу понять когда он криво реализован (этого всего в достатке в ГИС ЖКХ, но речь не об этом), но когда какой-то функционал в прошлой в версии был, а в новой его сломали и так случается буквально после каждого релиза, то да, появляются сомнения в наличии тестировщиков, ощущение, что вывалили релиз и ждут когда «приносите через форму связи...»
Еще одно сомнение возникает из-за того, что при любом запросе через форму связи, знаете какой получаем ответ — пришлите скрин, подтверждающий ошибку. То есть опять же понятно, что нет тестировщиков с ролью УК, которые могли бы воспроизвести ее самостоятельно.
К сожалению такая дискуссия ведет в никуда.
Можете прислать мне в ЛС номера Ваших обращений и мы посмотрим их судьбу.
По поводу второго пункта, сожалею, если запрос скриншота вызывает у Вас такую реакцию. Однако, если вы имеете отношение к разработке ПО, то должны понимать, что:
1) пруфы нужны нужны всегда, чтобы оценить наличие ошибки
2) тем, кто принимает Ваше обращение нужно убедиться что вы заходите туда, куда вы описываете в вашем обращении и делаете именно то, что вы описываете (была бы моя воля, я бы еще и видео заставлял прикладывать).
3) тестировщики не имеют никакого доступа к промышленному контуру, кроме открытой его части, либо как граждане, но уж точно не как УК))
4) точное и детальное описание Вашей «ошибки» помогут воспроизвести вашу ситуацию на тестовой среде, а нежелание предоставлять эту информацию не приводит ни к чему, если ошибка не очевидна или сложновоспроизводима (надеюсь, вы представляете все многобразие сочетаний пользовательских данных и действий пользователя на портале таких размеров).
Можете прислать мне в ЛС номера Ваших обращений и мы посмотрим их судьбу.
По поводу второго пункта, сожалею, если запрос скриншота вызывает у Вас такую реакцию. Однако, если вы имеете отношение к разработке ПО, то должны понимать, что:
1) пруфы нужны нужны всегда, чтобы оценить наличие ошибки
2) тем, кто принимает Ваше обращение нужно убедиться что вы заходите туда, куда вы описываете в вашем обращении и делаете именно то, что вы описываете (была бы моя воля, я бы еще и видео заставлял прикладывать).
3) тестировщики не имеют никакого доступа к промышленному контуру, кроме открытой его части, либо как граждане, но уж точно не как УК))
4) точное и детальное описание Вашей «ошибки» помогут воспроизвести вашу ситуацию на тестовой среде, а нежелание предоставлять эту информацию не приводит ни к чему, если ошибка не очевидна или сложновоспроизводима (надеюсь, вы представляете все многобразие сочетаний пользовательских данных и действий пользователя на портале таких размеров).
> тестировщики не имеют никакого доступа к промышленному контуру
А техподдержка? Ну или хоть кто-нибудь из технарей?
Просто техподдержка, не имеющая доступа к тому, что она должна поддерживать — это ерунда какая-то. Так работать — всё равно что оперировать вслепую.
А техподдержка? Ну или хоть кто-нибудь из технарей?
Просто техподдержка, не имеющая доступа к тому, что она должна поддерживать — это ерунда какая-то. Так работать — всё равно что оперировать вслепую.
Конечно же есть главный админ, у которого все ваши пароли хранятся (это сарказм).
Мы начинаем вдаваться в темы, в которые вдаваться не стоит в рамках открытой дискуссии))
А Вы зря иронизируете, и вопросы от этого не исчезнут. Когда я прихожу в банк, у девушки-операционистки тоже нет моего пароля. Тем не менее, она может на какие-то вопросы ответить самостоятельно, а какие-то может эскалировать наверх. Также она может совершить любую операцию от моего имени на основании бумажного заявления.
Вот недавно* у знакомой ситуация была: исчезли деньги со счёта. Были — и нет. И операций никаких в интернет-банке не видно. Но она точно помнит, что денег было много, а стало мало. Ничего, разобрались, хоть и не сразу. Оказывается, ей когда-то ошибочно перевели деньги на счёт по запросу какого-то пристава, и она этого не заметила. А потом ошибка выяснилась, операцию отменили, а в банковской выписке это было не видно.
А по одним скриншотам — точно не разобрались бы.
Вот недавно* у знакомой ситуация была: исчезли деньги со счёта. Были — и нет. И операций никаких в интернет-банке не видно. Но она точно помнит, что денег было много, а стало мало. Ничего, разобрались, хоть и не сразу. Оказывается, ей когда-то ошибочно перевели деньги на счёт по запросу какого-то пристава, и она этого не заметила. А потом ошибка выяснилась, операцию отменили, а в банковской выписке это было не видно.
А по одним скриншотам — точно не разобрались бы.
А у меня тоже ситуация в одном самом большом банке была, положил деньги через банкомат, а они пропали и из всех данных только смс об отмене зачисления. И никто ничего не нашел ни с логином, ни с паролем, ни с бумажкой, ни без) Я вам объясняю, что отвечать на вопросы касающиеся безопасности я не буду) Провоцировать смысла нет. Вы можете направить оператору портала официальный запрос, у кого и к чему есть допуск. Ответят, значит ответят. Я могу говорить лишь за команду тестирования. У команды тестирования доступа к учеткам и данным пользователей — нет.)
Но она точно помнит, что денег было много, а стало мало. Ничего, разобрались, хоть и не сразу. Оказывается, ей когда-то ошибочно перевели деньги на счёт по запросу какого-то пристава, и она этого не заметила. А потом ошибка выяснилась, операцию отменили, а в банковской выписке это было не видно.забавно что когда внезапно денег стало много, она вопросов задавать не стала))) а вот когда вернулось все на место возникли вопросы.
А по одним скриншотам — точно не разобрались бы.
К сожалению такая дискуссия ведет в никуда.дискуссия действительно ведет в никуда. Я вам говорю о причине, Вы мне о следствии.
Можете прислать мне в ЛС номера Ваших обращений и мы посмотрим их судьбу.
Если бы был нормально организован процесс тестирования, то не было бы никаких обращений.
А обращения да, были решены, не сразу, нудно, со скринами, записью видео, «мамой клянусь, это в ГИСе ошибка, а не я тупой». Про работу техподдержки речи нет, она конечно ужасна, но если бы не ужасное тестирование, не было бы ошибок и не было бы ужасной техподдержки.
По поводу второго пункта, сожалею, если запрос скриншота вызывает у Вас такую реакцию. Однако, если вы имеете отношение к разработке ПО, то должны понимать, что:
1) пруфы нужны нужны всегда, чтобы оценить наличие ошибки
2) тем, кто принимает Ваше обращение нужно убедиться что вы заходите туда, куда вы описываете в вашем обращении и делаете именно то, что вы описываете (была бы моя воля, я бы еще и видео заставлял прикладывать).
3) тестировщики не имеют никакого доступа к промышленному контуру, кроме открытой его части, либо как граждане, но уж точно не как УК))
4) точное и детальное описание Вашей «ошибки» помогут воспроизвести вашу ситуацию на тестовой среде, а нежелание предоставлять эту информацию не приводит ни к чему, если ошибка не очевидна или сложновоспроизводима (надеюсь, вы представляете все многобразие сочетаний пользовательских данных и действий пользователя на портале таких размеров).
можно, конечно, ответить в Вашем стиле, но я сторонник более кратких и точных ответов.
Надеюсь Вы представляете, что ГИСы от Ланита не единственные сложные системы в интернете. Так вот, я, соответственно, тоже пользуюсь не только данными порталами и могу сказать, что такого количества ошибок и запроса скринов, видео нет ни в одной системе.
Безусловно, можно найти этому множество правдоподобных объяснений, но факт остается фактом.
Вы немного ушли от тематики статьи в плоскость обсуждения особенностей технической поддержки конкретного проекта.
Давайте попробуем вернуться в плоскость обсуждение особенностей производственного процесса тестирования ГИС.
Ответ на ваш вопрос про техподдержку ГИС
(я сознательно пишу про любые ГИС, а НЕ КОНКРЕТНО ПРО ГИС ЖКХ).
Конечно над поддержкой ГИС работают специалисты разного уровня доступа к промышленному контуру. Такие специалисты есть как в технической поддержке, так и в производственной команде. Проверять что-то непосредственно на промышленном контуре для локализации инцидента в большинстве случаев нет необходимости, т.к. всегда развернут тестовый контур, копия промышленного, где установлена такая же версия системы, для возможности воспроизведения инцидентов, поступающих на третью линию поддержки.
Ваша задача, как пользователя, предоставить максимально точно информацию по выполняемым действиям, приводящим к инциденту, в том числе снять скриншоты. Для вас это могут быть совершенно рядовые действия, но при этом в профиле заполнены какие-то данные или не заполнены, которые в сочетании с вашими действиями приводят к возникновению инцидента. Только в этом случае у специалистов увеличивается шанс, воспроизвести, проанализировать причины, передать в разработку на исправление.
Давайте попробуем вернуться в плоскость обсуждение особенностей производственного процесса тестирования ГИС.
Ответ на ваш вопрос про техподдержку ГИС
(я сознательно пишу про любые ГИС, а НЕ КОНКРЕТНО ПРО ГИС ЖКХ).
Конечно над поддержкой ГИС работают специалисты разного уровня доступа к промышленному контуру. Такие специалисты есть как в технической поддержке, так и в производственной команде. Проверять что-то непосредственно на промышленном контуре для локализации инцидента в большинстве случаев нет необходимости, т.к. всегда развернут тестовый контур, копия промышленного, где установлена такая же версия системы, для возможности воспроизведения инцидентов, поступающих на третью линию поддержки.
Ваша задача, как пользователя, предоставить максимально точно информацию по выполняемым действиям, приводящим к инциденту, в том числе снять скриншоты. Для вас это могут быть совершенно рядовые действия, но при этом в профиле заполнены какие-то данные или не заполнены, которые в сочетании с вашими действиями приводят к возникновению инцидента. Только в этом случае у специалистов увеличивается шанс, воспроизвести, проанализировать причины, передать в разработку на исправление.
Мне искренне жаль, что вы сталкиваетесь с ошибками на одном конкретном проекте, при этом, к сожалению, вы не готовы озвучить ваши текущие открытые инциденты, мешающие работе с порталом, чтоб мы посмотрели, чем можем вам помочь. Мы стараемся совершенствовать наши навыки тестирования и оптимизируем производственный процесс, чтобы сократить такие моменты и выпускать новые релизы лучше, предыдущих. Именно это я пыталась отразить в статье — как мы измеряем качество, какие метрики используем, как это отслеживаем. Если я не до конца раскрыла вопрос с метриками качества, задайте, пожалуйста ваши вопросы по этой теме статьи, постараюсь вам развернуто ответить.
Вы просто поймите — для Вас это красивая история, правильные слова и вот это вот все, а для меня, как конечного пользователя, с ужасом ждущего нового релиза, за которым последует сотня скринов, доказательства что я не верблюд и через месяц исправление ошибок это выгляди неким издевательством.
Чтобы проверить что ошибка не на стороне пользователя от меня требуют скрины и видео, а чтобы выкатить плохо протестированный релиз не нужно ничего и в итоге можно еще написать гордый мануал, как мы работаем.
Чтобы проверить что ошибка не на стороне пользователя от меня требуют скрины и видео, а чтобы выкатить плохо протестированный релиз не нужно ничего и в итоге можно еще написать гордый мануал, как мы работаем.
Я бы вам рекомендовала принять ситуацию по требованиям от технической поддержки любой крупной системы, а именно детально заполнить форму обратной связи, приложить скриншоты и т.д., если цель вашего обращения в техподдержку — исправление возникшего инцидента. Только детальное описание инцидента поможет с его скорейшим решением.
А я бы Вам рекомендовал все же ответственнее подходить к тестированию, тогда и не нужно будет никаких скринов прикладывать.
Вы упорно не хотите замечать основную мысль, которую я пытаюсь донести с минимумом текста. Я понимаю, что в крупных системах возможны ошибки, я понимаю, что нельзя писать обращение вида «почему у меня все не работает, срочно почините» и я не пишу такие обращения, я понимаю что на устранение ошибок нужно время. Это очевидные истины, с которыми сталкиваешься каждый день.
По сути единственное исключение в этом это ГИС ЖКХ. Такого количества проблем из-за новых релизов сложно себе даже вообразить, если не сталкиваться с работой ГИС ЖКХ.
Раз уж не получается коротко, попробую по Вашему примеру писать много букв и приведу в пример, стороннего программиста 1С, который нам настраивает 1С, отчеты, выгрузки, в том числе и для ГИС ЖКХ. До того, как он столкнулся лично с ГИС он был примерно на Ваших позициях (как я скорее всего, если бы слышал о проблемах со слов). Но сейчас, когда мы его озадачили максимальной автоматизацией процессов выгрузки из 1С в ГИС и регулярной подстройкой ее после новых релизов, боюсь уже мои оценки работы ГИС ЖКХ более сдержанны, чем его.
Вы упорно не хотите замечать основную мысль, которую я пытаюсь донести с минимумом текста. Я понимаю, что в крупных системах возможны ошибки, я понимаю, что нельзя писать обращение вида «почему у меня все не работает, срочно почините» и я не пишу такие обращения, я понимаю что на устранение ошибок нужно время. Это очевидные истины, с которыми сталкиваешься каждый день.
По сути единственное исключение в этом это ГИС ЖКХ. Такого количества проблем из-за новых релизов сложно себе даже вообразить, если не сталкиваться с работой ГИС ЖКХ.
Раз уж не получается коротко, попробую по Вашему примеру писать много букв и приведу в пример, стороннего программиста 1С, который нам настраивает 1С, отчеты, выгрузки, в том числе и для ГИС ЖКХ. До того, как он столкнулся лично с ГИС он был примерно на Ваших позициях (как я скорее всего, если бы слышал о проблемах со слов). Но сейчас, когда мы его озадачили максимальной автоматизацией процессов выгрузки из 1С в ГИС и регулярной подстройкой ее после новых релизов, боюсь уже мои оценки работы ГИС ЖКХ более сдержанны, чем его.
Пока не видел ни краткости, ни точности, уж простите.
Тем более не привык обсуждать системы других компаний в их отсутствии.
Вообще складывается ощущение, что пришли похайповать.
Извините, потратил все отведенное время на комментарии.
Тем более не привык обсуждать системы других компаний в их отсутствии.
Вообще складывается ощущение, что пришли похайповать.
Извините, потратил все отведенное время на комментарии.
> и могу сказать, что такого количества ошибок и запроса скринов, видео нет ни в одной системе.
Я больше скажу. Единственная цель запроса скринов — это переброска мяча на вашу сторону, в надежде, что у вас руки не дойдут сделать скрин и проблему можно будет закрыть. Скрины запрашивают даже тогда, когда их прикладываешь в исходном обращении.
Я больше скажу. Единственная цель запроса скринов — это переброска мяча на вашу сторону, в надежде, что у вас руки не дойдут сделать скрин и проблему можно будет закрыть. Скрины запрашивают даже тогда, когда их прикладываешь в исходном обращении.
Я понимаю и так это и было.
В начале так вообще до смеха было. Срок ответа — 6 дней и вот на 6 день и запрашивают скрин, при этом срок ожидания, уж не помню, но точно меньше, чтобы да, не успел.
И запрос скрина это не худшее, бывало я получал в ответ на запрос просто кусок левого мануала, не имеющего отношения к теме запроса, просто чтобы успеть в 6 дней, перекинуть мяч на мою сторону.
Но тема статьи не техподдержка и увы, здесь это будет оффтоп. Тем более, как видно из переписки, сотрудники Ланита используют все методы, чтобы отклонить конкретные претензии и просто рассматривать сферическую статью в вакууме.
Давайте попробуем вернуться в плоскость обсуждение особенностей производственного процесса тестирования ГИС.возможно я старомоден, но всегда придерживался логики, что нужно обсуждать причины, а не следствия.
В данном случае, ничего не имея лично против автора, я считаю что нет смысла обсуждать статью результатом которой является такое качество тестирования, что складывается впечатление что его нет. Поэтому логично сначала наладить процесс, а потом уже описывать его.
Вы не очень внимательно читали статью.
Речь про то как мы налаживали производственный процесс тестирования крупных систем в период времени с 2009-2019 года.
Речь не идет про конкретный проект ГИС ЖКХ. Я НЕ ОПИСЫВАЮ процесс тестирования ГИС ЖКХ.
В статье указан базис по тестированию такого рода систем, основные моменты, на которые стоит обращать внимание и как мы до них дошли методом проб, ошибок, обучения, консультаций с другими специалистами из области тестирования.
Если вы считаете, что этот базис не верный, не рабочий, не оптимальный и т.д., я буду благодарна, если вы поделитесь Вашим удачным опытом построения процесса тестирования такого рода систем.
Мы готовы учиться и развиваться.
Речь про то как мы налаживали производственный процесс тестирования крупных систем в период времени с 2009-2019 года.
Речь не идет про конкретный проект ГИС ЖКХ. Я НЕ ОПИСЫВАЮ процесс тестирования ГИС ЖКХ.
В статье указан базис по тестированию такого рода систем, основные моменты, на которые стоит обращать внимание и как мы до них дошли методом проб, ошибок, обучения, консультаций с другими специалистами из области тестирования.
Если вы считаете, что этот базис не верный, не рабочий, не оптимальный и т.д., я буду благодарна, если вы поделитесь Вашим удачным опытом построения процесса тестирования такого рода систем.
Мы готовы учиться и развиваться.
Если вы считаете, что этот базис не верный, не рабочий, не оптимальныйименно так, про 2009 не скажу, но осенью 2019 был релиз который наглухо похоронил одну ежемесячную функцию в ГИС ЖКХ (не будем углубляться, но если интересно я могу и подробнее). Функция работала с самого запуска ГИС ЖКХ, на исправление ушло 2 месяца, за это время мы получили сотни обращений от жителей, кучу претензий от надзорных органов. Да, мы все пояснили, нашей вины не было, но на это ушла уйма рабочего времени и виной всему низкое качество тестирования. Если Вы шли к такому уровню 10 лет, то у меня для Вас плохие новости.
вы поделитесь Вашим удачным опытом построения процесса тестирования такого рода системмогу только поделиться удачным опытом построение таких систем со стороны заказчика. Я одно время руководил проектом, где был подрядчик, который должен был выполнить работу по построению чуть более простой системы. Начало было аналогичным — вот система, вот глюки, вот наши тестировщики, а вот наша гордость — методология тестировщиков, мы шли к этому очень долго, безусловно система несовершенна, но мы будем работать и нам искренне жаль за каждую ошибку. После 2 месяцев таких разговоров я сказал что, поддерживаю их стремление к совершенству, но пока количество ошибок радикально не будет снижено, я отказываюсь подписывать акты выполненных работ и оплат больше не будет.
К сожалению, я не присутствовал на дальнейших внутренних планерках подрядчика, хотя уверен, об этом можно было бы писать не мануал, а снимать полноценное кино, но результат в итоге был, правда, про методологию тестировщиков я больше не слышал.
Возможно, Вам будет полезен данный опыт.
После любого релиза крупной ГИС проводится технический анализ, в том числе исследуются негативные факторы обновления ГИС, повлекшие ошибки на продуктиве.
Уверена, что мои коллеги такой анализ проводили, сделали выводы и самое главное поняли допущенные ошибки (если они имели место быть со стороны тестирования) с целью проведения мер, направленных на недопущение подобных ситуаций в следующем релизе. Разработка таких систем — это командная работа, даже если причина ошибок была не в тестировании, а в аналитике или неверной установке на продуктив и т.д., анализ проводится в комплексе, меры недопущения подобных ситуаций касаются всей проектной команды.
Мне жаль, что тот осенний релиз 2019 года доставил вам столько неудобств.
Касаемо Вашего опыта, когда вы выступали со стороны Заказчика.
Наши Заказчики также не подписывают акты о выполненных работах и не проводят оплату, если мы не смогли пройти приёмочном-сдаточные испытания по этапу работ в рамках наших контрактных обязательств.
Со своими подрядчиками, в рамках наших контрактных обязательств, мы также обсуждаем ситуации, проводим совместные работы по изменению/улучшению процессов, с целью выпускать более качественные релизы. Если договорными отношениями допускаются штрафы за некачественно выполненные работы, то в подрядчиков можем и оштрафовать.
Что касаемо внутренних сотрудников, работающих на проектах, у всех есть KPI и работа каждого тестировщика оценивается со стороны Тест-менеджера команды на предмет его достижения или не достижения поставленных KPI, собирается обратная связь внутри рабочей группы, оценивается эффективность сотрудников и при необходимости принимаем разного рода меры, направленные на рост сотрудников, их обучение и как следствие улучшения качества работы, которое, в свою очередь приводит к улучшению качества тестирования. Естественно не всегда мы достигаем успеха, как и в любой сфере, но мы к этому стремимся.
Уверена, что мои коллеги такой анализ проводили, сделали выводы и самое главное поняли допущенные ошибки (если они имели место быть со стороны тестирования) с целью проведения мер, направленных на недопущение подобных ситуаций в следующем релизе. Разработка таких систем — это командная работа, даже если причина ошибок была не в тестировании, а в аналитике или неверной установке на продуктив и т.д., анализ проводится в комплексе, меры недопущения подобных ситуаций касаются всей проектной команды.
Мне жаль, что тот осенний релиз 2019 года доставил вам столько неудобств.
Касаемо Вашего опыта, когда вы выступали со стороны Заказчика.
Наши Заказчики также не подписывают акты о выполненных работах и не проводят оплату, если мы не смогли пройти приёмочном-сдаточные испытания по этапу работ в рамках наших контрактных обязательств.
Со своими подрядчиками, в рамках наших контрактных обязательств, мы также обсуждаем ситуации, проводим совместные работы по изменению/улучшению процессов, с целью выпускать более качественные релизы. Если договорными отношениями допускаются штрафы за некачественно выполненные работы, то в подрядчиков можем и оштрафовать.
Что касаемо внутренних сотрудников, работающих на проектах, у всех есть KPI и работа каждого тестировщика оценивается со стороны Тест-менеджера команды на предмет его достижения или не достижения поставленных KPI, собирается обратная связь внутри рабочей группы, оценивается эффективность сотрудников и при необходимости принимаем разного рода меры, направленные на рост сотрудников, их обучение и как следствие улучшения качества работы, которое, в свою очередь приводит к улучшению качества тестирования. Естественно не всегда мы достигаем успеха, как и в любой сфере, но мы к этому стремимся.
Мне жаль, что тот осенний релиз 2019 года доставил вам столько неудобств.вот мне интересно, если попробовать воплотить Ваши принципы общения в реальный мир, например, той же коммуналки, где я работаю. Вот начала подтекать скажем, труба, Вы вызываете сантехника, он ее якобы чинит, получает деньги, уходит, Вы включаете воду и получаете 3 см кипятка ровным слоем на полу, звоните в УК и слышите «Мне жаль что наш
Как считаете, какой будет Ваша реакция?
Буду ругаться конечно, но приму ситуацию и найду другого сантехника.
И в ситуации с сантехником… мне придется принять ее, устранить проблемы в квартире за свой счет, к сожалению, т.к. вероятность что мне ее устранит УК не велика, если нет страховки… и… жить дальше, но это уже совсем другая история… Никак не могу понять, как она может быть связана с тем, как техникум к примеру, обучает слесарей сантехников и что в итоге из них получается на выходе…
Это я вас пытаюсь вернуть к тематике статьи, т.к. цель статьи показать тест менеджерам наши ошибки, пути их устранения, дать рекомендации к процессу тестирования на крупных системах, которые помогут в их работе, а также приведено много полезных документов и методик расчёта, которыми можно пользоваться.
Давайте все таки оставим тему ГИС ЖКХ, т.к. прямого отношения осенний релиз на том проекте, к моей статье не имеет.
А я не имею никакого отношения к управлению тестированием на проекте ГИС ЖКХ и кроме передачи коллегам просьбы принять меры и устранить последствия, ничем помочь больше не могу.
И в ситуации с сантехником… мне придется принять ее, устранить проблемы в квартире за свой счет, к сожалению, т.к. вероятность что мне ее устранит УК не велика, если нет страховки… и… жить дальше, но это уже совсем другая история… Никак не могу понять, как она может быть связана с тем, как техникум к примеру, обучает слесарей сантехников и что в итоге из них получается на выходе…
Это я вас пытаюсь вернуть к тематике статьи, т.к. цель статьи показать тест менеджерам наши ошибки, пути их устранения, дать рекомендации к процессу тестирования на крупных системах, которые помогут в их работе, а также приведено много полезных документов и методик расчёта, которыми можно пользоваться.
Давайте все таки оставим тему ГИС ЖКХ, т.к. прямого отношения осенний релиз на том проекте, к моей статье не имеет.
А я не имею никакого отношения к управлению тестированием на проекте ГИС ЖКХ и кроме передачи коллегам просьбы принять меры и устранить последствия, ничем помочь больше не могу.
Никак не могу понять, как она может быть связана с тем, как техникум к примеру, обучает слесарей сантехников
Все очень просто. С УК есть все шансы получить возмещение если по вине ее сантехника будет залитие и поэтому в УК подходят более ответственно и к обучению и к тестированию. Поэтому у УК не уходит по 10 лет на разработку системы тестированию по итогам применения которой выпускаются релизы, за которое безмерно жаль… При этом, да в УК не пишется таких подробных и красивых статей «как научить сантехника с одного раза чинить протечку», хотя опыт имеется.
А я не имею никакого отношения к управлению тестированием на проекте ГИС ЖКХа какие ГИС Вы тестируете? Возможно я счастливый пользователь и просто не знаю этого?
К сожалению, не имею право отвечать на вопросы такого рода, NDA.
В статье не сказано, что на разработку системы тестирования ушло 10 лет ), мы не разрабатывали такие системы…
В статье опыт тестирования первой крупной системы, проблемы с которыми столкнулись, как их решали и рекомендации тем, кто быть может сейчас с такими же проблемами сталкивается и сможет вынести что-то полезное из нашего опыта, применить наши практики в своей работе.
В статье не сказано, что на разработку системы тестирования ушло 10 лет ), мы не разрабатывали такие системы…
В статье опыт тестирования первой крупной системы, проблемы с которыми столкнулись, как их решали и рекомендации тем, кто быть может сейчас с такими же проблемами сталкивается и сможет вынести что-то полезное из нашего опыта, применить наши практики в своей работе.
К сожалению, не имею право отвечать на вопросы такого рода, NDA.Я, кстати, пока не встретил этот хаб искренне считал что Ланит нигде и не будет афишировать свою причастность к ГИСам, ибо гордится там не чем, если честно.
Теперь я понял какой нашли выход — без конкретных ГИС. Нет конкретики, нет конкретных претензий, всегда можно уйти в сторону.
Причастность к ГИСам публикуется в открытом доступе, если был конкурс. Проблемы с системой конкретные надо все таки адресовать в техническую поддержку, это пожалуй единственный способ исправить ваш инцидент, но точно не на Хабр.
Вы упорно меня не слышите. Дело не в конкретной проблеме, а в массовом возникновении проблем послы выхода очередного релиза. Безусловно, можно их решить через техподдержку, постфактум, но можно и решить источник проблемы — наладить тестирование и предотвратить выпуск сырых релизов.
Хабр не я выбирал как площадку.
Просто раз Ваша компания пишет здесь, я решил, что ведь не ради только ради пиара и принятия похвалы, но и в том числе для получения конструктивной критики.
> Буду ругаться конечно, но приму ситуацию и найду другого сантехника.
Вы не можете найти другого сантехника, т.к. в данном случае работы выполняет тот сантехник который предоставлен управляющей компанией.
А мы не можем взять и начать использовать другой ГИС, потому что государство обязывает нас использовать конкретный ГИС.
Вы не можете найти другого сантехника, т.к. в данном случае работы выполняет тот сантехник который предоставлен управляющей компанией.
А мы не можем взять и начать использовать другой ГИС, потому что государство обязывает нас использовать конкретный ГИС.
В статье речь идёт о некоей сферической ГИС в вакууме. При том, что ГИС — это принципиально публичная система (по крайней мере сведения о ней), вы стыдливо скрываете конкретику о какой же конкретно ГИС идет речь, будто речь идет не о ГИС, а о внутренностях СОРМа.
Давайте карты на стол. Уверен, что на хабре достаточно пользователей не только ГИС ЖКХ, но других ГИСов. Обсудим ваши потуги на ниве этого ГИСа, к которому вы лично приложили руку.
Пока что выглядит так, что это не 1ax зашел в каменты хайпануть, а вы пытаетесь хайпануть, описывая собственную крутизну, результат которой пока мы никак не может оценить.
Давайте карты на стол. Уверен, что на хабре достаточно пользователей не только ГИС ЖКХ, но других ГИСов. Обсудим ваши потуги на ниве этого ГИСа, к которому вы лично приложили руку.
Пока что выглядит так, что это не 1ax зашел в каменты хайпануть, а вы пытаетесь хайпануть, описывая собственную крутизну, результат которой пока мы никак не может оценить.
Вот кстати свежайший пример — вчера, судя по плашке на ГИС ЖКХ ночью должны проводится техработы, однако проблемы начались уже днем. У нас пропала улица из справочника. Номер дома есть, город есть, а улицы нет.
Можно было бы подумать, что техработы призваны устранить проблему, но нет, улицы как не было так и нет.
При этом номер версии насколько я могу судить, изменился, то есть то о чем я говорил. Выкатили релиз, теперь оцениваем потери.
На всякий случай: в ФИАС при этом улица есть?
В статье речь о производственном процессе тестирования и методологии, применяемой при тестировании такого рода систем. Как мы шли к этой методологии с 2009 года и какие уроки вынесли при разработке первой ГИС. Статья направлена на техническую аудиторию, в основном на специалистов по тестированию (тест-менеджеров, руководителей групп, тестировщиков, желающих развиваться в управлении качеством), а не на пользователей ГИС ЖКХ в частности. По поводу конкретики выше уже ответила.
Я внимательно почитал вашу статью. В обычной жизни я технический специалист. С ГИСом ЖКХ меня столкнула череда довольно странных жизненных обстоятельств. Но я не вижу в этом ничего плохого, т.к. это позволяет мне более многосторонне взглянуть на проблему, а не только из-за одного забора.
Вы пишите о некой методологии. Пишите красиво (чё уж там). Но всё это выглядит как некий евангелизм. Составьте матрицу знаний, изучите то, это, обменяйтесь опытом в Skype. Это всё прекрасные и полезные (но, кстати, ни разу не технические) советы). Так вот, я веду к тому, что критерий хорошей методологии заключается в том, что она работает — виден положительный результат. Мы же не можем этот результат оценить. И было бы это простительно, если бы вы писали о некой внутренней корпоративной системе или что-то вроде. Но вы пишите о публичной системе.
На самом деле из прочитанного у меня возникает ощущение, что вы писали не методологию хорошего тестирования, а методологию того, как создать заказчику видимость того, что тестирование проведено и оно было качественным.
Вы пишите о некой методологии. Пишите красиво (чё уж там). Но всё это выглядит как некий евангелизм. Составьте матрицу знаний, изучите то, это, обменяйтесь опытом в Skype. Это всё прекрасные и полезные (но, кстати, ни разу не технические) советы). Так вот, я веду к тому, что критерий хорошей методологии заключается в том, что она работает — виден положительный результат. Мы же не можем этот результат оценить. И было бы это простительно, если бы вы писали о некой внутренней корпоративной системе или что-то вроде. Но вы пишите о публичной системе.
На самом деле из прочитанного у меня возникает ощущение, что вы писали не методологию хорошего тестирования, а методологию того, как создать заказчику видимость того, что тестирование проведено и оно было качественным.
Честно говоря мы уже ходим по кругу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чему нас научило тестирование государственной информационной системы