К сожалению, не имею право отвечать на вопросы такого рода, NDA.
В статье не сказано, что на разработку системы тестирования ушло 10 лет ), мы не разрабатывали такие системы…
В статье опыт тестирования первой крупной системы, проблемы с которыми столкнулись, как их решали и рекомендации тем, кто быть может сейчас с такими же проблемами сталкивается и сможет вынести что-то полезное из нашего опыта, применить наши практики в своей работе.
Буду ругаться конечно, но приму ситуацию и найду другого сантехника.
И в ситуации с сантехником… мне придется принять ее, устранить проблемы в квартире за свой счет, к сожалению, т.к. вероятность что мне ее устранит УК не велика, если нет страховки… и… жить дальше, но это уже совсем другая история… Никак не могу понять, как она может быть связана с тем, как техникум к примеру, обучает слесарей сантехников и что в итоге из них получается на выходе…
Это я вас пытаюсь вернуть к тематике статьи, т.к. цель статьи показать тест менеджерам наши ошибки, пути их устранения, дать рекомендации к процессу тестирования на крупных системах, которые помогут в их работе, а также приведено много полезных документов и методик расчёта, которыми можно пользоваться.
Давайте все таки оставим тему ГИС ЖКХ, т.к. прямого отношения осенний релиз на том проекте, к моей статье не имеет.
А я не имею никакого отношения к управлению тестированием на проекте ГИС ЖКХ и кроме передачи коллегам просьбы принять меры и устранить последствия, ничем помочь больше не могу.
Ваши комментарии читают мои коллеги, участвующие в проекте ГИС ЖКХ, в том числе руководитель тестирования. Уверена, будут сделаны соответствующие выводы и приняты меры, чтобы не допускать серьезных инцидентов на продуктив.
После любого релиза крупной ГИС проводится технический анализ, в том числе исследуются негативные факторы обновления ГИС, повлекшие ошибки на продуктиве.
Уверена, что мои коллеги такой анализ проводили, сделали выводы и самое главное поняли допущенные ошибки (если они имели место быть со стороны тестирования) с целью проведения мер, направленных на недопущение подобных ситуаций в следующем релизе. Разработка таких систем — это командная работа, даже если причина ошибок была не в тестировании, а в аналитике или неверной установке на продуктив и т.д., анализ проводится в комплексе, меры недопущения подобных ситуаций касаются всей проектной команды.
Мне жаль, что тот осенний релиз 2019 года доставил вам столько неудобств.
Касаемо Вашего опыта, когда вы выступали со стороны Заказчика.
Наши Заказчики также не подписывают акты о выполненных работах и не проводят оплату, если мы не смогли пройти приёмочном-сдаточные испытания по этапу работ в рамках наших контрактных обязательств.
Со своими подрядчиками, в рамках наших контрактных обязательств, мы также обсуждаем ситуации, проводим совместные работы по изменению/улучшению процессов, с целью выпускать более качественные релизы. Если договорными отношениями допускаются штрафы за некачественно выполненные работы, то в подрядчиков можем и оштрафовать.
Что касаемо внутренних сотрудников, работающих на проектах, у всех есть KPI и работа каждого тестировщика оценивается со стороны Тест-менеджера команды на предмет его достижения или не достижения поставленных KPI, собирается обратная связь внутри рабочей группы, оценивается эффективность сотрудников и при необходимости принимаем разного рода меры, направленные на рост сотрудников, их обучение и как следствие улучшения качества работы, которое, в свою очередь приводит к улучшению качества тестирования. Естественно не всегда мы достигаем успеха, как и в любой сфере, но мы к этому стремимся.
Я бы вам рекомендовала принять ситуацию по требованиям от технической поддержки любой крупной системы, а именно детально заполнить форму обратной связи, приложить скриншоты и т.д., если цель вашего обращения в техподдержку — исправление возникшего инцидента. Только детальное описание инцидента поможет с его скорейшим решением.
Вы не очень внимательно читали статью.
Речь про то как мы налаживали производственный процесс тестирования крупных систем в период времени с 2009-2019 года.
Речь не идет про конкретный проект ГИС ЖКХ. Я НЕ ОПИСЫВАЮ процесс тестирования ГИС ЖКХ.
В статье указан базис по тестированию такого рода систем, основные моменты, на которые стоит обращать внимание и как мы до них дошли методом проб, ошибок, обучения, консультаций с другими специалистами из области тестирования.
Если вы считаете, что этот базис не верный, не рабочий, не оптимальный и т.д., я буду благодарна, если вы поделитесь Вашим удачным опытом построения процесса тестирования такого рода систем.
Мне искренне жаль, что вы сталкиваетесь с ошибками на одном конкретном проекте, при этом, к сожалению, вы не готовы озвучить ваши текущие открытые инциденты, мешающие работе с порталом, чтоб мы посмотрели, чем можем вам помочь. Мы стараемся совершенствовать наши навыки тестирования и оптимизируем производственный процесс, чтобы сократить такие моменты и выпускать новые релизы лучше, предыдущих. Именно это я пыталась отразить в статье — как мы измеряем качество, какие метрики используем, как это отслеживаем. Если я не до конца раскрыла вопрос с метриками качества, задайте, пожалуйста ваши вопросы по этой теме статьи, постараюсь вам развернуто ответить.
Вы немного ушли от тематики статьи в плоскость обсуждения особенностей технической поддержки конкретного проекта.
Давайте попробуем вернуться в плоскость обсуждение особенностей производственного процесса тестирования ГИС.
Ответ на ваш вопрос про техподдержку ГИС
(я сознательно пишу про любые ГИС, а НЕ КОНКРЕТНО ПРО ГИС ЖКХ).
Конечно над поддержкой ГИС работают специалисты разного уровня доступа к промышленному контуру. Такие специалисты есть как в технической поддержке, так и в производственной команде. Проверять что-то непосредственно на промышленном контуре для локализации инцидента в большинстве случаев нет необходимости, т.к. всегда развернут тестовый контур, копия промышленного, где установлена такая же версия системы, для возможности воспроизведения инцидентов, поступающих на третью линию поддержки.
Ваша задача, как пользователя, предоставить максимально точно информацию по выполняемым действиям, приводящим к инциденту, в том числе снять скриншоты. Для вас это могут быть совершенно рядовые действия, но при этом в профиле заполнены какие-то данные или не заполнены, которые в сочетании с вашими действиями приводят к возникновению инцидента. Только в этом случае у специалистов увеличивается шанс, воспроизвести, проанализировать причины, передать в разработку на исправление.
Спасибо за вопросы.
Смогу ответить только на часть вопросов, и далее вы поймете почему. Вопрос 1
Нет, вы поняли не правильно. Речь не про ГИС ЖКХ. Как писала в комментарии выше, речь идет о целом пласте проектов, создаваемых в нашем департаменте с 2009-2019 года. В первую очередь речь шла о самой первой ГИС и бОльшая часть проблем, относилась к системам 2009-2015 годов. Это НЕ ГИС ЖКХ. Однако, наработанные в те годы практики, грабли на которые мы наступали на своем пути при тестировании систем такого масштаба, были учтены, и лучшие практики применены и на проекте ГИС ЖКХ в том числе. Лично мое участие в ГИС ЖКХ тоже было, меня привлекали как эксперта для решения задач по оптимизации процесса тестирования на ГИС ЖКХ и улучшения качества тестирования. Мое участие в проекте было 2016-2017 годы, я выполнила поставленные задачи и далее переключилась на другие задачи департамента. Вопрос 2.
Вижу, что основная ваша боль – ГИС ЖКХ, а в частности интеграция с этой системой. Я не в контексте текущих процессов на проекте ГИС ЖКХ, т.к. руководит тестированием мой коллега. Поэтому отвечать за то, как устроено интеграционное взаимодействие на проекте в данный момент, при этом не участвовать в проекте более 2 лет будет не правильно.
У нас есть отдельные статьи по ГИС ЖКХ на хабр, где вы можете задать вопрос, касаемый этой темы.
По поводу проблем, с которыми сталкиваются конечные пользователи при обновлении крупных ГИС, если вдруг серьезно изменился бизнес процесс или интерфейс.
Я прекрасно понимаю боль пользователей, т.к. сама не очень люблю перемены, особенно в интерфейсе, но это неизбежность, зачастую вызвана изменением законодательства или же переработкой интерфейса в рамках требований от Заказчика. Как правило это направлено на улучшение или вынужденные изменения (поменялись НПА или закон), никто заранее не ставит перед собой цель поиздеваться над пользователем. В статье я описывала проблемы на начальном этапе, когда мы только начинали разрабатывать ГИС (2009-2010 года), потом мы приняли ситуацию и научились оптимально с ней работать/жить. В рамках производственного процесса разработки программного обеспечения, проблема разрешилась, т.к. были найдены пути, как с этим работать. Вопрос 3.
Да, всегда тестовые сценарии создаются в терминах той предметной области, для которой они разрабатываются. Вы снова приводите конкретный пример из ГИС ЖКХ :). Не могу точно сказать, используют ли коллеги в тест-кейсах ТСЖ «Березка», но точно могу сказать, что любые тест-кейсы мы составляем с учетом предметной области и ее особенностей. Вопрос 4.
Простите, не совсем понимаю о каком софте вы спрашиваете, прошу уточнить ваш вопрос с примером. Вопрос 5.
Из контекста, могу догадаться, что вопрос касается снова конкретной системы ГИС ЖКХ, который правильнее адресовать коллегам. Что касается производительности ГИС систем, то ответ да, всегда уделяется внимание производительности и проводится нагрузочное тестирование такого рода систем перед каждым релизом. Информацию о том, как технически устроен процесс автоматизации на наших проектах, можно также прочитать в недавних статьях моих коллег.
Спасибо за проявленный интерес к статье.
Постараюсь развернуто ответить на все ваши вопросы. По поводу автоматизации:
В статье затронут пласт крупных проектов ГИС с 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 месяцев они уже становились младшими тестировщиками, полноценно участвовали в тестировании новых доработок. Касаемо бюджета на тестирование.
Т.к. речь в статье в большей степени о ГИС, то после того, как выигран конкурс на разработку системы, бюджет тестирования заложен в контракт и он включает в себя определенные риски, в том числе, связанные с изменением законодательства или нормативной документации.
Острого недостатка в бюджете не было, но вопрос об оптимальности работы команды возникает всегда и мы стараемся совершенствоваться в процессе тестирования, чтобы не тратить впустую бюджет на ненужные телодвижения или неоптимальную работу, обычно это заслуга всей проектной команды.
На рабочих совещаниях обсуждаются планы всей проектной команды и тестирования в том числе. Если тестирование выбивается из сроков релиза, каждый случай обсуждаем и анализируем, вырабатываем оптимальный вариант решения ситуации, при необходимости меняем планы или объем работ, расширяем команду, если это возможно и целесообразно. Внедряем автоматизацию, естественно.
В статье не сказано, что на разработку системы тестирования ушло 10 лет ), мы не разрабатывали такие системы…
В статье опыт тестирования первой крупной системы, проблемы с которыми столкнулись, как их решали и рекомендации тем, кто быть может сейчас с такими же проблемами сталкивается и сможет вынести что-то полезное из нашего опыта, применить наши практики в своей работе.
И в ситуации с сантехником… мне придется принять ее, устранить проблемы в квартире за свой счет, к сожалению, т.к. вероятность что мне ее устранит УК не велика, если нет страховки… и… жить дальше, но это уже совсем другая история… Никак не могу понять, как она может быть связана с тем, как техникум к примеру, обучает слесарей сантехников и что в итоге из них получается на выходе…
Это я вас пытаюсь вернуть к тематике статьи, т.к. цель статьи показать тест менеджерам наши ошибки, пути их устранения, дать рекомендации к процессу тестирования на крупных системах, которые помогут в их работе, а также приведено много полезных документов и методик расчёта, которыми можно пользоваться.
Давайте все таки оставим тему ГИС ЖКХ, т.к. прямого отношения осенний релиз на том проекте, к моей статье не имеет.
А я не имею никакого отношения к управлению тестированием на проекте ГИС ЖКХ и кроме передачи коллегам просьбы принять меры и устранить последствия, ничем помочь больше не могу.
Уверена, что мои коллеги такой анализ проводили, сделали выводы и самое главное поняли допущенные ошибки (если они имели место быть со стороны тестирования) с целью проведения мер, направленных на недопущение подобных ситуаций в следующем релизе. Разработка таких систем — это командная работа, даже если причина ошибок была не в тестировании, а в аналитике или неверной установке на продуктив и т.д., анализ проводится в комплексе, меры недопущения подобных ситуаций касаются всей проектной команды.
Мне жаль, что тот осенний релиз 2019 года доставил вам столько неудобств.
Касаемо Вашего опыта, когда вы выступали со стороны Заказчика.
Наши Заказчики также не подписывают акты о выполненных работах и не проводят оплату, если мы не смогли пройти приёмочном-сдаточные испытания по этапу работ в рамках наших контрактных обязательств.
Со своими подрядчиками, в рамках наших контрактных обязательств, мы также обсуждаем ситуации, проводим совместные работы по изменению/улучшению процессов, с целью выпускать более качественные релизы. Если договорными отношениями допускаются штрафы за некачественно выполненные работы, то в подрядчиков можем и оштрафовать.
Что касаемо внутренних сотрудников, работающих на проектах, у всех есть KPI и работа каждого тестировщика оценивается со стороны Тест-менеджера команды на предмет его достижения или не достижения поставленных KPI, собирается обратная связь внутри рабочей группы, оценивается эффективность сотрудников и при необходимости принимаем разного рода меры, направленные на рост сотрудников, их обучение и как следствие улучшения качества работы, которое, в свою очередь приводит к улучшению качества тестирования. Естественно не всегда мы достигаем успеха, как и в любой сфере, но мы к этому стремимся.
Речь про то как мы налаживали производственный процесс тестирования крупных систем в период времени с 2009-2019 года.
Речь не идет про конкретный проект ГИС ЖКХ. Я НЕ ОПИСЫВАЮ процесс тестирования ГИС ЖКХ.
В статье указан базис по тестированию такого рода систем, основные моменты, на которые стоит обращать внимание и как мы до них дошли методом проб, ошибок, обучения, консультаций с другими специалистами из области тестирования.
Если вы считаете, что этот базис не верный, не рабочий, не оптимальный и т.д., я буду благодарна, если вы поделитесь Вашим удачным опытом построения процесса тестирования такого рода систем.
Мы готовы учиться и развиваться.
Давайте попробуем вернуться в плоскость обсуждение особенностей производственного процесса тестирования ГИС.
Ответ на ваш вопрос про техподдержку ГИС
(я сознательно пишу про любые ГИС, а НЕ КОНКРЕТНО ПРО ГИС ЖКХ).
Конечно над поддержкой ГИС работают специалисты разного уровня доступа к промышленному контуру. Такие специалисты есть как в технической поддержке, так и в производственной команде. Проверять что-то непосредственно на промышленном контуре для локализации инцидента в большинстве случаев нет необходимости, т.к. всегда развернут тестовый контур, копия промышленного, где установлена такая же версия системы, для возможности воспроизведения инцидентов, поступающих на третью линию поддержки.
Ваша задача, как пользователя, предоставить максимально точно информацию по выполняемым действиям, приводящим к инциденту, в том числе снять скриншоты. Для вас это могут быть совершенно рядовые действия, но при этом в профиле заполнены какие-то данные или не заполнены, которые в сочетании с вашими действиями приводят к возникновению инцидента. Только в этом случае у специалистов увеличивается шанс, воспроизвести, проанализировать причины, передать в разработку на исправление.
Смогу ответить только на часть вопросов, и далее вы поймете почему.
Вопрос 1
Нет, вы поняли не правильно. Речь не про ГИС ЖКХ. Как писала в комментарии выше, речь идет о целом пласте проектов, создаваемых в нашем департаменте с 2009-2019 года. В первую очередь речь шла о самой первой ГИС и бОльшая часть проблем, относилась к системам 2009-2015 годов. Это НЕ ГИС ЖКХ. Однако, наработанные в те годы практики, грабли на которые мы наступали на своем пути при тестировании систем такого масштаба, были учтены, и лучшие практики применены и на проекте ГИС ЖКХ в том числе. Лично мое участие в ГИС ЖКХ тоже было, меня привлекали как эксперта для решения задач по оптимизации процесса тестирования на ГИС ЖКХ и улучшения качества тестирования. Мое участие в проекте было 2016-2017 годы, я выполнила поставленные задачи и далее переключилась на другие задачи департамента.
Вопрос 2.
Вижу, что основная ваша боль – ГИС ЖКХ, а в частности интеграция с этой системой. Я не в контексте текущих процессов на проекте ГИС ЖКХ, т.к. руководит тестированием мой коллега. Поэтому отвечать за то, как устроено интеграционное взаимодействие на проекте в данный момент, при этом не участвовать в проекте более 2 лет будет не правильно.
У нас есть отдельные статьи по ГИС ЖКХ на хабр, где вы можете задать вопрос, касаемый этой темы.
По поводу проблем, с которыми сталкиваются конечные пользователи при обновлении крупных ГИС, если вдруг серьезно изменился бизнес процесс или интерфейс.
Я прекрасно понимаю боль пользователей, т.к. сама не очень люблю перемены, особенно в интерфейсе, но это неизбежность, зачастую вызвана изменением законодательства или же переработкой интерфейса в рамках требований от Заказчика. Как правило это направлено на улучшение или вынужденные изменения (поменялись НПА или закон), никто заранее не ставит перед собой цель поиздеваться над пользователем. В статье я описывала проблемы на начальном этапе, когда мы только начинали разрабатывать ГИС (2009-2010 года), потом мы приняли ситуацию и научились оптимально с ней работать/жить. В рамках производственного процесса разработки программного обеспечения, проблема разрешилась, т.к. были найдены пути, как с этим работать.
Вопрос 3.
Да, всегда тестовые сценарии создаются в терминах той предметной области, для которой они разрабатываются. Вы снова приводите конкретный пример из ГИС ЖКХ :). Не могу точно сказать, используют ли коллеги в тест-кейсах ТСЖ «Березка», но точно могу сказать, что любые тест-кейсы мы составляем с учетом предметной области и ее особенностей.
Вопрос 4.
Простите, не совсем понимаю о каком софте вы спрашиваете, прошу уточнить ваш вопрос с примером.
Вопрос 5.
Из контекста, могу догадаться, что вопрос касается снова конкретной системы ГИС ЖКХ, который правильнее адресовать коллегам. Что касается производительности ГИС систем, то ответ да, всегда уделяется внимание производительности и проводится нагрузочное тестирование такого рода систем перед каждым релизом. Информацию о том, как технически устроен процесс автоматизации на наших проектах, можно также прочитать в недавних статьях моих коллег.
Постараюсь развернуто ответить на все ваши вопросы.
По поводу автоматизации:
В статье затронут пласт крупных проектов ГИС с 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 месяцев они уже становились младшими тестировщиками, полноценно участвовали в тестировании новых доработок.
Касаемо бюджета на тестирование.
Т.к. речь в статье в большей степени о ГИС, то после того, как выигран конкурс на разработку системы, бюджет тестирования заложен в контракт и он включает в себя определенные риски, в том числе, связанные с изменением законодательства или нормативной документации.
Острого недостатка в бюджете не было, но вопрос об оптимальности работы команды возникает всегда и мы стараемся совершенствоваться в процессе тестирования, чтобы не тратить впустую бюджет на ненужные телодвижения или неоптимальную работу, обычно это заслуга всей проектной команды.
На рабочих совещаниях обсуждаются планы всей проектной команды и тестирования в том числе. Если тестирование выбивается из сроков релиза, каждый случай обсуждаем и анализируем, вырабатываем оптимальный вариант решения ситуации, при необходимости меняем планы или объем работ, расширяем команду, если это возможно и целесообразно. Внедряем автоматизацию, естественно.