Your SlideShare is downloading. ×
Тестирование для программистов
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Тестирование для программистов

189
views

Published on

Рассказ с ДевелоперГаража про тестирование для программистов

Рассказ с ДевелоперГаража про тестирование для программистов

Published in: Engineering

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
189
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Если сравнить и не брать в рассчет колонки, и что прыгает немного картинка, то отличие серьезное одно – вместо eshop Online Shop и в селекторе страна болдом. Хрен с ним с селектором. Но пункт меню отломал часть тестов на последовательность и состав меню.
  • А вот теперь пробем стало гораздо больше. До свидания старая DOM-модель, здравствуй новая, очаровательная.
  • Тестирование контента. К сожалению, к составу контента маркетологи очень требоваетельны. По их науке даже небольшое изменение в тексте роняет или возносит продажи на непомерные высоты. Т.к. все страницы разные, первой идеей было - "а давайте сравним то, что получилось с предыдущей версией сайта". Т.е. по сути воспользуемся подходом тестирования на базе эталонов и попробовать найти ответ на вопрос - "так ли новая кажет, как старая казала". По началу так и делали. В результате потратили кучу времени, т.к автоматически проверять контент оказалось еще сложнее. Дальше решили всех обмануть и проводить тестирование по принципу "работает ли новая система корректно". Т.е. по сути приватизировав право на валидацию. От этой идеи тоже очень быстро отказались, т.к. на русский и английский языки хватило, а вот испанский и итальянский подкачали. Не нашлось носителей языка среди команды миграции. По сути работа миграторов свелась к тому, что проверить, все ли компоненты (картинки, стили и т.д. ) присутствуют и корректно отображаются на странице. А роль читателей отдали носителям языка из группы контент-редакторов. С блоками продаж поступили немного не так: отдали валидацию сотрудникам региональных отделов продаж. Они проверяли корректность работы сайта с интернет-магазинами, настраивали свои трекеры и, заодно, вычитывали тексты и проверяли, что картинки соответвуют дейтсвительности.
  • Ведь есть же старый сайт. Он то точно правильно работает. Тут же напоролись на то, что работает то он нормально, но вот контент битый. Где очепятка, где картинка не та. Это свойственно системам, где контент контролируется редакторами и не проходит достаточную проверку перед публикацией.
  • Ведь есть же старый сайт. Он то точно правильно работает. Тут же напоролись на то, что работает то он нормально, но вот контент битый. Где очепятка, где картинка не та. Это свойственно системам, где контент контролируется редакторами и не проходит достаточную проверку перед публикацией.
  • Не всегда это подходит.
  • Большие объемы контента. Ребята из саппорта применили неведомый нам доселе прием и не стали сразу запускать новый сайт в продакш, а разрешили нам запустить его в так называемой "бете", чем сделали нам тестирование прогулкой под луной, а не забегом под метеоритным дождем. Что нам это дало - фактор суеты был уничтожен. В результате сейчас в паблике ворочаются оба сайта - старый и новый, не сильно отличающиеся по контенту. При этом новый вежливо просит с вас фидбек. Ура. Мы за бесплатно получили некоторое количество бета-тестеров. Люди пишут отзывы, люди находят баги. Но это баги в бете:)  Даже те, кто не пишет баги - тыкают странички, контролы, формочки. А еще афигенная тема признавать свои ошибки - т.е. если пользователь натыкался на несуществующую страницу или на битый контрол (дя, мы иногда отдаем 40е и 50е, но под картинку с извинениями). А еще ниже картинки - письмо разрабу/тестеру, что что-то отвалолось и можно что-то откопать по горячим следам. Функциональное тестирование: ничего умнее не придумали, как сравнение с эталоном. Старый сайт в рабочем состоянии, вот с ним и сравнивали. Объекты для сравнения выковыривали заранее. Т.к. сайт саппорта не является чем-то высокотехнологичным - таких объектов нашлось не очень много. Были правда и те, которые были созданы с нуля. Их пинали по полной и по всем правилам науки.Контролы и прочий функциональный стаф. При условиях работы сайта под естественной нагрузкой - немного более агрессивное логгирование с нотификацией в почту о критических сбоях (да, оно тормозит время отклика, но мы в бете:)) в компонентах залог нахождения объяснения очень интересным эффектам, на получение которых в лабораторных условиях ушло бы очень много времени. Т.о. мы и тут не ушли от классической науки, применив так назывваемое "soak-тестирование" - тестирование системы в естественной среде обитания под естественными нагрузками. Что касается внутреннего тестирования, которое мы, естественно проводили, подход был выбран такой - чтобы не проверять глазками 7, 5К статей, отсортировали их по рейтингу (старая система исправно считала гвозди) и начали проверять сверху вниз. Плюс ребята из саппорта очень дисцеплинированные - привлекают свои локальные офисы, тыкают сами, пишут баги и т.д. 
  • Ребята из саппорта применили неведомый нам доселе прием и не стали сразу запускать новый сайт в продакш, а разрешили нам запустить его в так называемой "бете", чем сделали нам тестирование прогулкой под луной, а не забегом под метеоритным дождем. Что нам это дало - фактор суеты был уничтожен. В результате сейчас в паблике ворочаются оба сайта - старый и новый, не сильно отличающиеся по контенту. 
  • Не всегда это подходит.
  • Не всегда это подходит.
  • Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
  • Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
  • Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
  • Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
  • Дальше немного про то, что мы использовали, чтобы облегчит себе жизнь
  • Группировка контента и постоянные демы. Использование ресурса заказчика на все проценты
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
  • Рассказать про то, что в команде нет выделенного тестировщика, но это совершенно не значит, что нет тестирования.
  • Да, это может снизить производительность системы, но, для этого есть следующий инструмент. Но все это ради следующего инструмента. Это ведь совсем не сложно. Тут вариантов использования куча целая.
  • Это было наверное самое ценное предложение из всех. Для всех участников процесса сценарии были сделаны одинаковыми. Составленные в наиболее удобоваримой форме – степ-бай-степ с привлечением маркетинга и саппорта, которые стопитсот лет назад построили эти сценарии на основе статистических данных, собранных на миллионах пользователей. С ними же собрали перечень критичексих для бизнеса страниц, на которые уделяли наибольшее внимание.
  • Уаля. Вопрос регрессии решен.
  • Нагрузка. Использовали JMeter в распределенном исполнении и ab. Запаса по производительности у серверов прилично, поэтому в основном силы тратили на снижение ресурсоемкости операций. Плюс к этому нагло пользовались распределенной архитектуров системы. На серверах-балансерах включали и выключали ноды, предварительно настроив системы мониторинга (тут кстати стоит отметить, что сами системы мониторинга, особенно с включенным графическим модулем, сильно поедают ресурсы). Т.о. мы получали возможность наблюдать за поведением сервера при реальных нагрузках (имеетсч ввиду реальное поведение пользователя, который приходит на индекс, затем топает в поиск, потом переходит в продуктовые блоки и т.д.) При этом опять же усиливали логирование. Это конечно не очень правильно, но определенных успехов в поимке слабых мест в системе достичь удалось. Почему не достигали на берегу? Потому что система из коробки, с чрезвычайно нетипичным поведением в некоторых ситуациях. Кстати, вот эти чуваки https://browsermob.com/ абсолютно бесплатно предлагают померять время отдачи контента из разных точек, но и напихали на сайт много интересной информации. А еще можно зарегистрироваться и получить еще кучу плюшек. 
  • Нагрузка. Использовали JMeter в распределенном исполнении и ab. Запаса по производительности у серверов прилично, поэтому в основном силы тратили на снижение ресурсоемкости операций. Плюс к этому нагло пользовались распределенной архитектуров системы. На серверах-балансерах включали и выключали ноды, предварительно настроив системы мониторинга (тут кстати стоит отметить, что сами системы мониторинга, особенно с включенным графическим модулем, сильно поедают ресурсы). Т.о. мы получали возможность наблюдать за поведением сервера при реальных нагрузках (имеетсч ввиду реальное поведение пользователя, который приходит на индекс, затем топает в поиск, потом переходит в продуктовые блоки и т.д.) При этом опять же усиливали логирование. Это конечно не очень правильно, но определенных успехов в поимке слабых мест в системе достичь удалось. Почему не достигали на берегу? Потому что система из коробки, с чрезвычайно нетипичным поведением в некоторых ситуациях. Кстати, вот эти чуваки https://browsermob.com/ абсолютно бесплатно предлагают померять время отдачи контента из разных точек, но и напихали на сайт много интересной информации. А еще можно зарегистрироваться и получить еще кучу плюшек. 
  • Они все делают сами. Даже сценарии писать не надо.
  • Дальше немного про то, что мы использовали, чтобы облегчит себе жизнь
  • Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
  • Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
  • Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
  • Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
  • Серьезность. Насколько опасен отказ системы из-за какой-то части функционала? Приведет ли это к потере данных?Приоритет. На сколько силен будет эффект от отказа системы повлияет на пользователей и их лояльность продукту?Вероятность. Какова вероятность того, что пользователь таки воспользуется именно тем куском функционала, который не до конца работает?
  • Серьезность. Насколько опасен отказ системы из-за какой-то части функционала? Приведет ли это к потере данных?Приоритет. На сколько силен будет эффект от отказа системы повлияет на пользователей и их лояльность продукту?Вероятность. Какова вероятность того, что пользователь таки воспользуется именно тем куском функционала, который не до конца работает?
  • Серьезность. Насколько опасен отказ системы из-за какой-то части функционала? Приведет ли это к потере данных?Приоритет. На сколько силен будет эффект от отказа системы повлияет на пользователей и их лояльность продукту?Вероятность. Какова вероятность того, что пользователь таки воспользуется именно тем куском функционала, который не до конца работает?
  • Вдруг повезет
  • Вдруг повезет
  • Вдруг повезет
  • Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
  • Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
  • Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
  • Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
  • Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
  • Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
  • Метод достаточно сложный, основан на определении потенциальных проблем, оценки их влияния, а затем выполнении классификации по серьезности, приоритетности и вероятности возникновения дефекта.В классическом исполнении предполагается оценка потенциальных ошибок по четырем критериям: серьезность, вероятность, приоритетность и обнаружаемость, причем каждый критерий может варьироваться в различных диапазонах для увеличения или уменьшения точности. Таким образом, вероятность может оцениваться по шкале начинающейся с 1 (наибольшая вероятность) и заканчивающейся Х (наименьшая вероятность). Промежуточные значения и их количество определяются исходя из требуемой точности для конкретного проекта. В итоге получается для каждого типа ошибок четыре числовых значения. Их произведение дает приоритет риска, который может принимать значение от 1 до Y. После этого определяются рекомендуемые действия по снижению рисков. Общая шкала значений делится на количество выделенных категорий, в результате каждой ошибке сопоставляется то или иное действие для уменьшения её эффекта. В общем это не для слабонервных, а в условиях, когда надо занижать, а не увеличивать, вообще может не подойти.
  • На этом месте обычно слайд «Вопросы», но из-за него никогда не получается срисовать контакты выступающего. Поэтому я его упразднил. Большое спасибо за внимание, перезжайте аккуратно, и да прибудет с вами сила! Вопросы
  • Transcript

    • 1. Тестирование программистов для
    • 2. О чем я хочу поговорить • Почему вдруг эта тема? • Проблемы? • Примеры есть? • Как бы себе помочь? • Как бы им помочь?
    • 3. Есть ли среди тестировщики?
    • 4. Есть ли среди вас разработчики?
    • 5. Очень приятно, что не только нам все это интересно
    • 6. Будьте бдительны:
    • 7. Почему вдруг эта тема?
    • 8. Почему вдруг эта тема? Видели, как экономят на тестировании?
    • 9. Почему вдруг эта тема? Видели, как экономят на разработке?
    • 10. Почему вдруг эта тема?
    • 11. Почему вдруг эта тема? Почему так происходит?
    • 12. Проблемы?
    • 13. Проблемы! Они есть всегда!
    • 14. Время:
    • 15. Ограниченный бюджет:
    • 16. Нехватка рук:
    • 17. Изменчивость требований:
    • 18. Что с этим делать?
    • 19. Средства от всех бед:
    • 20. Средства от всех бед:
    • 21. Средства от всех бед:
    • 22. Без паники:
    • 23. Без паники:
    • 24. Его надо просто найти:
    • 25. 2 реальных примера
    • 26. Маркетинг: • Часто обновляется • Локализации иногда радикально отличаются • Занудные владельцы • Приличные объемы • Куча функциональных костылей
    • 27. Так разницы почти не видно:
    • 28. Так разницы почти не видно:
    • 29. А вот так уже очень видно...
    • 30. Основной упор – контент:
    • 31. • Сравнивали с эталоном Основной упор – контент:
    • 32. • Сравнивали с эталоном Основной упор – контент:
    • 33. • Сравнивали с эталоном • Валидировали самостоятельно Основной упор – контент:
    • 34. • Сравнивали с эталоном • Валидировали самостоятельно Основной упор – контент:
    • 35. • Сравнивали с эталоном • Валидировали самостоятельно • Верифицировали самостоятельно Основной упор – контент:
    • 36. • Сравнивали с эталоном • Валидировали самостоятельно • Верифицировали самостоятельно • Валидацию раздали заинтересованным лицам Основной упор – контент:
    • 37. Саппорт: • Плановая выкатка контента пачками • Межязыковое единообразие • Более сговорчивые владельцы • 7,5К статей на основные локализации
    • 38. Основной упор – пользователи: • Бета-версия
    • 39. Proof-pic
    • 40. • Бета-версия • Сбор фидбэков Основной упор – пользователи:
    • 41. • Бета-версия • Сбор фидбэков • Привлечение сотрудников саппорта Основной упор – пользователи:
    • 42. • Снизить число дефектов Цели:
    • 43. • Снизить число дефектов • Получить плюс в карму от тестеров Цели:
    • 44. • Снизить число дефектов • Получить плюс в карму от тестеров • Получить плюс в карму от шэфа Цели:
    • 45. • Снизить число дефектов • Получить плюс в карму от тестеров • Получить плюс в карму от шэфа • Добавить себе уверенности Цели:
    • 46. Инструменты:
    • 47. Проявление гибкости:
    • 48. Решительное НЕТ код-оунингу:
    • 49. ДА коллективному разуму:
    • 50. ДА статическому тестированию:
    • 51. ДА статическому тестированию: • Читаем чужой код
    • 52. ДА статическому тестированию: • Читаем чужой код • Обсуждаем чужой код
    • 53. ДА статическому тестированию: • Читаем чужой код • Обсуждаем чужой код • Правим чужой код
    • 54. ДА статическому тестированию: • Читаем чужой код • Обсуждаем чужой код • Правим чужой код • Учимся у боевого товарища
    • 55. ДА статическому тестированию: • Читаем чужой код • Обсуждаем чужой код • Правим чужой код • Учимся у боевого товарища • Учим боевого товарища
    • 56. ДА статическому тестированию: • Читаем чужой код • Обсуждаем чужой код • Правим чужой код • Учимся у боевого товарища • Учим боевого товарища • Есть анализатор – очень круто
    • 57. Ролевые игры:
    • 58. Тотальное логирование:
    • 59. Пользовательские сценарии: • Руками разработчиков
    • 60. • Руками разработчиков • Руками тестировщиков Пользовательские сценарии:
    • 61. • Руками разработчиков • Руками тестировщиков • Да мало ли ещѐ какими руками Пользовательские сценарии:
    • 62. • Руками разработчиков • Руками тестировщиков • Да мало ли ещѐ какими руками • И..... Пользовательские сценарии:
    • 63. • Руками разработчиков • Руками тестировщиков • Да мало ли ещѐ какими руками • И..... • Это совершенно бесплатно Пользовательские сценарии:
    • 64. Проигрывание логов:
    • 65. Коллективный анализ логов:
    • 66. Датчики и сигнализаторы:
    • 67. В качестве примеров:
    • 68. Доступность и производительность:
    • 69. Доступность и производительность:
    • 70. Доступность и производительность:
    • 71. Тестирование безопасности: • Nessus
    • 72. • Nessus • XSpider Тестирование безопасности:
    • 73. • Nessus • Xspider • OpenVAS Тестирование безопасности:
    • 74. • Nessus • Xspider • OpenVAS • Nikto Тестирование безопасности:
    • 75. Разрабские плагины: • FF • IE • Chrome • Гугл вам в помощь
    • 76. Немного теории:
    • 77. Или «как им помочь»:
    • 78. Два типа функционала: 1. Тот, что обязательно надо тестировать
    • 79. 1. Тот, что обязательно надо тестировать 2. Если хватит времени - протыкаем Два типа функционала:
    • 80. Собственно ищем: • Как? ▫ Расставить приоритеты
    • 81. • Как? ▫ Расставить приоритеты ▫ Сопоставить время рискам Собственно ищем:
    • 82. • Как? ▫ Расставить приоритеты ▫ Сопоставить время рискам ▫ Сопоставить ресурсы рискам Собственно ищем:
    • 83. • Как? ▫ Расставить приоритеты ▫ Сопоставить время рискам ▫ Сопоставить ресурсы рискам ▫ Сопоставить финансы рискам Собственно ищем:
    • 84. Прикинуть приоритетность: • Комплексные приоритеты ▫ Серьезность
    • 85. • Комплексные приоритеты ▫ Серьезность ▫ Приоритет Прикинуть приоритетность:
    • 86. • Комплексные приоритеты ▫ Серьезность ▫ Приоритет ▫ Вероятность Прикинуть приоритетность:
    • 87. Смотреть вглубь в вширь: • Маленькие проекты
    • 88. • Маленькие проекты • Побольше Смотреть вглубь в вширь:
    • 89. • Маленькие проекты • Побольше • Совсем большие Смотреть вглубь в вширь:
    • 90. Эмпирический метод: • Собрали в кучу функционал;
    • 91. • Собрали в кучу функционал; • Прикинули для него ситуации (user-story); Эмпирический метод:
    • 92. • Собрали в кучу функционал; • Прикинули для него ситуации; • Поставили приоритет; Эмпирический метод:
    • 93. • Собрали в кучу функционал; • Прикинули для него ситуации; • Поставили приоритет; • Сопоставили с рисками; Эмпирический метод:
    • 94. • Собрали в кучу функционал; • Прикинули для него ситуации; • Поставили приоритет; • Сопоставили с рисками; • Обсудили список с остальными; Эмпирический метод:
    • 95. • Собрали в кучу функционал; • Прикинули для него ситуации; • Поставили приоритет; • Сопоставили с рисками; • Обсудили список с остальными; • Отсортировали по убыванию. Эмпирический метод:
    • 96. FMEA Failure Mode and Effects Analysis метод анализа видов ошибок и их влияния
    • 97. Каждому свое: «Слова вы услышали, поиск пути за вами» Уильямс Деминг
    • 98. Спасибо за внимание! • Я: Роман Ивлиев • Е-почта: roman.ivliev@mail.ru • @dumtest • dumtest.livejournal.com