От writer123
К Hokum
Дата 01.02.2012 18:15:09
Рубрики Современность; Космос;

Re: У всех,...

>Два человека (или две группы) пишут код. Все прекрасно работает само по себе. При попытке совместить это внутри одной системы лезут косяки, поскольку начинается драка за общие ресурсы или еще что. На каком этапе самотестирования Вы это отловите?

Совместное самотестирование провести кто запрещает?
Даже если вы это отдадите тестировщикам, то на выходе у вас будет всё равно описание типа "такие-то мои действия привели к ошибке, которая выражается в ... и ..., вот такой был вывод, вот такое состояние" ну и т.п.
Что дальше? Дальше придётся взять те же две группы, посадить их вместе, запустить им всё это, повторить ошибку самостоятельно и совместно искать её до опупения.
Достаточно редко удаётся найти и устранить ошибку в коде со слов тестировщика/лица, выполняющего эту функцию, обычно для этого программистам требуется самостоятельно воспроизвести ошибочную ситуацию.
У наличия тестировщика тут два плюса - он берёт на себя рутинную работу, которой не шибко-то хочется заниматься сверх необходимого, и он тестирует не зная, как должна работать система. В этом же и его минусы.
От Hokum
К writer123 (01.02.2012 18:15:09)
Дата 01.02.2012 19:56:11

Похоже, надо начинать с терминологии

Вот стандартные определения из учебника:
Unit testing. Модуль или компонент работает в соответствии со спецификациями.
Integration testing level 1. Борт ФГ, собранный из протестированных модулей и компонентов, работает в соответствии со спецификациями.
Integration testing level 2. Полностью протестированный борт ФГ взаимодействует с системами космодрома и ЦУП в соответствии со спецификациями.
Regression testing. Повторное тестирование всех зависимых систем и подсистем после внесения изменений в одну из них после тестирования.
Concurrency testing. Мы запускаем два ФГ одновременно - смогут ли космодром и ЦУП это обеспечить? Есть ли разнесение по стартовым столам, бункерам, частотам? (Для ФГ не критично - а, скажем, для систем продажи авиабилетов - ключевое требование).
Performance testing. Сколько ФГ нужно запустить для насыщения системы, и где узкое место? Число стартовых столов, бункеров, персонала или кресел в ЦУП? (Актуальность - см. предыдущий пункт).
Penetration testing. Американцы пытаются взломать канал управления, ослепить ФГ лазером или пучковым оружием, сбить ракетой ASAT, погрузить в Шаттл и увезти на мыс Канаверал - что мы можем этому противопоставить?
User acceptance testing. Финальный этап тестирования, проводимый заказчиком. Достаточно ли информации у оператора ЦУП, можно ли запросить дополнительную, можно ли вмешаться в процесс и на каких этапах, достаточно ли информативны сообщения об ошибках и отказах...
Вопрос - какие из указанных видов тестирования входят в понятие "самотестирование"?
От writer123
К Hokum (01.02.2012 19:56:11)
Дата 01.02.2012 20:25:28

Что сказать-то хотели?

Много красивых слов, в т.ч. про систему продажи авиабилетов, а что хотели сказать ими?
С тем, что на каком-то уровне самотестирование невозможно и нужно организовывать испытания тем или иным способом - и так очевидно, дальше-то что?
Если уж начали с определений - тогда определитесь сначала, что вы тестируете - программное обеспечение борта, или КА как аппаратно-программный комплекс. А то у вас тут сплошь речь о КА в целом, а это проблема опять же куда шире чем одно лишь тестирование ПО, о котором вроде бы речь в ветке.
От Hokum
К writer123 (01.02.2012 20:25:28)
Дата 01.02.2012 21:06:23

Re: Что сказать-то...

Мы проводим тестирование программно-аппаратного комплекса "Фобос-Грунт". Который передается заказчику как единое целое и должен взаимодействовать с его системами (кораблем, службами космодрома и ЦУП) в соответствии с утвержденными спецификациями.
Программное обеспечение является частью комплекса, а программа его тестирования - частью программы общего тестирования, органически туда вписанной.
А слова "самотестирование" я не знаю.
От Павел Войлов (Т-28А)
К writer123 (01.02.2012 18:15:09)
Дата 01.02.2012 19:07:56

Делать надо все хорошо, плохо оно и само получится (с)

Приветствую,

>Совместное самотестирование провести кто запрещает?
>Даже если вы это отдадите тестировщикам, то на выходе у вас будет всё равно описание типа "такие-то мои действия привели к ошибке, которая выражается в ... и ..., вот такой был вывод, вот такое состояние" ну и т.п.
>Что дальше? Дальше придётся взять те же две группы, посадить их вместе, запустить им всё это, повторить ошибку самостоятельно и совместно искать её до опупения.

Это плохой вариант, на который ориентироваться нельзя. В нормальной команде QA Engineer иногда знает код даже лучше разработчиков, способен его исследовать и в багрепорте указать путь (или пути) его исправления с кодом/псевдокодом. И должен быть готов самостоятельно эту ошибку исправлять. Фактически же суть ошибки и ответственного (этого тестера или другого, разработчика этого или другого) за ее исправление назначают на Defect Triage совместно руководитель разработчиков и руководитель тестеров.

>Достаточно редко удаётся найти и устранить ошибку в коде со слов тестировщика/лица, выполняющего эту функцию, обычно для этого программистам требуется самостоятельно воспроизвести ошибочную ситуацию.

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

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

Почему не зная? Тестировщик вообще-то даже более широкий кругозор может иметь чем девелопер, потому что при реализации разнообразных AE, поз/нег сценариев и ручных харнессов вполне может работать с несколькими модулями или системой в целом - в отличие от разработчика, который погружен на 1-2 текущие задачи.
Ну если конечно девочек задешево в QA набирать, то тогда да.

С уважением, Павел
От writer123
К Павел Войлов (Т-28А) (01.02.2012 19:07:56)
Дата 01.02.2012 19:48:40

Re: Делать надо...

>Это плохой вариант, на который ориентироваться нельзя.
Это самый реальный вариант. Тот, который вы описываете - очень дорогой и сложный.

>В нормальной команде QA Engineer иногда знает код даже лучше разработчиков, способен его исследовать и в багрепорте указать путь (или пути) его исправления с кодом/псевдокодом.
Каков будет КПД его работы по исследованию и отладке чужого кода?
Программистам всё равно придётся проверять то что он там нашёл и наисправлял и согласовывать представления тестировщика о том как работает проект с тем, как он реально работает.

>И должен быть готов самостоятельно эту ошибку исправлять.
Это плохо кончится.

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

>В багрепорте должен приводиться полный путь воспроизведения и/или воспроизводящий код/бинарь.
Должен, поскольку без него толку с такого тестирования вообще негусто. Однако же далеко не всегда этот путь будет и будет корректен.

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

>Почему не зная?
Потому что если он тестирует зная - то это либо путь вникуда (он знает, как всё должно работать и ровно так же, как и сами программисты тщательно убеждается в том, что оно работает так, как задумано - неработа его не интересует), либо штучный человек особого склада ума.

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

>Ну если конечно девочек задешево в QA набирать, то тогда да.
Дык а в реальности задёшево и набирают.

На самом деле все эти вещи имеют право на жизнь, но не являются чудесным решением всех проблем, которым их сейчас принято представлять. И создают ряд новых самодостаточных проблем. Разумный подход нужен. А когда он есть - это уже частности.
От Павел Войлов (Т-28А)
К writer123 (01.02.2012 19:48:40)
Дата 01.02.2012 20:25:38

Re: Делать надо...

Приветствую,

>Это самый реальный вариант. Тот, который вы описываете - очень дорогой и сложный.

Мы Фобос-Грунт за N миллиардов(онов) запускаем или курсовые по программированию на заказ делаем? Тот вариант, который я описываю, реально работает в весьма средненьких компаниях, правда, профессионально занимающихся разработкой софта, а не высоколобой наукой. Ну так может быть надо было профессионалам отдать разработку ПО?

>Каков будет КПД его работы по исследованию и отладке чужого кода?

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

>Программистам всё равно придётся проверять то что он там нашёл и наисправлял и согласовывать представления тестировщика о том как работает проект с тем, как он реально работает.

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

>Это плохо кончится.

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

>Угу, и в итоге ответственными и исправляющими становится программисты, что я и описал ранее. Только с целой процедурой по маканию их в собственные косяки.

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

>Должен, поскольку без него толку с такого тестирования вообще негусто. Однако же далеко не всегда этот путь будет и будет корректен.

Эти тривиальные вещи как-то опровергают то, о чем я говорю?

>Вы написали своими словами то что описал и я. Всё равно в конечном итоге эти две группы сядут, будут воспроизводить, искать и придумывать, как исправить.

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

>Потому что если он тестирует зная - то это либо путь вникуда (он знает, как всё должно работать и ровно так же, как и сами программисты тщательно убеждается в том, что оно работает так, как задумано - неработа его не интересует), либо штучный человек особого склада ума.

Это какие-то абстрактные рассуждения, какое отношение они имеют к решению поставленной задачи? Нет ресурсов или не умеем - не беремся.

>Может, но тогда см. выше.

Что именно выше? Девочек не нанимать? В некоторых проектах нужны как раз девочки - по соотношению цена/качество - но не в Фобос-Грунте.

>Дык а в реальности задёшево и набирают.

Ну, мышам можно порекомендовать не кушать кактус. Лишать их этого священного права или вырывать его у них из глотки никто и не собирается.

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

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

С уважением, Павел
От doctor64
К Павел Войлов (Т-28А) (01.02.2012 19:07:56)
Дата 01.02.2012 19:36:58

Подписываюсь под каждым словом.

Дополню, что в моей мелкой конторе, делающей чипы для связи, тест девелоперы зарабатывают побольше многих фирмварщиков.
От KGI
К writer123 (01.02.2012 18:15:09)
Дата 01.02.2012 18:36:59

Re: У всех,...

>У наличия тестировщика тут два плюса - он берёт на себя рутинную работу, которой не шибко-то хочется заниматься сверх необходимого,

так времени хоть отбавляй на самотестирование.

> и он тестирует не зная, как должна работать система.

А вот это плюс сомнительный. Значительная(но не все) часть его отчетов говорит о том, что человек толком не разобрался но думает, что что-то здесь неправильно. Кстати такой тестировщик всегда есть - ответственный сдатчик называется:). Особенно если он новый и малоопытный. Его когда оставляют на заказе одного без программистов, он начинает нажимать на кнопки сам, и тут же начинает генерить. В принципе его вполне достаточно в качестве отдела тестирования.
От writer123
К KGI (01.02.2012 18:36:59)
Дата 01.02.2012 18:47:22

Re: У всех,...

>так времени хоть отбавляй на самотестирование.
Желания обычно нет. Процесс нудный и неинтересный.

>А вот это плюс сомнительный. Значительная(но не все) часть его отчетов говорит о том, что человек толком не разобрался но думает, что что-то здесь неправильно. Кстати такой тестировщик всегда есть - ответственный сдатчик называется:). Особенно если он новый и малоопытный. Его когда оставляют на заказе одного без программистов, он начинает нажимать на кнопки сам, и тут же начинает генерить. В принципе его вполне достаточно в качестве отдела тестирования.
Согласен, потому и написал что это же и является минусом.
Но всё равно - когда знаешь, как всё устроено - подсознательно тестируешь так, как оно ДОЛЖНО работать (личностей, которым изначально хочется что-то сломать в рассмотрение не берём), когда не знаешь - больше шансов как раз (в т.ч. и почти случайно) выявить нетривиальную проблему, не принятую во внимание никем. Другой вопрос, что, вполне вероятно, попутно он загрузит всех устранением десятка несуществующих проблем. :)
От Claus
К writer123 (01.02.2012 18:47:22)
Дата 01.02.2012 21:59:04

Re: У всех,...

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