Шарттуу мисал: сайт «өтүнүч жөнөтүлдү» деди, бирок CRMде ал жок. Менеджер көйгөйдү кардар кайра чалганда билет. Сайттагы жашыл баскыч ошол убакта өзүн сонун сезип турду.
Интеграцияны кошуу — пайдалануунун башталышы. Бизнеске маалыматты бир жолу берүү гана эмес, үзгүлтүктү байкап, кайрылууну ишке кайтаруу жолун түшүнүү маанилүү.
Биринчи текшерүү: керектүү жерге жеттиби?
Интеграция — мисалы, сайт менен CRMдин ортосунда маалымат алмашуу. Жөнөтүүчүгө ийгиликтүү жооп келиши бизнес-процесс бүткөнүн дайыма эле далилдебейт.
Окуу өтүнүчүндө бүт чынжырды текшериңиз: суроо-талапты кабыл алуу, керектүү жазууну түзүү, жооптууну дайындоо жана кийинки аракеттин пайда болушу. Өтүнүчтү эки системадан тең табуунун түшүнүктүү жолун сактаңыз.
CRMге чейин ортомчу сервис болсо, анын «ийгиликтүү» абалы эмнени билдирерин тактаңыз: маалыматты кабыл алдыбы же андан ары өткөрдүбү?
Экинчи текшерүү: мазмун белгиден маанилүү
Атын, байланыш жолун, товарын, санын жана сценарийге керектүү башка талааларды салыштырыңыз. Бош талаа кээде ачык катадан кооптуураак: карточка бар, бирок иштетүүгө болбойт.
Кыргызстандагы компания окуу үлгүсүнө колдонулган тилдерди, телефон форматтарын жана түзүлгөн убакытты кошкону пайдалуу. Сыноо үчүн чыныгы буйрутмаларды өзгөртпөңүз.
Кайсы айырмалар олуттуу экенин жана ким текшерерин макулдашыңыз. Кардар өзү алмашууга аудит жүргүзгөнчө күтүүнүн кажети жок.
Үчүнчү текшерүү: кайталоо жана белгисиз жыйынтык
Бир окуя кайра келиши мүмкүн. Иштеткич ар бир жолу текшербей жаңы сатуу түзсө, байланышты оңдоо кайталанган жазууларды жаратышы ыктымал.
Долбоордо иштетилген окуяны таануу жана жыйынтыкка байланыштыруу жолу керек. Анын түрү интеграцияга жараша; универсалдуу баскыч убада кылбаңыз.
Өзгөртүү аяктаганы белгисиз тайм-аутта адегенде кабыл алуучу системаны текшеришет. Сокур кайра жөнөтүү экинчи жазууну түзүшү мүмкүн. Бул учурду макулдашылган сыноолорго сөзсүз кошуңуз.
Төртүнчү текшерүү: катаны ким билет?
Ката журналы — эмне өтпөгөнүн жана эмне үчүн өтпөгөнүн түшүндүргөн окуялар тизмеси. Жетекчи үчүн бардык техникалык саптар эмес, жооптуу адам, иштетилбеген окуялардын саны жана калыбына келтирүү тартиби маанилүү.
Битрикс24 REST APIде жүк чектөөлөрү жана лимит каталары бар — алар расмий документацияда сүрөттөлгөн. Иштетүү суроо-талаптарды чексиз кайталабай, өнүмдүн сунуштарын эске алышы керек.
Жол берилген кечигүүнү, билдирүү алуучуну жана коопсуз кайра иштетүү жолун макулдашыңыз. Сырсөздөр менен ачкычтар бүт команда көргөн журналга түшпөшү керек.
Бешинчи текшерүү: калыбына келтирүү чындап иштейби?
Уруксат берилген сыноо сценарийинде кабыл алуучунун убактылуу жеткиликсиздигин, байланыштын калыбына келишин жана топтолгон окуялардын иштетилишин текшериңиз. Жыйынтыкты баштапкы өтүнүчтөр менен салыштырыңыз: эмне кабыл алынды, эмне иштетилди жана эмне ката менен калды?
Кызматкердин кадимки аракеттерин жана адис керек болгон учурду сүрөттөңүз. Система жаңырганда же талаалар өзгөргөндө текшерүүгө жооптууну дайындаңыз. Болбосо кечээ иштеген алмашуу бүгүн маанилүү бир маанини үнсүз жоготушу мүмкүн.
QQDev API аркылуу алмашууну, анын ичинде кайталоолорду иштетүүнү, ката журналын жана документацияны иштеп чыгат. Интеграция иштеп чыгуу бетинде чынжырыңызды текшерүүнү талкууласа болот. Жеке маалыматсыз бир мисал алып келип, команда азыр жоголгон өтүнүчтү кантип билерин түшүндүрүңүз.