How-to: інструменти для проведення конкурентного аналізу програмних продуктів



Зображення: Stephen Bowler, Flickr

Щоб отримати уявлення про розроблення продукті, необхідно дізнатися якомога більше про його властивості та якості. Для цього і існує тестування — цей процес якраз дозволяє зібрати потрібну інформацію. Але отримати їжу для роздумів і активних дій можна й іншим способом — наприклад, порівнявши власний продукт з конкуруючим рішенням.

Конкурентний аналіз (КА) програмних продуктів дозволяє виявляти такі їх властивості і якості, які неможливо було б дізнатися з допомогою звичайних тестів.

Ми в Positive Technologies почали процес занурення в КА ще кілька років тому — ось наша стаття про розробку методики проведення аналізу. У подальшому вона отримала свій розвиток у вигляді внутрішнього інструменту для конкурентного аналізу — про нього ми сьогодні і поговоримо.

Як це працює
Нижче — простий приклад застосування такого методу. Є два продукти — «наш» і конкурує. У першого ми бачимо чотири кольори, відповідні якимось властивостями, а у другого вирішення їх тільки три. Також у нашого продукту більше синього кольору, а в конкурента — сірого.



Практичне застосування цих знань в реальній роботі може бути таким. Припустимо, що ми прогнали десять тестів і дев'ять з них призвели до збою. Здавалося б, це вказує на наявність серйозних помилок у продукті, все погано. Якщо ж конкуруючий продукт точно також не проходить ті ж тести, то ситуація стає не такою критичною. Або навпаки — з десяти тестів тільки один призводить до збою, і здається, що все непогано. Але якщо конкуруючий продукт проходить всі десять тестів, то все не так райдужно.

Наш досвід
Ми займаємося конкурентним аналізом сканерів безпеки та захисних міжмережевих екранів, тому наші методики орієнтовані на продукти зі сфери веб-безпеки, але вони підходять і для інших ніш. Нижче — розповідь про те, як ми проводимо конкурентний аналіз.

У своїй роботі ми пройшли два важливих етапи розвитку. На першому з них нам важливо було провести якомога більше різних тестів, і ми порівнювали свій продукт усього з одним конкурентом. Звіт представляв собою відповідь на одне питання — який продукт виявив більше вразливостей.

Далі ми вирішили, що скоротимо кількість тестів до 10-15 найважливіших і збільшимо кількість конкурентів до 2-3, а в звіт включимо порівняння за більшою кількістю параметрів. Формат відповіді на питання «хто знайшов більше» при цьому зберігається, але більш глибокий аналіз даних дозволяє знаходити і відповідь на питання про те, чому конкурент обійшов нас з конкретного параметру?

Згодом ми плануємо збільшити кількість тестів, а число конкурентів для аналізу перевищить 3 продукту. У майбутньому ми хочемо перейти на наступний етап розвитку конкурентного аналізу в компанії і навчитися давати відповідь на питання про те, які фічі слід реалізувати, щоб наші продукти стали на голову вище конкуруючих рішень.

Зараз наш процес конкурентного аналізу виглядає так: ми запускаємо тести, розбираємо результати, готуємо звіти, займаємося автоматизацією і доопрацюванням тестів, а потім все повторюється знову.



Не все так просто
На папері все виглядає гладко, але в реальному житті трапляються і складності. Дуже часто ми потрапляємо в ситуацію, як на картинці нижче, коли продукти різняться, приблизно як яблуко і черемха:



Якщо завдання полягає у порівнянні двох різних сканерів уразливості, то зазвичай ми стикаємося з такими труднощами:

  1. Конкуруючі продукти мають різні формати звітів і логів — це означає, що потрібно придумати єдиний формат і конвертувати всі в нього.
  2. На виході продукти надають різну інформацію — наприклад, навіть при виконанні одних і тих же завдань, у звітності продукти можуть використовувати різні описи. А значить потрібно розробляти засоби автоматизації, щоб розуміти, коли ми маємо справу з однаковими поняттями.
  3. Конкуренти вміють шукати різні типи вразливостей — один продукт шукає уразливості A і B, а другий визначає B і C. Просте порівняння кількості вразливостей в двох множинах буде неефективним, необхідно аналізувати їх перетин, тільки тоді картина буде повною.
  4. Конкуренти по-різному називають одну і ту ж уразливість — тут ситуація повторює другий пункт.
  5. Конкуруючий продукт на якийсь цілі показує велику кількість помилкових спрацьовувань — у підсумку наш сканер може знайти 1000 вразливостей, а конкурент все 10000, значить нам потрібно придумувати, як автоматично виявляти такі помилкові спрацьовування, щоб отримати можливість коректно порівнювати результати.
  6. Сканер не може повністю просканувати якусь CMS — навіть якщо ми знайшли відмінну мета для сканування, все це не допоможе, якщо конкуруючий продукт не може зробити теж саме (наприклад, не може пройти авторизацію в CMS). Доводиться адаптувати мети, щоб все-таки мати можливість провести порівняння.
Інструменти конкурентного аналізу
Поговоримо про те, з допомогою яких інструментів можна проводити конкурентний аналіз софту. Для управління процесом аналізу ми використовуємо власний інструмент під назвою InAC (Intellectual Analysis of Competitors). Без хмари OpenStack процес також був би неможливий, для збереження результатів використовується TFS і мережевий диск, крім того ми застосовуємо в аналізі нейромережі (про це буде окрема стаття), але все віддати машин неможливо, тому розбір результатів проводиться вручну за допомогою браузерів, IDE і burp, висновок складається звіт у вебі. Спочатку ми використовували Excel, однак він не здатний виводити велику кількість графіків в зручному для користувача вигляді.



Висновок: що потрібно вміти для проведення КА
Конкурентний аналіз дозволяє одержати інформацію про властивості та якості програмних продуктів, яку не дізнатися іншими способами. Однак це специфічний інструмент, і щоб домогтися високої якості висновків фахівці, які проводять аналіз, повинні глибоко розбиратися у предметній області.

В нашому випадку, фахівці з тестування володіють навичками ІБ-дослідників і проведення пентестов, крім того, їм потрібно знати PHP, Java EE, ASP.NET (C#), Python (бажано), вміти працювати з Docker, TFS, Salt, git

P. S. Розповідь про наш досвід конкурентного аналізу програмних продуктів був представлений в рамках DevOps-митапа, який відбувся восени 2016 року в Москві.

Відео:



Слайди:



посилання представлені презентації 16 доповідей, представлених в ході заходу. Всі презентації та відео виступів додано в таблицю в кінці цього топіка-анонсу.

Автор: Володимир Софин
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.