Коли Скотт Шервуд побудував плани, архітектурні конструкції та початкова база кодів для створення TestLodge Test Test Case Toolйого команда була зосереджена на – як не дивно – процедури тестування програмного забезпечення. Те, що вони зараз усвідомлюють, привело б їх до ще більш функціонального кінцевого продукту, це було (і є) більш визначеним фокусом на інженерії даних з самого початку аналітики, звітності, аудиту та оцінки. Крім того, у всесвіті програмного забезпечення, де AI настільки ж хороший, як і його життєва кров, надання даних тестових випадків (сам по собі) явно потребує певного тестування.
Що таке управління тестовими справами?
Як основна функція інженерії програмного забезпечення, яка повинна мати у всіх програмах технологій корпоративних технологій розумного розміру, управління тестовими випадками стосується відстеження дефектів за допомогою процедур створення тестових випадків, які щільно узгоджуються з контролем версій, щоб весь поточний код є частиною проведеного аналізу назовні.
Але чому важливе управління тестовими справами? Це насамперед тому, що управління тестовими випадками може покращити ефективність використання ресурсів випуску програмного забезпечення та програмного забезпечення (ресурси тут – як робочий час людини, так і обчислюють цикли обробки та вимоги до зберігання даних, а також “великі” дзвінки з аналітики даних тощо), щоб остаточні отримані отримані Програмне забезпечення відповідає більш високому рівню прийняття користувачів. Оскільки погана документація може погіршити управління тестом, дані, що стосуються тестового випадку, мають вирішальне значення для відстеження тестових випадків.
Основні дані хліб та масло
Коли Шервуд та його колеги вперше розробили свою платформу, вони визнають, що насправді дуже мало враховують, як вони використовуватимуть дані для зростання – окрім очевидних зобов'язань щодо безпеки та дотримання.
“Будучи інструментом управління справами, ми були суто зосереджені на робочому процесі виконання тестів, настільки насправді, що початкова бета -версія не мала жодної функції звітності”, – зізнається Шервуд. «Це швидко змінилося, коли відгуки користувачів почали зростати, і прагнення до детальних звітів з наших даних зростало. Складність виникла від різноманітних запитів з кожною компанією, здавалося б, бажає іншого підходу до того, як аналізуються та представлені її дані ».
Озираючись назад, Шервуд каже, що це проблема, яка часто мучила інженерів даних, тобто бажання зосередитись на конкретному результату чи інструменті, перш ніж зрозуміти самі дані, як вони рухаються по трубопроводу, як він зберігається тощо, як тільки вони почали дивитися на це Дані з трохи більше внутрішнього ока, вони почали визначати, які особливості матимуть найбільший вплив на (і для) користувачів.
Диктатура розробників
“Ви повинні часом бути диктатором, як розробник, щоб переконатися, що ви не намагаєтесь бути всіма людьми. Ми витратили час на створення функції та моніторинг її використання, але якщо це виявилося менш популярним, ніж інші, нам доведеться прийняти важке рішення, щоб його видалити. Однак, замість того, щоб зробити жорсткий розріз, ми просто не надаємо новим користувачам доступ до нього, припиняючи його. Це тримає продукт худорлявим, не засмучуючи існуючих користувачів », – детально Шервуд.
Ще одним завданням для розробників є презентація даних та вимоги до ресурсів, які йдуть разом з нею.
Deluxe UX досвід
UX інтерфейсу часто може бути визначальним фактором для залучення або утримання нових користувачів, тому йому дійсно потрібно звернутися до першого погляду. Як інструмент управління тестом, вони представили інформаційну панель користувачів, яка дала миттєве розуміння тестових заходів з першого погляду та виявилося дуже популярним. Складність цього підходу до презентації полягає у необхідності його завантаження миттєво, тому для підтримки ефективності він може повідомити лише про поточні дані та діяльність.
“Під час звітування ви стискаєте багато даних, тому вам потрібно присвятити свої ресурси лише аналізу даних, необхідних для потрібного результату – ніхто не хоче чекати години, щоб звіт про створення та доставку”, – сказав Шервуд. «Одне рішення – перемістити якомога більше цього на задній план і дозволити користувачам продовжувати інші завдання під час аналізу. Знову ж таки, значна частина цього покладається на те, наскільки добре ви використовуєте свої ресурси – оскільки додавання додаткових може бути дорогим, не обов'язково вдосконалюючи досвід користувача ».
Детально деталізуючи роботу тут, він сказав, що сторонні інтеграції-це чудовий спосіб дозволити користувачам вибирати та вибирати потрібні функції, не потребуючи внутрішнього розвитку. Насправді, сторонні інструменти аналізу даних потенційно пропонують величезний стрибок для розробників, які хочуть надати різні елементи звітності, з їх здатністю пройти дані та генерувати звіти за частку часу.
Однак перед тим, як запровадити їх, є ряд речей, які слід враховувати – які вартість цих інструментів, чи добре вони інтегруються, чи будуть керувати даними вашого користувача етично та відповідально, відповідати правилам конфіденційності тощо.
Дані майбутні світогляди
Отже, він запитує … як виглядає майбутнє для розробників, коли йдеться про використання та звітування про їхні дані?
«Важко з нетерпінням чекати цього чи будь -яку тему насправді, не згадуючи AI. Хоча його використання неминуче, виникає непорозуміння щодо ролі, яку вона відіграватиме. Можливо, увага, можливо, не повинна зосереджуватися на тему “Чи буде це видалити потребу в інженерах даних”, а більше – на те, як інженери використовуватимуть AI “, – сказав Шервуд. «Це випливає з загальної галузі упередженості, щоб зосередитись на інструментах, а не на основах – все починається з типу та якості ваших даних! Вирішення, які набори даних є правильними для конкретного аналізу, дасть вам набагато швидше та точніше, ефективні та відповідні звіти, які використовують менше ресурсів. Це зробить нас більш ефективними, але незабаром це не замінить потребу в людей ».
Нарешті, як уже торкалося, Шервуд каже, що етика та використання даних-це занепокоєння, яке лише зросте-оскільки більше розробників використовують сторонні інструменти, скільки проходитимуть через тонкий друк і подивиться, де ці дані фізично зберігаються ? Як він буде використаний, ділиться чи, можливо, продається? Як ви можете гарантувати, що дані ваших користувачів захищені через кілька платформ, юрисдикцій та відповідей?
Підсумовуючи тут, екіпаж TestLodge нагадує нам, що розробникам зобов’язано забезпечити безпеку даних користувачів та забезпечити широке розуміння того, як сторонні інтеграції в них. Довіра-це товар, який ми рідко можемо дозволити собі втратити, і зростаючи Вік автоматизації, як відомо, що етика у вашій інженерії допоможе вам виділитися.
Testlodge
TestLodge-це веб-інструмент для управління тестовими випадками та тестовими запусками. Він призначений для того, щоб допомогти командам забезпечення якості (QA) впорядкувати свої тестування та співпрацювати більш ефективно. Це інтегрується з трекерами випуску, тобто він може автоматично створювати проблеми у відстеженні випуску команди розробників, коли тест не вдається. Особливості співпраці Середній тестова дозволяє користувачам легко обмінюватися інформацією та працювати разом над тестуванням проектів. Він може надати звіти та показники тестування на якості, а також допомогти розробникам побачити, які вимоги мають пов'язані тестові випадки. TestLodge може автоматично створювати квитки в трекері випуску, коли тест виходить з… і автоматично оновлювати стан проблем у трекері випуску.