вторник, 16 августа 2011 г.

Промышленный контроль и тестирование ПО.

У Лены активное обсуждение выступления Сергея Мартыненко с мыслью, что при тестировании требований от последующего тестирования можно и отказаться. В ходе разговора была высказана мысль, что вот в промышленном же производстве контроль охватывает дай бог, если 1 %  продукции...

Сравнение промышленного производства и разработки ПО - далеко не ново. И в нем хотелось бы обратиться к основоположнику TQM Э.Демингу.

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

Уровень ошибок также закладывается системно - начиная с требований и спецификаций. И поэтому лучше, чем позволяет система исполнитель сделать не может. В переводе на разработку ПО - при непоставленных процессах разработки и тестирования конкретный программист мало что может сделать (такая ситуация как правило сопровождается дедлайнами, внутренним напряжением и т.д., когда сделать правильно "времени нет").

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

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

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

А в целом, как всегда. Главное с водой не выплеснуть ребенка. Выстраивать систему надо с момента согласования с заказчиком и спецификаций, но это не значит, что не надо заниматься и всеми остальными процессами. В том числе и тестированием.

3 комментария:

  1. тестирование требований поможет избежать в договоренности с заказчиком необоснованных обещаний и в формулировании техзадания "необоснованных требований".
    однако даже при идеальных требованиях надо все равно протестировать соответствует ли продукт утвержденным требованиям и сформулированному техзаданию

    ОтветитьУдалить
  2. Честно говоря, не совсем поняла мысль, к которой Вы вели: был сделан ряд сравнений разработки ПО и промышленного производства - и к чему Вы пришли в итоге? Мысль про "не выплеснуть ребёнка" ясна, но это - общая мысль. А вывод по поводу сравнения какой-либо Вы имели в виду? Можете пояснить, пожалуйста? О-)

    ОтветитьУдалить
  3. Lena, мысль - сравнивать можно, но аккуратно) Бо специфика)

    ОтветитьУдалить