Организация тестирования.
Сразу оговорюсь, что вопрос не относится к моей реальной ситуации, а скорее навеян размышлениями над личным опытом. Итак, организация тестирования. Интересен опыт, как это делается у вас, от чего зависит выбор способа организации процесса тестирования, и что вы думаете по этому поводу.
Под тестированием подразумевается поиск багов в уже так или иначе работающем модуле, приложении, библиотеке и т.п., поскольку отладкой занимается чаще всего сам программист.
Под тестированием подразумевается поиск багов в уже так или иначе работающем модуле, приложении, библиотеке и т.п., поскольку отладкой занимается чаще всего сам программист.
Тестировщика/аусорсингового тестировшика. В плохом случае другого программиста, если ты его очень не любишь.
В той конторе, где я до недавнего времени работал, тестировать приходилось всё самому. Поэтому тратилось очень много времени и эффективность была чертовски невысокая.
Я тоже сам все тестирую, что сейчас, что до этого. Ну есть пользователи моего же софта у меня в конторе, но они не тестировщики!
Если говорить о этапах тестировнаия в нашей конторе. То -
Во время разработки пишуться разные наборы тестов. Это личное дело каждого, вещь не принудительная -- подотчетности нет, но обычно все гоняют код тестами.
Так как распределение работ построенно ввиде определенной иерархии (кто то пишет примитивы, кто то вспомогательную логику, кто то верхний общий уровень), то получается что люди выше по иерархии тестят косвенно чужой код.
Работаем мы над различными системами управления, поэтому отдельно обученный человек =) разрабатывает и реализует модель объекта управления. Потом на различных этапах на этом имитаторе происходят испытания.
В конце этапа разработки другой конторе отдаются алгоритмы (блок схемы алгоритмов должны покрывать весь код) и исходники. Она проводит валидацию и верификацию нашего кода. Это длительный (иногда до нескольких месяцев) процесс переписки и исправления кода, который собственно замыкается на начало повествования.
//--=== Не совсем про тестирование
Кстати, именно, по большей части, по этим причинам вот уже год пытаюсь перевести хоть что нибудь из проекта (хотя бы вспомогательные утилиты) под функциональный язык программирования с его REPL.
Кое какие соображения на эту тему из книги Practical Common Lisp. (перевод здесь).
Во время разработки пишуться разные наборы тестов. Это личное дело каждого, вещь не принудительная -- подотчетности нет, но обычно все гоняют код тестами.
Так как распределение работ построенно ввиде определенной иерархии (кто то пишет примитивы, кто то вспомогательную логику, кто то верхний общий уровень), то получается что люди выше по иерархии тестят косвенно чужой код.
Работаем мы над различными системами управления, поэтому отдельно обученный человек =) разрабатывает и реализует модель объекта управления. Потом на различных этапах на этом имитаторе происходят испытания.
В конце этапа разработки другой конторе отдаются алгоритмы (блок схемы алгоритмов должны покрывать весь код) и исходники. Она проводит валидацию и верификацию нашего кода. Это длительный (иногда до нескольких месяцев) процесс переписки и исправления кода, который собственно замыкается на начало повествования.
//--=== Не совсем про тестирование
Кстати, именно, по большей части, по этим причинам вот уже год пытаюсь перевести хоть что нибудь из проекта (хотя бы вспомогательные утилиты) под функциональный язык программирования с его REPL.
Кое какие соображения на эту тему из книги Practical Common Lisp. (перевод здесь).
Цитата:
Психологи выделяют состояние сознания, называемое потоком (поток сознания?), в котором мы обладаем немыслимой концентрацией и производительностью. Важность данного состояния при программировании была осознана в последние 2 десятилетия, с тех пор, как данная тема была освещена в классической книге о человеческом факторе в программировании «Эффективные проекты и команды» Тома Демарко и Тимоти Листера. Два ключевых факта о состоянии потока: требуется около 15 минут, чтобы войти в него, и даже короткие прерывания могут вывести из данного состояния, после этого требуется опять 15 минут на вход в него. Демарко и Листер, как и многие последующие авторы, концентрируются на исключении прерываний, разрушающих состояние потока, таких, как телефонные звонки и неподходящие визиты начальника. Меньше внимания обращается на не менее важные вещи — прерывания из-за инструментов, которые мы используем в своей работе. Например, языки, которые требуют долгой компиляции прежде, чем вы сможете запустить ваш код, могут быть не менее губительными для потока, чем надоедливый начальник или звонки по телефону.
Цитата: Phodopus
Я тоже сам все тестирую, что сейчас, что до этого. Ну есть пользователи моего же софта у меня в конторе, но они не тестировщики!
А по сути они и есть тестировщики. :) Конечно, смотря какой софт, смотря какие задачи, и смотря какие пользователи. У меня вот был проект сервера, который выполнял операции, связанные так или иначе с деньгами, а пользователи даже не знали, что такой сервер существует - для них существовала только услуга, предоставляемая через оператора связи. Соответственно, тут отдаваться на откуп пользователям очень дорого.
По сути любой пользователь тестировщик :), только не такой какой действительно нужен! Когда сам запускаешь прогу - ты ж тоже тестировщик :) Да только все это не то, не то.. На прошлой работе были достаточно серьзные и ужасно мутные проекты, тестировали все сами, начальство руководствовалось принципом "и так пойдет, хватит.." и подкидывало паралельно другую работу. Одна из причин почему ушел. Часто полдня разбирали чья же все-таки ошибка. На тихое предложение взять студента реакия была "они все тупые". Я хотел спросить, когда это мои коллеги так поумнели, хотя закончили универ 2-3 года назад, но не стал. Сейчас с начальством общий язык найден, но проекты пока закрытые (практически для внутреннего использования). Когда появится возможность их продавать (когда они "созреют") - обещали дать того кто будет тестировать и того кто будет писать документацию (пока без документации и с собственным тестированием). Аж не верится в такую сказку :)))
Мое мнение -- у программиста и тестера немного разный тип мышления. Синтез и анализ.
Несколько причин того, почему я считаю что полное тестирование кода программистами --- зло:
1) Тестеры обычно понятия не имеют, как работает внутри то, что им предлагают, и работают по принципу полного черного ящика.
2) Есть разделение технических деталей и четкого понимая бизнес-процессов, которые выполняются программой. Тестер не знает, как работает внутри код, который я написал для приложения в области знаний, например, логистики. Но он гораздо лучше меня знает саму логистику и требования к приложению (я так же стараюсь понимать бизнес-процессы как можно отчетливей, но определенные ограничения тут есть), и потому может придумать и проверить такие usecases, до которых мне не додуматься.
3) Высококлассные тестеры используют специальные методологии, без которых эффективность будет невысокая. И знать/понимать/уметь применять эффективно еще и эти методологии впридачу к девелоперским -- чересчур.
У нас первичное тривиальное тестирование производится программистами при написании (на уровне - ввел на странице число, нажал кнопку, ничего не упало, изменение значений в БД в соответствии с используемым алгоритмом зафиксировано, все со скринами и описаниями). Если есть время или критичная область приложения -- юнит тесты обязательно. Потом это все передается QA-отделу, который тестит все и потом все по полному циклу, см. TestTruckPro, и другие программы управления разработкой и качеством.
Несколько причин того, почему я считаю что полное тестирование кода программистами --- зло:
1) Тестеры обычно понятия не имеют, как работает внутри то, что им предлагают, и работают по принципу полного черного ящика.
2) Есть разделение технических деталей и четкого понимая бизнес-процессов, которые выполняются программой. Тестер не знает, как работает внутри код, который я написал для приложения в области знаний, например, логистики. Но он гораздо лучше меня знает саму логистику и требования к приложению (я так же стараюсь понимать бизнес-процессы как можно отчетливей, но определенные ограничения тут есть), и потому может придумать и проверить такие usecases, до которых мне не додуматься.
3) Высококлассные тестеры используют специальные методологии, без которых эффективность будет невысокая. И знать/понимать/уметь применять эффективно еще и эти методологии впридачу к девелоперским -- чересчур.
У нас первичное тривиальное тестирование производится программистами при написании (на уровне - ввел на странице число, нажал кнопку, ничего не упало, изменение значений в БД в соответствии с используемым алгоритмом зафиксировано, все со скринами и описаниями). Если есть время или критичная область приложения -- юнит тесты обязательно. Потом это все передается QA-отделу, который тестит все и потом все по полному циклу, см. TestTruckPro, и другие программы управления разработкой и качеством.
[QUOTE=Phodopus]Когда появится возможность их продавать (когда они "созреют") - обещали дать того кто будет тестировать и того кто будет писать документацию (пока без документации и с собственным тестированием). Аж не верится в такую сказку[/QUOTE]IMHO, это сказка ровно до тех пор, пока не ушёл человек, который всё это помнит. Всё, что сложнее того, что у вас начинает работать безупречно в течение рабочего дня, должно быть задокументировано и протестировано. В конторе, которую я покинул этой весной, имелся как минимум один внутренный продукт, которым без обучения пользоватся было невозможно, а обучение проводил лично генеральный директор, по совместительству разработчик этого продукта. Мало того, что он тратил своё время на объяснение того, что можно было написать и прочитать в документации; так он ещё и обновлял продукт и не утруждался вести чейнджлог, а это порождало недокументированные несовместимости.
У вас генеральный пишет???
Я в последнее время как-то критически отношусь к процессам, не имеющим планирования и документации, независимо от того - это разработка программного продукта, базы данных или тестирование. Правильней, конечно же писать программу, да и вообще любую ее часть под какой-нибудь "набор тестов", заранее описаный в плане. Следовательно, чтоб не получалося разнобоя, тестировщик должен с самого начала по проектной документации писать план тестирования, и по мере написания модулей - проводить тесты на предмет соответствия действительности с планом. Если тестирование не поставлено в самой основе, то вряд-ли оно будет качественным, и уж быстрым оно тоже вряд-ли будет.
Про организацию тестирования есть хорошие книги, из которых можно извлечь много полезной информации:
1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. "Тестирование программного обеспечения."
2. Robert Culbertson, Chris Brown, Gary Cobb "Rapid Testing"
Я работаю тестером(недавно) в аутсорсинговой компании, которая занимается тестированием, и нам очень рекомендуют эти книги к прочтению.
1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. "Тестирование программного обеспечения."
2. Robert Culbertson, Chris Brown, Gary Cobb "Rapid Testing"
Я работаю тестером(недавно) в аутсорсинговой компании, которая занимается тестированием, и нам очень рекомендуют эти книги к прочтению.
[QUOTE=Zorkus]У вас генеральный пишет???[/QUOTE]Ну, уже не у нас... :) Но в той организации он среди прочего ещё и писал эту чёртову VsApp. Может быть и сейчас пишет, только я не в курсе. Вообще говоря, фирма загибается плавно, разработчики уходят, и как тот генеральный собирается выживать - тот ещё вопрос, но это к делу не относится.