Тестовая сессия авионики в «Контур-НИИРС»
Мы уже неоднократно говорили об идее провести силами сообщества тестовую сессию, и вот наш первый опыт. Большое спасибо Елене Радиловой за инициативу и руководству и сотрудникам ООО «Контур-НИИРС» за готовность участвовать в эксперименте.
Скажу сразу, что основной целью данной тестовой сессии было не протестировать ПО, а дать возможность разработчикам принимающей стороны пообщаться с тестировщиками, обменяться опытом. Специфика компании в том, что у них все ПО — встроенное, и продаются комплексы, а не само ПО. Всего мы там пробыли два часа, и у меня сложилось впечатление, что цель была успешно достигнута.
Вначале главный конструктор познакомил нас с компанией, рассказал, что она производит, для кого, какова специфика производства. Нас поводили по помещениям, показали реальные устройства. После этого мы разделились по парам, и нас познакомили с объектами тестирования.
Дальше мы изучали устройства и софт, общались с разработчиками, радовались найденным дефектам 
К концу сессии нашли несколько ошибок, составили список замечаний и предложений по доработке. Надеюсь, затронули нужные струны в сердцах руководства и разработчиков, и они задумаются о перспективах тестирования своих продуктов, потому что сейчас они в основном занимаются отладкой.
Надеюсь, мы помогли в достижениях поставленных целей! Сами мы очень интересно и познавательно провели время, еще раз спасибо Елене за инициативу!
Полный фотоотчет.
| Рассказать друзьям: |  LinkedIn |
 Twitter |
 Facebook |
 Вконтакте |
 LiveJournal |
 LiveInternet |
 Я.ру |
 Blogger |
 Мой Мир |
А тест план вы с ними не разработали?
Риски качества не выявляли?
Процесс разработи не изучали в контексте этих рисков?
Спрашиваю, потому что не очень понятна ценность действий: 1. узнал программу, 2. потыкал, 3. нашёл ошибку…
Ценности в подобных действиях нет ни для профессионала, ни, часто, для компании в которой это делается.
Руководители подобных предпрятий и групп разработчиков, часто, сидят и смотрят на тестировщиков и считают их
по головам и прикидывают сколько денег они сейчас экономят не платя им зарплату и получая.
И пока не будет «доказано», или хотя бы «показано», что обеспечение качества может генерировать прибыль/стоимость,
руководители далёкие от понимания и веры в качество будут оставаться при своём.
Увы, проверено практикой.
Именно поэтому я писал второй абзац: «Скажу сразу, что основной целью данной тестовой сессии было не протестировать ПО…» Чтобы составлять тест-план, выявлять риски и заниматься прочей серьезной работой, надо было приходить на недельку, а не два часа.
я прочитал и тоже не один абзац написал
смысл других абзацев, что привнести современные представления об управлении качеством на такие предприятия достаточно тяжело и начинать его с демонстрирования свободного поиска багов — это очень слабый заход (по моему опыту).
Про цели, результаты и прочее ЗАЧЕМ?
1. Идея была моя. Мотивация моя – мне интересно было вот такое устроить (почему для меня «интересно» — вполне себе мотивация см. диалог в нашей группе на фасебуке про мотивацию)
2. Цели для нас, которые потом сформулировались :
2.1 Софт у нас специфичен, коллектив разработчиков небольшой. Нужен был какой-то толчок, импульс снаружи.
2.2 У нас появилось новое направление – Windows-программы стали объектом продаж. А опыта разработки на продажу Windows-программ пока очень мало.
2.3 Чистых тестировщиков вообще нету. Что привносит специфику.
2.4 Хотелось расширить /изменить представление руководства фирмы о тестировании.
3. Цели для гостей.
Если нашим гостям было интересно – то это уже цель. Почему бы и нет?
4. Что получилось.
4.1. Импульс получился. Во всяком случае разговор про автоматическое тестирование со стороны выглядел очень живо.
4.2 Про Windows-программы. Гости ЛЕГКО показали парочку багов. Мастер-класс! Спасибо! Вживую показали специфику!
4.3 К сожалению, ребята с участка настройки, которые занимаются тестированием, не смогли поучаствовать (была срочная работа). На следующий день мне от них немножко досталось : «Почему пришли гости в такое время? И почему так мало времени были на фирме?! Мы хотели бы с ними поговорить!» (иэх… ну да, настройщик – это элита, которая себя уважает! )
4.4 За баги – спасибо! (хихикает… нюанс: одна команда гостей оставила аккуратный лист с пронумерованными багами на столе. Вторая команда … в общем я сама нашла один листочек с одной багой, Александр вчера выкопал из под проводов и железа еще лист с тремя багами – ну да, я всегда знала, что сильный пол обожает железки!). Занесла все в баг-трекинг с пометкой «гости нашли».
4.5 На следующий день руководство присело у моего стола и с интересом выслушало отче. Вчера еще разговор с руководством. Вполне вероятно, что у фирмы будет большая заказная работа. !!!! И руководство стало рассуждать – что надо бы набрать тестировщиков, которые занимаются только тестированием!! И что хорошо, что приходили гости!!!
1. А тест план вы с ними не разработали?
Риски качества не выявляли?
==============================================
Ой!
Это надо экспертов на работу приглашать на пару месяцев! А не гостей на пару часов!
Ну пишу я сейчас тест-план под новую разработку. Написала пункт -»Стенды». С железом — понятно. А вот софт для стенда! А этот софт тож проверять надо! эээ… кто-нибудь хочет в гости (кофе, сахар и сушки! будут!) на парочку часов поговорить про тест-план?
2. пока не будет «доказано», или хотя бы «показано», что обеспечение качества может генерировать прибыль/стоимость
===============================
Собственно, качество нашей продукции масса факторов обеспечивает. Тестирование тут, на стендах- имитаторах — это начальный этап проверок софта.
Если хотите — -первая линия обороны.
[...] сессия авионики в «Контур-НИИРС». Об этом есть отчет на сайте [...]
Контур-НИИРС ни разу не государственная компания. Что зарабатываем на продажах, на то и живем.
Техника наша востребована, так что качество техники эксплуатантов устраивает.
Причем востребована в условиях достаточно жесткой конкуренции. Со стороны тех же американцев.
Проблема в том, что качество это сильно дорого обходится. И обеспечивается целым комплексом мероприятий.
Если брать мааааленький кусочек — тестирование ПО, то получается, что тестирование одного и того же функционала занимаются несколько человек. Параллельно.
Так, МФИ (абсолютно сырую версию ПО которого тестили наши гости) проверяют два-три человека.
Затратно, ага. А МФИ — это уровень ПО «не влияет на безопасность полетов».
ПО уровня 1 (ойойойо… страшный сон, да есть такой блочок у нас с крайне ехидным ПО!!) проверялось на наших стендах — три человека, на стендах сторонней организации — еще два человека со стороны и бригада от нас….
Плюс испытания летные. Ну там просто тьма людей задействована.
Элементарная вещь — ввод с клавиатуры. Проверялась тут, проверялась на стендах сторонней организации, проверялась….проверялась.., и в завершении проверялась на борту самолета по специально разработанной методике штурманом-испытателем (методика не нами разрабатывалась, а комиссией! ) . уфф….
Что есть работа на летных испытаниях человека от нас — сейчас фото куда-нибудь приспособлю.
Поэтому сейчас есть такая маааленькая цель — тестирование ПО на стендах фирмы как-то оптимизировать.
Ну чтоб хотя бы не по три человека, и не так долго как сейчас!
Не стене в фасебуке выложила.
Работа на летных испытаниях. По уровня 1 — катастрофическое.
Хорошо хоть функционал небольшой…
Спасибо за дополнения, картина становится целостней.
Тест план — не обязательно большой документ, а риски качества не обязательно снимаются тестированием. В смысле эффективности затрат ресурсов автоматизация часто стоит не на первом месте. Разобрать это всё как раз и замечательно на первой встрече.
Всё-таки вашему руководству нужно познакомиться ещё с какими-нибудь qa менеджерами у которых есть успешный опыт в работе с программно-аппаратными продуктами, т.к. тестирование оно конечно повышает качество, но комплексный подход может обеспечить ещё лучшие результаты.
Чтобы предложения исходящие из QA имели шансы быть применёнными — исходить они должны от авторитетного человека производящего хорошее впечатление на остальных руководителей процесса разработки.
т.к. тестирование оно конечно повышает качество, но комплексный подход может обеспечить ещё лучшие результаты.))))
угу. Кто б спорил.
Есть задумка — стандартизовать Требования ПО. Ну это я в качестве техписа мечтаю… может и смогу за ближайший год разрисовать — что, как, в каком порядке и какими словами.
Что обидно — Тех Задание на блоки в целом собственно все однотипные, стандартными фразами, со стандартной структурой, а в вот Требования к ПО — мама мия….(хихикает — ну прям в любых стилях!)
УРЯЯЯЯЯЯ!!!!!!!!!!!!!!!!!!!!!!
Лед тронулся, господа присяжные заседатели!!!!!
Сейчас подошел комплексник (т.е. в терминах форума софтваре — аналитик) и ПОПРОСИЛ!!!!!
Список багов из старой версии!!!
Ну дык… это не МФИ, которое уважаемые гости к нам приходили тестить.
Это — локатор.
Где проверку в основном проводят Суровые Мужики-настройщики, и не менее суровые комплексники!!
Уф… баги пока записывают спицифически… но ничего-ничего!!
Зачем баг-трекинг уже прочувствовали.
Проблема пока основная в том, что если что-то всплывает ВНЕ озвученного «я тестирую новую версию ПО» то…
пока делают так:
«Слышь, Лен. Тут вот такое вылезло, ты там запиши где-нить!»
Пишу баг так: — «Со слов Иван Иваныча…… »
Уф…..
Здорово, что налаживается! Успехов!
Если будет надо, можно еще людей собрать, устроить тестирование посерьезнее