Меню

Чого КЛІЄНТИ ДІЙСНО очікують від тестувальників програмного забезпечення?

what do clients really expect from software testers

Спробуйте Наш Інструмент Для Усунення Проблем

У сьогоднішній статті я збираюся поділитися деякими думками щодо того, що, на мою думку, клієнти ДІЙСНО очікують від нас, базуючись на моєму досвіді роботи з клієнтами в місцях щоденної особистої взаємодії та співпрацюють в офшорах за допомогою електронної пошти або телефонних дзвінків.

ІТ-послуги є важливою та невід’ємною частиною індустрії програмного забезпечення, і для досягнення успіху важливо задоволення споживачів. Кожен клієнт / організація може бути різним у своєму процесі, може слідувати різному протоколу і може мати справу з різними типами бізнесу.

Але наступні фактори є загальними і мають значення для всіх загалом.

клієнти для тестування програмного забезпечення

(зображення src )

Що ви дізнаєтесь:

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

Очікування клієнта 1

# 1) Вигода

Коли ви думаєте щось продати чи придбати, вартість відіграє важливу роль, і це часто є одним з важливих вирішальних факторів. Чи не всі ми з нетерпінням чекаємо Чорної п’ятниці, розпродажу Flipkart Billion Day чи чудового торгового фестивалю Amazon? Ми стаємо шаленими покупцями під час продажу. Очікувати належної або додаткової вартості за наші гроші - це проста людська поведінка.

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

Вигода

Зараз ВЕЛИКЕ запитання: як ми можемо показати вигідність своїм клієнтам?

Ці моменти можуть допомогти:

  • Покажіть їм, скільки коштують їх гроші . Обґрунтуйте та надайте підтверджуючі докази для свого кошториси .
  • Подумайте про творчі способи економії на витратах.
  • Пристосуйте свою пропозицію. Замість того, щоб дотримуватися свого стандартного процесу, який коштує X суми грошей, запропонуйте дешевші альтернативи. Наприклад : Запропонуйте тестування критичного шляху замість повного тестування системи.
  • Знайте свою конкуренцію . Швидка перевірка реальності того, що інші сервісні компанії пропонують своїм клієнтам за яку ціну, є важливою для підтримання відповідності ринку вашої моделі ціноутворення.

# 2) Якість роботи

Якість і кількість роботи - це дві дуже різні речі.

Минули часи, коли кількість створених тестових випадків або повідомлених про дефекти використовувались за показниками продуктивності чи якості. Більше ні.

Ситуація більше схожа на зображення нижче:

Якість роботи

Якість роботи 2

А) Знайте, коли потрібно сказати „НІ”

Ми всі були в місцях, де ми працювали понаднормово, були на викликах у вихідні, відвідували пізні вечірні або ранкові ранкові дзвінки і т. Д. Однак, чого ми не розуміємо, це те, що ми можемо сказати НІ, якщо ситуація продовжує погіршуватися. Скажу НІ це єдиний спосіб, яким ми можемо зберегти якість роботи та здоровий стан.

Роблячи це, заздалегідь висловте своє занепокоєння та виступайте за якість.

Ось ситуація, в якій я потрапив, і це може дати вам краще уявлення про те, про що я говорю:

Моя компанія виграла новий логотип, і в рамках переходу зі старої компанії на мою було заплановано сеанси передачі знань. Ми, команда з 6 членів, вирушили на сайт клієнта. У перший же день після вступу нам поділились планом KT. Я виявив, що моє ім'я позначене на декількох модулях. Один із цих модулів мав бути повністю поза моїм обсягом, оскільки я навіть не знав про цю технологію; це ніяк не відповідало моїм навичкам.

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

  • Мені було призначено занадто багато робочих завдань, що, у свою чергу, заважатиме якості та моїй здатності захоплювати 100% на сесіях.
  • У запланованих предметах були сфери, де мої навички не збігалися, і оскільки я не був у правильній формі, я міг не зрозуміти на 100% під час переходу.

Свинець зрозумів проблему та переглянув план КТ.

список шпигунських програм для android

Сподіваюся, це допомагає підтвердити, що: якщо щось є в нашій тарілці, це не означає, що ми повинні з’їсти все це. Особливо, якщо це означає компроміс щодо якості.

Б) Повнота тестового кейсу

Скільки з вас зі мною згодні, що якщо ми спробуємо це зробити покращити спосіб написання тестових кейсів , це призводить до кращої якості?

Нижче наведено кілька типових помилок, поширених у більшості тестових випадків:

Компоненти тестових кейсівПоточна проблемаРішення
Об’єктивна Завдання - це найважливіша частина будь-якого тесту, це те, що робить всі тести різними. Поширені помилки з Objective - відсутність ясності.

Як і всі тестові кейси, створені для однієї функціональності, мають одну мету, не показуючи, чим відрізняється кожен тестовий кейс.		 Мета / мета кожного тестового випадку має бути чітким, щоб пояснити, яка функціональність та умови тестування будуть перевірені як частина цього тестового випадку.

Одна і та ж функціональність може мати позитивні та негативні тестові приклади, тому об'єктивність повинна бути достатньо чіткою, щоб показати різницю.
Попередні умови Багато тестувальників повністю пропускають згадування про передумову, або багато хто просто копіює та вставляє. Вставлення копії призводить до помилок, оскільки кожен тестовий приклад може повністю відрізнятися від іншого.Уникайте помилок Copy-Paste та звертайте увагу на деталі.
Дані тесту Це, мабуть, найбільш ігноруване поле, і в більшості тестових випадків воно буде порожнім або не матиме точного визначенняЗгадайте відповідні дані, які потрібно ввести. Іноді це не повинно бути точно.

Наприклад: Реєстрація користувача може зареєструвати користувача Анну чи Джона, і це не має значення. Але визначення, що дійсне ім’я, яке має всі символи і має бути довжиною 4-10, може допомогти з’ясувати багато речей.
Ідентифікатор тестового кейсу Над спрощеною умовою іменування чи нумерації. Скажімо, ви тестуєте кнопку входу. Часто ідентифікатори:
TC_1_Login
TC_2_Login		Зробіть їх більш описовими:
TC_1_Login_Invalid_User
TC_2_Login_Valid_User
Довідкові документи Невідповідне копіювання-вставлення з довідкових документів або ще гірше, використання неправильного.Завжди доцільно згадувати правильний довідковий документ із правильним номером версії, скажімо, для деяких тестових випадків FRS та технічні характеристики були б посилані на обидва, тому в тестовому випадку у довідковому розділі слід згадати обидва.
Етапи тестування Пропущені кроки, в основному тестувальниками, які дуже добре знають програму. Вони могли припустити щось і пропустити згадування кроків. Це створює проблеми для бізнесу, рецензентів та нових тестувальників.Слід використовувати правильні кроки та послідовність.

Підводячи підсумок, якщо врахувати дрібні деталі на етапі проектування, якість тестових результатів буде набагато вищою.

# 3) Розуміння бізнесу

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

Спробуйте спочатку дізнатися про бізнес, а потім вивчити функціональність; ти можеш уявіть потреби вашого клієнта більше і перевірити відповідно.

Ось приклад- FRS стверджує, що «Звіт XYZ повинен створюватися з 3 стовпцями як Дата, Ім’я та Статус». Нижче наведено тестові приклади, з якими ви закінчите, коли приймете цю вимогу за номінальною вартістю:

  • Створюється перевірочний звіт XYZ
  • Перевірити звіт має 3 стовпці як Дата, Ім’я, Статус
  • Перевірте дані у 3 стовпці.

Але, маючи на увазі ділову придатність цього звіту, можливо, доведеться перевірити:

  • Яка комерційна мета цього звіту?
  • Цей звіт створюється щодня?
  • Хто такі бізнес-користувачі, які переглядають цей звіт?
  • Що є джерелом даних для цього звіту?
  • Чи слід створювати звіт, якщо відсутні дані?

Це лише один із прикладів, але, мабуть, ми всі сходяться на думці, що кращого тестування можна досягти за рахунок підвищення обізнаності та досвіду бізнесу.

# 4) Доступність

Незалежно від того, чи є ви одинокою особою, яка підтримує клієнта чи команду, ваша наявність завжди повинна перевірятися ( Сфера вдосконалення).

За доступністю це не означає цілодобову підтримку. Це просто означає чітке та заздалегідь спілкування про вихідні, альтернативні плани та недоступність та відсутність МВС.

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

  • Модель збільшення персоналу - Якщо ви працюєте за моделлю збільшення персоналу і є єдиним представником вашої компанії, бажано, щоб клієнт був поінформований про ваші терміни роботи та заплановані неявки, щоб можна було зробити необхідні заходи.
  • Модель керованих проектів - У моделі керованого проекту, в якій формуються великі команди проектів і очолюються менеджерами з доставки / проекту, резервне планування ресурсів більше не залишається відповідальністю клієнтів. Потреба ПМ в управлінні як заплановані, так і незаплановані вихідні. У цій моделі бажано, щоб прем’єр-міністр намагався заздалегідь зібрати заплановані дані про відсутність у своєї команди та керувати відповідним чином. Бувають випадки, коли клієнти звертаються за підтримкою у вихідні дні або продовженням робочого часу. Такі випадки також слід планувати шляхом чергування ресурсів. Команда повинна складатися з членів, які можуть резервувати один одного, якщо це потрібно. Запланованими деталями слід поділитися із замовником.

# 5) Сфера вдосконалення

Це бажано не тільки в галузі програмного забезпечення, але й скрізь. Поліпшення не є одноденною роботою. Над сферою вдосконалення слід працювати постійно, і її можна розділити на 3 кроки -

Також читайте=> Як покращити свої навички тестування та перемогти конкуренцію

Крок No1: Визначте

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

Крок No2: Внесіть вдосконалення

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

Я процитую ситуацію:

Я був частиною команди тестування баз даних. Наша повсякденна робота включала запуск одних і тих самих сценаріїв SQL кілька разів на день з різним набором параметрів. Коли ми запускали проект, ми добре працювали з цими кроками, але врешті-решт ми зрозуміли систему краще, і ми думали, що ті самі сценарії SQL можна запускати як частину збережених процедур, замість того, щоб хтось вручну оновлював параметри та виконував.

Питання та відповіді на інтерв’ю для python

Крок No3: Оцініть покращення

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

Інша частина - відстежувати переваги протягом певного періоду, щоб бути абсолютно впевненими та представляти результати своїм клієнтам. У нашому проекті ми продемонстрували клієнтам скорочення часу виконання тесту на 30%, що, в свою чергу, зменшило вартість.

Висновок

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

Про автора: Ця чудова стаття написана членом команди STH Приєю Р. Якщо ви хочете написати нам і поділитися своїм досвідом, будь ласка дайте нам знати тут .

Сподіваюся, вам сподобалось прочитати цю статтю і ви знайшли її інформативною! Повідомте нас, якщо у вас є інший досвід поділитися.

Рекомендована література

^