Несколько мыслей о том, что должно делать QA подразделение с ошибками и тестированием.
— То, что можно автоматизировать – нужно автоматизировать
Тут все просто. Если что-то может делать машина, то пусть она это и делает, на то мы существа и наделенные ленью.
Обратная сторона медали, если что-то автоматизируется плохо — нельзя тратить кучу времени пытаясь таки это автоматизировать.
— Все ошибки должны быть в системе багтрекинга
Нету большего врага QA и Dev подразделения, чем ошибки, которые передаются как предания — наскальной живописью, сказками и т.п.
— Ошибки должны иметь настолько дотошное описание, чтобы человек с улицы мог их повторить.
Экономия 30 секунд на описании ошибки выливается потом, в несколько часов попыток ее повторить, обсуждения с тестерами и т.п.
Кстати, это должно включать версии тестируемого продукта и детали, на какой конфигурации все тестировалось.
— Ошибки должны быть приоритезированы
Иногда QA это делают сами, иногда с менеджерами, иногда с разработчиками. Но в конечном итоге, ошибка типа «программа не устанавливается вообще», должна быть выше приоритетом, чем «показ лишнего пикселя в диалоге, которые запустит 1 из 1000 пользователей».
— Раз в некоторое время система контроля ошибок должна прочищаться
Обычно, за несколько лет, в ней накапливаются сотни ошибок, которые никто и никогда не будет исправлять, более того, которые даже уже повторить нельзя, так как программа кардинально изменена.
Этот мусор зачастую тяжело отделить каким-то автоматическим фильтром и приходится постоянно его видеть.
— QA отдел (из своего названия) должен гарантировать, что все крупные баги должны быть найдены
Один их самых плохих признаков, когда при втором проходе тестирования той же версии продукта, находятся серьезные дефекты.
— Тестирование должно быть планированным и эффективным
Всегда должен быть план, что будет тестироваться, как будет тестироваться. Сколько времени на это отведено. И за это время QA должно найти как можно больше серьезных багов.
Ну, и как добавок к статье, скажу, что внутри фирмы обычно QA занимает одну из двух позиций:
— отделение неформально подчинено программистам
То есть программисты и сами могли бы протестировать, но работу эту сбрасывают на QA отделение так как труд тестеров стоит дешевле и у них не такой «замыленный» глаз.
Проблема этой схемы, что тестеры в такой ситуации фактически не имеют права голоса и получается, что зачастую программистам удается «задавить» авторитетом тестеров и продукт выходит с крупными дефектами.
— отделение программистов неформально подчинено QA
Обычно это происходит, когда QA назначают ответственных за выпускаемый продукт. То есть, только когда QA менеджер говорит, продукт нормального качества, то продукт выходит в свет.
Тут складывается обратная ситуация, обычно тестировщикам удается «задавить» программистов и продукт перешлифовывается.
Нормальная ситуация, когда эти два отдела работают отдельно и менеджеры отделов решают когда выпускать или не выпускать продукт. Зачастую ситуация с перекосом в одну сторону происходит, если существует всего один менеджер, которые управляет обеими отделами. В таком случае его субъективное мнение клонит равновесие в одну из сторон.
>> — То, что можно автоматизировать – нужно автоматизировать
А как же стоимость? Автоматизация — затратный процесс, как по необходимому времени, так и по квалификации тестировщика. Совет: почитайте что-нибудь по этому вопросу, перед такими заявлениями.
>> — Все ошибки должны быть в системе контроля версий
Поправочка: я так думаю, что речь идёт о сообщениях об ошибке?
Если да, то может в системе багтрэкинга? А то я использую Subversion и просто понять не могу, как туда засунуть ошибку?
Если же нет, то тогда естественно ошибки должны быть в системе контроля версий, поскольку носителем ошибки является код (я не рассматриваю пока ошибки документации и т.п., хотя документации тоже должна иметь версионность), то он должен быть в системе контроля версий.
>> — Ошибки должны иметь настолько дотошное описание, чтобы человек с улицы мог их повторить.
Опять же не соглашусь. Сообщения об ошибках должны отвечать текущему уровню специалистов компании плюс небольшой запас. И человек пришедший с улицы может и не суметь её воспроизвести. Зато сэкономите время тестировщика на создание ошибки и он сможет больше уделить внимания другим моментам.
>> — QA отдел (из своего названия) должен гарантировать, что все крупные баги должны быть найдены
Опять же, отправлю куда-нибудь почитать по тематике. QA отдел, как следует из названия, должен гарантировать, что крупные баги НЕ ДОПУСТЯТСЯ. А то, о чём вы говорите, называется Quality Control — сбор информации о существующих багах.
>> Ну, и как добавок к статье, скажу, что внутри фирмы обычно QA занимает одну из двух позиций: …
А сколько фирм вы знаете? Я работал в компании (руководителем QA), где у тестировщиков — свой руководитель, у проекта — свой. И в лучших традициях диалектики, борьба единства (цель: выпустить продукт) и противоположностей (что из себя продукт представляет), приводило к хорошим результатам.
>> — То, что можно автоматизировать – нужно автоматизировать
>А как же стоимость? Автоматизация — затратный процесс, как по необходимому времени, так и >по квалификации тестировщика. Совет: почитайте что-нибудь по этому вопросу, перед такими >заявлениями.
Читал и участвовал в разработке системы автоматизирования.
Кстати, поэтому и написал «Если что-то автоматизируется плохо — нельзя тратить кучу времени пытаясь таки это автоматизировать.»
А вообще на долгоиграющих проектах, автоматизация себя окупает.
>> — Все ошибки должны быть в системе контроля версий
>Поправочка: я так думаю, что речь идёт о сообщениях об ошибке?
>Если да, то может в системе багтрэкинга?
Да. Вы правы, имелся в виду багтрекинг. Я поправил в статье.
Не пробовали отдавать статьи на рецензирование? Давайте попробуем, вдруг получится.
http://it4business.ru/forum/index.php?showtopic=11510
Ну, давайте поглядим.
Хотя рецензирование статей своего блога… хм… достаточно необычная идея.
>> Читал и участвовал в разработке системы автоматизирования.
Прошу прощения, что придираюсь, но всё-таки, вы учавствовали в разработке системы автоматизации тестирования или во внедрении автоматизации тестирования? Подозреваю всё же второе.
>> Кстати, поэтому и написал “Если что-то автоматизируется плохо — нельзя тратить кучу времени пытаясь таки это автоматизировать.”
>> А вообще на долгоиграющих проектах, автоматизация себя окупает.
Ну а если начать дальше оценивать фразы «автоматизируется плохо» и «автоматизация себя окупает», переводя любую оценку в деньги, то получим вывод:
«Перед внедрением автоматизации, оцените, будет ли она выгодна или нет.» Ну и продолжая вывод, «Если автоматизация не выгодна, а очень хочется, что можно сделать, чтобы внедрить.» Где-то так. 😉
>Прошу прощения, что придираюсь, но всё-таки, вы учавствовали в разработке системы >автоматизации тестирования или во внедрении автоматизации тестирования?
Звучит удивительно, но именно в первом. А вот как раз во внедрении поучаствовать толком не удалось.
>Перед внедрением автоматизации, оцените, будет ли она выгодна или нет.” Ну и продолжая >вывод, “Если автоматизация не выгодна, а очень хочется, что можно сделать, чтобы >внедрить.” Где-то так. 😉
С этим соглашусь на 100%. 🙂
А помоему отличная статья. Развитие QA отделов во многих компаниях находится на слабеньком уровне. Поэтому если менеджер отдела задает себе перечисленные выше вопросы — это уже неплохо на нашем рынке. И кому-то она покажет новые горизонты.
К тому же, как мне кажется, этот блог сугубо практический и мысли которые тут пишутся — рождены опытом а не только теоритическими изысками. Что сильно подымает их ценность.
Относительно последних комментариев о не/формальном подчинении. Это пожалуй самый интересный вопрос. Все зависит от того что команда делает.
Если часть работы — пользовательские интерфейсы, какие-то функционалы которые будут использоваться конкретным Васей который сидит за компом — то идеально когда тестировщик может лидировать.
Если же результат работы программиста будет использоваться другим программистом, то имхо лидирование должно оставаться у программистов.
Спасибо :))
А то, что-то пару последних дней в основном негативные комментарии собираю…
>К тому же, как мне кажется, этот блог сугубо практический и мысли которые тут пишутся — >рождены опытом а не только теоретическими изысками.
Это действительно так. Есть конечно множество вещей, которые я обобщаю на основе своего опыта. Так, что не каждая фраза проверена, но практическая база под тем, что я пишу — есть.
>Относительно последних комментариев о не/формальном подчинении. Это пожалуй самый >интересный вопрос. Все зависит от того что команда делает.
Да, чаще всего клонит в сторону либо в зависимости от типа программ, либо в зависимости от типов менеджеров. Например сейчас участвую в продукте, которые явно должны вести программисты, но так как менеджер над QA и Dev, бывшый менеджер QA, то все кренится именно в QA часть.
А оно совсем не плохо когда человек выходит из QA.
Девелопмент часть в принципе потеряна быть не может. Это исключено, так как именно довелоперы и создают стоимость. А менеджер проекта, который вышел из QA, в течении еще какого-то времени настроен на то, что качество нужно держать, и эта мысль ему в голову вбита сапогами клиентов — то есть сидит крепко.
Главное не злоупотреблять в таких случаях, так как долгое отсутствие нормального development managera может опустить технологический уровень проекта/компании. Что чревато.
Так сказать нужен разумный компромис, если проблема еще не создана.
Да, естественного ничего плохого в этом нету. До тех пор пока есть равновесие в фирме.
Кстати, сейчас оно потихоньку налаживается, но был переклон в сторону QA и упущения технологического уровня.
Есть кстати, одна неприятная особенность когда QA руководит программистами, особенно в отсутствии нормальных team lead). Он редко может погрузиться в технические детали.
всё хорошо, вот тока по всему тексту QA надо заменить на QC. 🙂
А что такое QC?
эээээ. это не шутка? 🙂
Quality Assurance и Quality Control немного разные activities. Всё описанное относится в большей степени к QC, а не к QA.
если шутить, то: «перелом карьеры тестера: ‘как ты уже здрал ныть!!! что сделать чтоб ты заткнулся?’ если ему есть, что на это сказать, то QC может стать QA.»
Чуть ниже мне altermath рассказал.
Это была не шутка. Наверное мне не повезло и в основном я работал в конторах именно с QC, может быть с легком оттенком QA.
Да и термин QC сегодня первый раз встретил, хм… опять же удивлен.
Ну, век живи (уже неплохое пожелание) — век учись (это более жестокое) 🙂
Есть оговорки почти по каждому пункту 🙂
Если просто как мантру использовать разве что — да, полезности без привязки к реалиям.
Ну, это естественно. Если начать раскрывать каждый пункт по полной программе, то каждый из них можно на главу в книге роскатать.
Пожалуй — эти пункты действительно мантра, в смысле, что они скорее побуждение к действию, чем идеальное описание того. что делать.
QC — quality control, контроль качества, как раз собирают баги
QA — quality assurance, занимаются качеством процессов, их задача состоит (в том числе) в предупреждении появления багов.
У нас постоянно путают эти два понятия…
Мне кажется, что не только у нас, но и у них (я сейчас в штатах) путают эти две вещи в таком случае.
Фактически, все используют термин QA и фактически все имеют в основном QC.
это да, но это не повод идти у них на поводу 🙂
Даешь, правильное употребление терминологии в каждой компании к 2010 году!!! 🙂
По пунктам.
> — То, что можно автоматизировать – нужно автоматизировать
Смотри доклад Дмитрия Ручко о мифах. Ну и мои две статьи «автоматизированное тестирование с самого нуля»
> — Все ошибки должны быть в системе багтрекинга
«Не обязательно. Но если вы не знаете почему это не так, то считайте это абсолютной истиной» смотри архив форума тестировщиков
> — Ошибки должны иметь настолько дотошное описание, чтобы человек с улицы мог их повторить.
Нет. Это прямые убытки. См. ну хотя бы «Вальсируя с медведями» Листера и Демарко
> — Ошибки должны быть приоритезированы
1) Иногда да, иногда нет.
2) Кроме того существуют несколько способов управлением багами. Приоритеты — лишь один из них.
>- Раз в некоторое время система контроля ошибок должна прочищаться
> Обычно, за несколько лет, в ней накапливаются сотни ошибок, которые никто и
> никогда не будет исправлять, более того, которые даже уже повторить нельзя,
> так как программа кардинально изменена.
> Этот мусор зачастую тяжело отделить каким-то автоматическим фильтром и
> приходится постоянно его видеть.
Типа делать «close» и настраивать фильтры мы уже разучились? А хранить их стоит, хотя бы для статистического анализа.
— QA отдел (из своего названия) должен гарантировать, что все крупные баги должны быть найдены
Не совсем так. Тестовое покрытие должно быть достаточным для получения продукта заданного качества с определенным заранее доверительным интервалом. За подробностями на форум тестировщиков, и на курс теорвера.
> — Тестирование должно быть планированным и эффективным
> Всегда должен быть план, что будет тестироваться, как будет тестироваться.
> Сколько времени на это отведено.
Планирование — один из способов повышения эффективности. Есть другие. Соответственно, союз «и» неуместен.
Кроме того, иногда для повышения эффективности нужно отказаться от планирования.
> И за это время QA должно найти как можно больше серьезных багов.
Нет. Он должен искать баги, которые будут правиться. Опять же на форум. там есть отдельная ветка по этой теме.
> Ну, и как добавок к статье, скажу, что внутри фирмы обычно QA занимает одну из двух позиций:
> — отделение неформально подчинено программистам
> То есть программисты и сами могли бы протестировать, но работу эту сбрасывают
> на QA отделение так как труд тестеров стоит дешевле и у них не такой «замыленный» глаз.
Особенно мне нравится про «подешевле». Добро пожаловать в реальный мир. Сейчас при равной квалификации тестер получает больше программера. программисты на это уже жалуются.
> — отделение программистов неформально подчинено QA
> Обычно это происходит, когда QA назначают ответственных за выпускаемый продукт.
> То есть, только когда QA менеджер говорит, продукт нормального качества, то
> продукт выходит в свет.
По структуре службы качества посмотрите доклады Елены Ивановой и Александра Лобача. Многое прояснится.
——————————
И напоследок. Заголовок статьи не соответствует содержимому.
ok. Я не буду отвечать на каждый пункт, я отвечу суммарно.
а) «Мысль изреченная есть ложь»
Любую фразу, которую я напишу или любой другой человек тоже можно оспорить с какого-то угла. Тем не менее, это не значит, что фраза лишена смысла.
Я вполне иду на уточнения фразы или формулировок, но достаточно редко случается так, что фраза полностью неправильна в корне.
б) На каждую фразу я уделил порядка 3-4 предложений.
Как я согласился со Славой Панкратовым, скорее каждая фраза которую я написал — мантра. То есть пункт, который нужно помнить.
Я всегда и везде говорю: «Без фанатизма». Естественно, если взять фразу и с заставить на нее молиться, то от этого будет вред, а не польза.
в) Дмитрий Ручко, Елена Иванова и Александр Лобача, Листер и Демарко
Я уверен, что все эти люди профессиональны, и знают больше меня в тестировании.
Однако, те фразы, которые я писал тоже базированы на опыте. И да, я ставлю полученный
мной опыт выше чем прочтенную информацию о чужом опыте. Естественно, я воспринимаю внешнюю информацию, но до тех пор пока она не прошла у меня в руках проверку практикой, я к ней отношусь с сомнением.
И напоследок. Мне не нравиться ваш тон.
> Типа делать «close» и настраивать фильтры мы уже разучились?
> Добро пожаловать в реальный мир.
> Не пробовали отдавать статьи на рецензирование? Давайте попробуем, вдруг получится.
> Бред. Все с точностью до наоборот.
Я тоже себе позволяю иногда сарказм. Но у вас, что-то многовато.
SALar, скажи почему ты такой злой? 🙂
Внимание — оффтп!
Фу-у-ух. Начитался 🙂
Напоследок насру еще в каментах. 🙂
Витя, привет.
На http://www.developers.org.ua в линкдампах дали линк на твой пост «Программистский синхрофазотрон». Сижу в твоем блоге уже часов пять наверное. Вот хотел передать тебе привет от компа, за которым ты работал когда уходил из CDD. Я до сих пор за ним сижу и даже твой коврик с надписью Palm Treo все еще юзаю. За это время сменили мне тока моник, винт, мышку и клаву. И то мышку уперли техники 4 месяца назад, когда в новый офис переезжали. Наверное решили продать раритет в антикварную лавку, сцуки, за большие бабки. Где щас еще найдешь работающую шариковую мышь? 🙂 Вы тока не подумайте шо у нас тут на железо жлобятся 🙂 Просто у Вити по тем меркам (4,5 года) был довольно таки не плохой комп. Мне его до сих пор хватает 🙂
Привет 🙂
Я кстати раздумывал тот jaguar ты или не тот ;))) Уже собирался IP смотреть, Харьковские ли.
Передавай привет, кого из старых знакомых увидишь.
>до сих пор за ним сижу и даже твой коврик с надписью Palm Treo все еще юзаю. За это >время сменили мне тока моник, винт, мышку и клаву.
Да, насчет компа, у меня даже некоторое время были ностальгические чувства по нему. 🙂
Кстати, когда пытался узнать кому он достался.
Я сейчас в основном с notebook бегаю. Оно удобно когда все свое с собою.
>Сижу в твоем блоге уже часов пять наверное
Это приятно :))
Если, что, чтобы в блог не сорить можно пообщаться e-mail’ом. У меня vronin at consultant.com
Кстати, спасибо за комментирование.
«- Раз в некоторое время система контроля ошибок должна прочищаться»
Неплохо бы, чтобы тестеры перепроверяли устаревшие баги. Например чтобы баг-трекер высвечивал баги, которые были зарепорчены более, чем 2-3 версии назад (или если они выходят по 1-2 разу в день, то тогда по времени (2-3 недели)) и до сих пор не исправлены.
Да, именно так. А то получается, что висят баги открытые, зачастую assigned на людей, которые уже ушли год назад. Если баг важный — его надо исправлять, если он важный для release note — то перенести туда, а если не важный, то лучше закрыть.
По крайней мере — это мое виденье.
Я просто не люблю, когда есть сущности (не обязательно баги), которые не несут смысловой нагрузки.
Хотя по большому счету, при количестве открытых багов более чем по 100 штук на разработчика, нужен все таки человек, который специализированно работает на управлении потоком багов. Возможно, если проект не большой, чтобы такой спец объединял в себе и роль менеджера QA по проекту (не QC 🙂 ).
Мне кажется, это не нормальная ситуация, когда 100 багов на разработчика.
Я бы сказал, что средний разработчик должен знать что ему делать от 1 до 4 недель вперед.
100 багов, скорее 3 месяца вперед.
Всегда где я видел такие ситуации, часть багов не исправлялась никогда, опять же как я комментировал прошлый коммент. Не вижу смысла иметь сущности, которых нет смысловой нагрузки и которые не ведут к действиям или к знаниям.
cuxoedfo…
cuxoedfo…
Да простит меня автор, но статья ни о чем. То что тут напи-но известно и так. Выводов практически никаких. Какую цель преследвал автор неясно.