The area of knowledge for SF QA (part 1)

Why QA should know the business principles of Salesforce?

Основна мета будь-якого бізнесу - забезпечити задоволення клієнтів. Компанії інвестують багато часу та зусиль, щоб задовольнити клієнтську базу, наголошуючи на швидкій та ефективній взаємодії з клієнтами, тим самим підкреслюючи потребу в ефективних продуктах управління взаємовідносинами з клієнтами (Customer relationship management - CRM) на ринку.

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

Так що ж таке CRM і чому нам важливі бізнесові підходи системи? Рішення для управління взаємовідносинами з клієнтами є обов’язковими для будь-якого бізнесу, що має на меті розширення. Система дозволяє отримати глибоке розуміння наявних і потенційних клієнтів, побудувати з ними тісні стосунки та пропонувати їм різноманітні послуги. Вона також надає інформацію, необхідну для прийняття рішень на основі даних, та інструменти для оптимізації завдань прогнозування, забезпечує винагороду від продажів, маркетингу, а також автоматизує робочий процес підтримки клієнтів тощо.

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

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

Why QA should become a Certified Admin?

Тестування Salesforce вимагає знання тих самих методик, які зазвичай використовуються у звичайному веб тестуванні. То чому ж таки бізнес принципи, які використовуються у Salesforce, так впливають на сам процес тестування? Більшість функцій у Salesforce, це так звані функції з коробки (built-in features), які є підлаштовані під потреби того чи іншого бізнесу. І коли QA приймається за свою роботу, дуже важливо розібратись, в чому ж таки проблема. Чи все-таки це помилка, що виникла в наслідок не релевантного налаштування, інтеграційних можливостей, чи не достатньої обізнаності бізнесу щодо того, які саме можливості платформа пропонує, або ж чи це помилка, що виникла у коді, оскільки, не всі потреби бізнесу вдається налаштувати та кастомізувати. Для того, щоб уникнути непорозумінь у процесі роботи з клієнтом (а розробка та тестування це нехай не безпосередня, але все-таки робота з клієнтом), QA, як справжній фахівець з якості, потребує достатніх знань та розумінь цілої платформи.

Що ж саме необхідно знати? В першу чергу бодай частково напрямок, в якому працює клієнт, так званий домен. Адже в залежності від того, чим займається компанія — чи це банківська справа, чи медицина, чи роздрібна або гуртова торгівля — буде залежати набір стандартних і кастомних налаштувань, використання 3rd party services, налаштувань безпеки й т.д… Що логічно, оскільки у різних компаніях є різні потреби у використанні платформи.

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

Багато речей можна зробити в Salesforce за допомогою адміністрування point-and-click, включаючи автоматизацію завдань, як-от автоматичне створення tasks, оновлення полів і надсилання електронних листів. Це робить процес налаштування настільки цікавим, що тестувальник часом відчуває себе справжнім розробником і це теж частина роботи QA.

What basic Levels should QA understand to start a daily routine in testing?

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

Salesforce проходить ті самі етапи життєвого циклу тестування програмного забезпечення як і будь-яка інша Web програма, але вона має деякі особливості.

Отже, які ж рівні тестування присутні у Salesforce:

Unit Testing

Хто проводить: розробники Salesforce.

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

  • Покриття коду має становити принаймні 75%, щоб перемістити Apex код у production.

  • У модульних тестах використовується код Apex, анотований ключовим словом «testMethod».

System Testing

Хто проводить: консультанти Salesforce, QA.

  • Вони також перевіряють систему повністю, проводять так зване end-to-end testing, щоб перевірити технічний процес, який виконується у серверній частині.

  • Консультанти використовують кілька тестових сценаріїв на основі конкретних результатів.

  • Дозволяє діагностувати проблему за допомогою автоматичних правил системи, таких як flow, validation, assignment тощо.

User Acceptance Testing

Хто проводить: Користувачі Salesforce, які збираються використовувати web app в режимі реального часу.

  • Тестування проводиться в середовищі, схожому на Production, в залежності від потреб – це може бути partial або full copy sandbox, і у зв’язку з цим користувач бачить лише ті елементи, які йому потрібні.
  • Метою перевірки прийнятності для користувачів є усунення помилок, які впливають на роботу користувача.
  • UAT — це останній рівень тестування перед тим, як запустити код у production.

Production Testing

Хто проводить: і команда тестування, і кінцеві користувачі

  • Цей вид тестування здебільшого проводять на Production environment.
  • Він схожий на тестування системи, в процесі тестують систему повністю, щоб переконатися, що конфігурація та налаштування, які виконані командою розробників, ідеально працюють у робочому середовищі.
  • Оскільки тестування відбувається в живій системі, потрібно бути максимально обережними під час тестування production.

Regression Testing

Хто проводить: як manual QA, так і automation QA.

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

З усього вище сказаного, можемо зробити висновок: якщо Salesforce правильно налаштовано, розроблено та перевірено, вона забезпечує користь і збільшує рентабельність інвестицій для бізнесу. Тому якісне та достатнє тестування SFDC і глибоке розуміння програмного додатка можуть запобігти затримкам розгортання, підвищити ефективність і запровадити миттєву віддачу.

Бажаю усім, хто взявся за тестування Salesforce – отримати справжнє задоволення від процесу, адже ця система є великою та цікавою водночас!

в целом все правильно написано, но убери слова типа SFDC и поставь вместо их, например, ServiceNow - и тоже все будет правильно…

пожелание отсертифицироваться на Админа для SFDC QA - это очень разумно, но на практике QA палкой не заставишь получить что-то по SFDC, они предпочитают бесконечно сертифицироваться по своим QA-ным топикам

1 Вподобання

Дякую за відгук @DenBrown, сертифікація по QA topics, це корисна і можливо не завжди очевидна річ, так як основним є не наявність сертифікату, а знань, і підготовка до іспиту стимулює глибше занурюватись у ту чи іншу тему, так само працює і з SF Certifications - основним у цій справі є потреба глибше зануритись у саму платформу, а присутність зданого іспиту це просто підтвердження того, що час був затрачений недаремно)

Кстати, на Trailhead есть сертификация по БА, но до сих пор нет почти ничего по QA. А ведь именно QA в многих случаях является точкой входа для новых людей в IT

2 Вподобання