Сообщений в теме: 60

[meol]

Проект запущен - проводится анализ, проектирование...

Как взаимодествуют между собой отдел тестирования и разработки?

1 на какой стадии разработки подключаются тестировщики
2 какой между разработчиками и тестировщиками документооборот
3 с чего начинается работа тестировщика в проекте

[Case]

1) Если проект запущен, проводится проектирование и анализ, а тестирование до сих пор не сущетсвует как класс - вы уже опоздали.
С моей точки зрения, тестирование есть неотъемлимый процесс разрабокти продукта/системы, а не только непосредственно кодирования.
2) Мы обычно используем starteam не только как bugtracking system, но и как репозитарий документов, в котором хранится вся документация по проекту, включая ТЗ, документы относящиеся к постановке задачи (нормативные акты, копии рабочей документации и документов, которые подлежат автоматизированию), на более поздних этапах в базу добавляются документы описывающие сценарии использования, юзер стори, словом все рабочие документы, на основе которых впоследствии строится проектная документация. Доступ к документаиции имеют все, документы обсуждаются средствами самого стартима (есть такая возможность организовать дисскисии), задаются вопросы по пунктам документов и неясным моментам ТЗ. В какой то мере тестирование ТЗ проводится всей командой тестировщиков, а не только ведущими специалистами, которым этот круг задач ставится как первоочерёдный. И вот именно поэтому документация не просто хранится, она становится рабочим документом и отдела тестирования и отдела разработки, поэтому если тестирование подключить уже на этапе кодирования этот участок работ - тестирование ТЗ и документации остаётся непокрытым.
Сюда же хотел бы добавить активное участие тестировщиков (в минимальном представлении - ведущего тестировщика) в выработке проекта системы, архитектуры. Трезвый взгляд не загруженного техническими подробностями реализации человека, которым и должен выступать на этом этапе разработки проекта тестировщик, во многом помогает не "наворотить" лишнего и построить более лёгкую и красивую архитектуру, и как следвствие повышает её качество в целом. Кроме того, есть ещё такое понятие как "тестируемость решения", то есть критерий насколько полученное архитектурное решение будет поддаваться анализу с точки зрения тестирования.
3) Разрешите уточнить - о каком тестировщике идёт речь?
Если это тестировщик испытатель, то его деятельность определена тратегией тестирования (были варианты когда ведущий тестер занимался на уровне разработчиков постановкой задачи, разработкой архитектуры, прототипированием интерфейсов), а команда тем временем готовила окружения, создавала тестовую лабораторию (если таковой не было), готовила среду построения билдов (не совсем задача тестеров но это реалии) и приступала к построению окружения тестирования. Были варианты, когда небольшая команда тестировщиков была переброшена на усиление комадны постановщиков и вместе с разработчиками мы строили систему с самого начала, от анализа задачи, выработки требований, постановки задачи плавно переходя на техническую реализацию.
Если вопрос по поводу ведущего тестировщика в проекте - он принимает решения и активное участие с самых первых шагов зарождения системы, иначе полного контроля качеством разработки уже не достичь.

[Олешка]

Проект запущен - проводится анализ, проектирование...

Как взаимодествуют между собой отдел тестирования и разработки?

1 на какой стадии разработки подключаются тестировщики
2 какой между разработчиками и тестировщиками документооборот
3 с чего начинается работа тестировщика в проекте

Соглашусь с Case - идеальная ситуация, когда тестировщика подключают к проекту сразу. Если такого не произошло - чем раньше ему предоставят доступ ко всем материалам проекта, тем лучше. У нас практикуются два варианта работы тестировщиков:

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

2) Тестировщик команды Quality Assurance - в его работу входит тестирование всей функциональности проекта с нуля и оценка качества проекта. Исходными данными для его работы служит спецификация проекта, утвержденная клиентом, выходными данными - описание найденных ошибок. Собственно, это весь документооборот между разработчиками и QA tester.

А работа тестировщика вполне может начинаться с чтения существующей документации и ее тестирования, путем знакомства с разрабатываемой системой.

Да, еще - есть тестирование самих программистов, на уровне кода, до того, как готовый модуль попадает к тестировщику проекта.

[meol]

Если проект запущен, проводится проектирование и анализ, а тестирование до сих пор не сущетсвует как класс - вы уже опоздали. С моей точки зрения, тестирование есть неотъемлимый процесс разрабокти продукта/системы, а не только непосредственно кодирования.

Что делать отделу тестирования, когда документации как таковой не имеется? Есть "спецификация" от заказчика, в том виде, в котором он ее себе представляет и над ней работает аналитик.

Мы обычно используем starteam

starteam - это bugtracking system, где можно узнать о ней поподробнее?

Разрешите уточнить - о каком тестировщике идёт речь

Имелось в виду - человек, который будет заниматься тестированием. (в не зависимости от его квалификации и должности в компании - это может быть временно переквалифицированный разработчик).
Кто будет заниматься тестированием - не важно. Меня интерисует распределение задач по ролям - постановщик, аналитик, разработчик...и наконец Test&QA department.

[Case]

Oleshka, если можно чуть поподробнее о критериях разбиения команды тестирования на две - внутри комадны разработчиков и в составе команды QA (если чесно не совсем понимаю что значит тестировщик внутри команды QA, но об это ниже).
Зачем делить команду? В чём принципиальная разница в разрезе выполняемых задач?

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

С оглядкой на мои слова (или в опровержение оных) обьясните мне, что делает тестировщик в команде качества?

[meol]

А работа тестировщика вполне может начинаться с чтения существующей документации и ее тестирования, путем знакомства с разрабатываемой системой.

Не знаю как в других компаниях, а у нас пока что сложно с документацией...разработчики совмещают много ролей в проекте, документация на последнем месте в рейтинге.

Мы пытаемся навести порядки в этом вопросе.
Определить необходимый минимум документации - REQUIRED, которая необходима в отдел тестирования от разработчиков.

Поделитись опытом:
какую документацию рождают разработчики? без какой документации не может обойтись отдел тестирования?

Интересна сама технология взаимодействия тестеров и разработчиков на каждом этапе ЖЦ продукта.

[Case]

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

[meol]

Согласитесь, что то что предлагает RUP или описывает IEEE слишком громоздко. В реальности проектная документация гораздо менее детализирована.

Есть же определенный набор документов, который составляется от проекта к проекту.

А то, что в зависимости от специфики проекта и требований заказчика, появляются соответствующие документы, то это понятно и не обсуждается.

[Case]

Я уточняю у Вас как у автора вопроса:

какую документацию рождают разработчики? без какой документации не может обойтись отдел тестирования?

Что вы хотите сделать из процесса тестирования?
Есть такое понятие как уровень зрелости системы качества в компании.
На что вы ориентируетесь, потому как для разных уровней и детализация и списки требований очень различные.

[meol]

Что вы хотите сделать из процесса тестирования?

Организовать его на должном уровне!

Система качества в компании находится в зачаточном состоянии.
Хотелось бы узнать опыт других компаний.

[Олешка]

Что делать отделу тестирования, когда документации как таковой не имеется?

Создавать свою документацию. Ставить свой процесс тестирования. Как минимум, нужен test plan template и bug report template. Дополнительно мы используем сводные отчеты, получая их из bug tracking system.

Вот здесь много вкусного и полезного, том числе и шаблоны:

SQAtester

[Олешка]

Без какой документации не может обойтись отдел тестирования?

Если требовать с разработчиков, то как минимум:

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

Неплохо также иметь руководство пользователя.

Если все совсем плохо - начинать с того, что специфицировать продукт самим. Вести учет всех изменений по своей документации и не ждать, что вам ее дадут. Увы.

[Case]

Я бы предложил не хвататься за заготовки документов, а изучить предмет как таковой. Очень рекомендую литературу, обзор которой кстати есть на Тестере в разделе Тестер :: Литература.
Начать рекомендую с книг Луизе Тамре (Введение в тестирование программного обеспечения) или более основательных (я просто не знаю на каком уровне вы представляете предмет, так что без обид :)).

Браться сразу за автоматизированное тестирование не рекомендую, сначала нужен полноценный рабочий процесс тестирования ручного (поверте - это даёт возможность вывести проект на определённый уровень качества).
Почему затронул этот вопрос: очень часто не до конца видя, что такое тестирование/качество, менеджеры компаний пытаются решить вопрос качества автоматизацией тестирования. "Мы купим Робот и теперь тестироваться всё будет очень быстро и качественно. И зачем нам целый отдел тестировщиков? Мы 2 возьмём и они с Роботом нам всё натестят быстро".
То есть нужен сам процесс, потом уже будем автоматизировать его. То что построение автоматизированной системы занимает в 7-10 раз больше времени чем построение аналогичной системы ручного тестирования в каком то её приближении, как-то не учитывается.

Мой совет - книги, потом вопросы и личные рекомендации коллег по цеху. Именно в такой последовательности, во-первых терминология будет подобающая, во-вторых у Вас будет своё видение, которое можно оттачивать в цеху коллег. А если наоборот, мы вам, как говориться, насоветуем :) Втроём не разгребёте :)

[Case]

А может отдельную тему откроете? К примеру "с чего начать систему качества"? Это отдельная и очень интересная тема, тут есть что изучить и в чём разобраться.

[Олешка]

Oleshka, если можно чуть поподробнее о критериях разбиения команды тестирования на две - внутри комадны разработчиков и в составе команды QA (если чесно не совсем понимаю что значит тестировщик внутри команды QA, но об это ниже).
Зачем делить команду? В чём принципиальная разница в разрезе выполняемых задач?

Существует несколько уровней тестирования. Первый - на уровне кода, выполняется самими программистами. Тестируется написанный класс, функция, отслеживается соответствие принятому в компании стандарту написания кода, и т.д. Второй - выполняется тестировщиками внутри проекта, на уровне готового модуля. Третий - выполняется отделом QA. Продукт, который проверен тестировщиками проекта и по которому они дали добро считать его готовым релизом для клиента, принимается отделом QA. Или не принимается.

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

Существует еще такой политически важный момент - тестировщик внутри проекта подчиняется менеджеру проекта. QA tester подчиняется подчиняется менеджеру QA, и больше никому.

[Олешка]

Обеспечение качества - контроль процесса разработки, стандартизация, разработка стандартов, соблюдение стандартов, но никак не само тестирование.

С оглядкой на мои слова (или в опровержение оных) обьясните мне, что делает тестировщик в команде качества?

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

[Case]

Если требовать с разработчиков, то как минимум:
- требования к окружению

С разработчиков? Пардон, а как разработчик влияет на окружение? В каком окружении будет работать система решает заказчик.

- документ, описывающий конфигурацию

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

- документ, описывающий процесс инсталляции
- функциональная спецификация

Идеальный случай, вы описали Oleshka. ИДЕАЛЬНЫЙ. Так не бывает и наверное это логично. Ибо если есть все перечисленные вами документы, то остаётся сесть и начать работать.
На деле, как вы прекрасно понимаете :)

[мечтательно] а если сисадмин нам ещё и окружения все соберёт, дейлибилдерку соберут программисту, с автоматизированным тестированием погодим пока, а ошибки нам сами пользователи найдут когда в альфу отдадим. программеры у нас умные - вылетать не будет. Чтож осталось? Ах да - пиво пить и интернет шерстить :)

Неплохо также иметь руководство пользователя.

И набор тест кейсов.
И пусть тестируют сами :) А чаво - руководство есть, чек лист заполнить смогут небось :)
Я не со зла, Oleshka. Вы всё верно почти описали, но так не бывает.

[meol]

А может отдельную тему откроете? К примеру "с чего начать систему качества"? Это отдельная и очень интересная тема, тут есть что изучить и в чём разобраться.

Отдельная тема - это хорошо!
Идея была ваша, так что будем ждать! ;)

И почему бы вам там не поделиться на тему - "а как все начиналось у нас..."

[Олешка]

To case: Вероятно, у Вас процесс не поставлен. Вот и не работает. У нас - работает.

[Case]

Есть группа контроля качества продукта на выходе

Что она делает давайте сразу говорить, а то мы полдня только на терминологию теряем.

Обе они могут называться QA

Давайте разберёмся что делает контроль качества на выходе, на входе, посредине.
Кстати а в процессе разработки у вас никто не принимает участие из тестировщиков или я как это пропустил?