Home

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

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

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

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

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

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

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

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

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

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

Классификация задач и ролей в тестировании, основанная на методологии RUP.

Вокруг ролей и задач, связанных с тестированием и обеспечением качества, сложилось несколько противоположных идейных течений, которые усердно культивируются носителями этих идей. Точки зрения во многом противоположны, во многом противоречивы. Тестирование видится с одной стороны каким-то полумеханическим процессом, который не требует особенной квалификации: тестировщика видят эдаким «кликальщиком», который просто гоняет приложение, ждёт пока оно «упадёт», потом радостно сообщает об ошибке и продолжает в том же духе. В последнее время, надо отдать должное, появляются материалы о тестировании и качестве, выходят в свет книги, развиваются сайты посвящённые этому направлению — это направление мысли постепенно сходит на «нет». С другой точки зрения, которую, наверное, культивируют отчасти и сами тестировщики (в самом широком смысле этого слова), тестирование — это процесс, покрытый множеством неопределённостей, трудно формализируемый и поддающийся оценкам. Если же к тестированию добавить автоматизацию, которая по оценкам тех, кто внедрял инструменты и решения для тестирования, требует больших (по сравнению с ручным тестированием) трудозатрат и говорить об оценке качества продукта, направление тестирования получается совсем непрозрачным для стороннего наблюдателя, а порой и для самих тестировщиков и QA.

Автор: Максим Уваров

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

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

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

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

Автор: Ларри Квесада, специалист по Rational, IBM

Источник публикации

Excel-плагин для TestManager — это набор макросов, включенных в Microsoft Excel, который расширяет функциональность IBM Rational TestManager. Практики в области тестирования могут использовать плагин вместе с TestManager на всем продолжении цикла тестирования для облегчения разработки набора тестовых данных, его импорта в TestManager, а также передачи отчётов. Менеджеры по обеспечению качества могут использовать плагин для получения доступа к статусу тестовой программы, не запуская её саму. В конце концов, как только отчёты созданы в Excel, можно использовать любую функцию Excel, например, копирование и вставку из книги Excel в документ Word, создание графиков и диаграмм, сводных таблиц, функций, создание версий для печати и т.д.

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

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

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

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

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

Введение

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

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

Источник: журнал BetterSoftware (October 2005)
Перевод: Артём Ваулин

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