Home

Таблица, на примере которой показано, как можно оценить сэкономленные человеко-часы.

Публикация компании SEADMEX

Качество программного обеспечения всегда было одним из «больных вопросов» для пользователей и для разработчиков.  Кого ни спроси, все обязательно борются за качество. Что характерно, многие действительно борются, применяя тестирование продукта, инспекции кода, детальное документирование процесса разработки и т.д. и т.п. Но это следовало бы назвать обеспечением качества постфактум, закономерно приводящим к необходимости борьбы с дефектами. Однако качество — это, прежде всего, соответствие программного изделия решаемой задаче. Обеспечивать качество можно и нужно путем обеспечения этого соответствия в течение всего процесса разработки. В этом случае есть шанс минимизировать количество дефектов, с которыми придется бороться.

Автор: Вячеслав Панкратов

Руководителям групп тестирования и ведущим тестировщикам часто приходится разрабатывать кроме необходимой рабочей документации и артефактов, документы более высокого уровня, описывающие общие подходы к тестированию системы и развитие процесса тестирования в проекте. Об одном из таких документов-артефактов и пойдёт речь ниже.

Многие из нас сталкивались с разработкой стратегии тестирования, особенно часто подобные артефакты интересуют заказчиков крупных проектов, срок разработки которых превышает год. Попробуем внести ясность в понятие Стратегии Тестирования и ответить на ряд вопросов разобрав несколько примеров на практике.

Авторы: В. В. Кулямин, О. Л. Петренко, ИСП РАН.

Введение

В последнее десятилетие произошли революционные технологические изменения практически во всех видах деятельности, связанных с разработкой и распространением программного обеспечения. Стали активно и широко использоваться такие подходы, как:

• Итеративные процессы разработки ПО
• Методы обеспечения и контроля качества ПО на всех этапах разработки, нацеленные на повышение степени удовлетворения клиентов
• Объектно-ориентированные методы анализа, проектирования и разработки ПО
• Проектирование и разработка ПО с использованием формализованных графических языков моделирования, таких как UML
• Использование инструментов CASE, поддерживающих автоматизированные преобразования из графических языков в языки программирования и обратно

Автор: Антон Михайлов

За последнее время компьютерные системы и выполняемое на них программное обеспечение проникло во все области человеческой деятельности. С ростом компьютерных технологий предъявляются все более высокие требования к качеству создаваемого программного продукта и его последующего сопровождения. Вместе с тем повышаются требования к разработчикам и тестировщикам в плане обеспечения должного уровня качества программного обеспечения, которое смогло бы удовлетворить потребителя. Каскадная модель тестирования программных продуктов предполагает выполнение процедур статического и динамического тестирования.

Автор: Евгений Марченко

Основной проблемой в управлении качеством является тот факт, что определение качества слишком неясное и неоднозначное. Это вызвано тем, что обычно термин качество понимается неправильно. Такая путаница может объясняться несколькими причинами...

 Попробуем ответить на вопросы:

• Что такое качество программного обеспечения?
• Популярный взгляд на качество
• Профессиональный подход к качеству
• Выводы

Источник: Риски в тестировании ПО.

По следам тренинга по работе с рисками в тестировании, я решил разобрать тему рисков в тестировании до простейших составляющих, чтобы для себя и коллег эта полумистическая, полушаманская тема стала прозрачной и управляемой.

Итак, во-первых: риски и проблемы зачастую сваливаются в одну кучу. Риск, по определению какой-то существующий или развивающийся фактор процесса, который обладает потенциально негативным воздействием на процесс и, как следствие, на его результат. Можно, конечно, дотянуть любую проблему до понятия риска, только зачем? В среднем, обычный тренинг по управлению рисками состоит всего на 20-25% из материалов про сам процесс управления рисками и описания типичных рисков, а в остальные 75% времени тренеры пытаются впихнуть под видом рисков описания процессных проблем под соусом «а ещё у вас может быть вот что…». Повторюсь — зачем?

Этот доклад был представлен Александром Орловым на SQAdays 2009.

Там вообще была анимация, но сервис Slide Share ее куда-то зажевал. Если есть желание поглядеть слайдики с анимацией, то их можно скачать отсюда.

Обсудить в форуме

Автор: Стеценко Дмитрий

Традиционно,  многие компании, занимающиеся разработкой ПО, задумываются о процессах по мере роста. Приглашают консультантов, описывают процессы, изводят тонны бумаги и сотни человеко-часов на инструкции, обучают новичков.
Однако на рынке существует очень много небольших компаний, веб студий, внутренних проектов  на несколько человек. Кризис, подстегнувший желание многих западных компаний сэкономить, увеличивает объемы аутсорсинга, и вызывает увеличение количества фрилансеров и микрокомпаний с персоналом от  2 до нескольких десятков человек.  Очень часто там работают знающие и умеющие разработчики, но вот с тестировщиками ситуация как-то значительно печальнее. А такого редкого зверя, как аналитик, тяжело найти и в более крупных компаниях, что уж говорить о маленьких

Последние несколько лет мне довелось работать в такого рода командах. Как правило, начальники в данном случае – люди, понимающие, что тестирование все таки должно быть, желающие улучшить качество продукта, но очень слабо понимающие, что именно надо для этого делать. Они нанимают тестировщика и уподобляются многократно руганному заказчику,  требующему кнопку «сделать хорошо».
В этой статье я попробую просуммировать свой опыт, полученный на нескольких небольших проектах и показать, что именно сработало, или чего не хватало в моем случае. Статья основана на исключительно личном опыте, и не претендует на полноту охвата или всесторонний обзор. Цель – поделится опытом с теми кому довелось быть единственным тестировщиком на проекте, и дать пищу для ума  ПМам, зачастую выросшим из разработки, и не совсем понимающим с какой стороны подходить к организации тестирования.

Продолжение серии слайдкастов с конференции SQA Days 2009 Piter: доклад Сергея Слесарева "Отличия в работе тестировщика в software-development компании и в банке". Название доклада говорит само за себя: докладчик  описывает и анализирует работу специалиста по качеству в банковской сфере, проводит сравнение с тестированием в сфере разработки программного обеспечения.