Note Event ISQA x Telkom

Testing cycle and automation API in Peduli Lindungi by Herdian Chandra

• Testing cycle

1. Identify Requirement Analysis: Ensure that business flow is ok & prepare test data

2. Create test design: create test case

3. Environment setup: prepare the APK(Android Package)/IPA(iOS App Store Package) for each environment

4. Test execution: sanity test & smoke test

Sanity test adalah menguji fitur yang baru saja dikembangkan dan fungsi utama aplikasi.

Smoke test adalah memastikan fungsi utama aplikasi berjalan dengan baik dan stabil dan tidak ada perubahan setelah ada fitur baru.

5. Test closure: smoke test & regression test

Smoke test adalah memastikan fungsi utama aplikasi berjalan dengan baik dan stabil dan tidak ada perubahan setelah ada fitur baru.

Regression test adalah menguji semua bagian berfungsi atau tidak. Bertujuan untuk mengontrol dan mengonfirmasi bahwa perubahan kode baru tidak memengaruhi fitur yang ada.

• Tools & Technology

1. Java
2. Rest Assured: basic bahasa pemrograman Java
3. TestNG: test framework Java
4. Allure Reports: untuk report
5. Hamcrest: library assertion
6. Jackson API: untuk melakukan serialization & deserialization

• API adalah core bisnis, sebaiknya mendahulukan automation API, kemudian Web.
• Project structure (dari bawah sampai atas)

1. Pom.xml : dependency management
2. TestCase Classes : berbagai nama skenario fitur
3. POJO (Plain Old Java Object) Classes for Serialization & Deserialization :

• Serialization converts an in-memory data structure to a value that can be stored or transferred.
• Deserialization takes a series of bytes and converts it to an in-memory data structure that can be consumed programmatically.

4. Spec Builder : Reusable Request & Response spefication

5. Route : endpoint yang akan di testing

6. Rest Assured API reusable methods

7. API Test Reusable Methods : contoh ada 10 test cases login menggunakan method post, daripada menggunakan 10 method post dalam test cases, lebih baik simpan 1 method post dalam API Test Reusable Methods, sehingga kedepannya dipanggil saja.

• Function / Method Test Cases, dibagi 3 blok :

1. Body Request : detail request API yang dikirim untuk mendapat response
2. Rest Assured : melakukan hit terhadap API
3. Assertion : expectation dari response API

Telkom Testops Solution by M. Najmi Ardan

- persona : yang memanfaatkan testing seperti Developer, Product Owner dan QA.

- Problem :

1. Device fragmentation : android memiliki berbagai macam merek, setiap merek memiliki custom os merek sendiri, behaviour hadware : layarnya memiliki poni, behaviour software : bisa reproduce di android version 12 one ui version 4.0 tapi tidak bisa reproduce di android version 12 one ui version 4.1.

2. Multi-platform server setup: Android, Ios, Web, Mobile Web, API, Microservice.

3. Multi-platform pipeline setup: pipeline QA, pipeline Developer.

4. Multi role: contoh aplikasi My Indihome terdapat berbagai role User, Technical Support, Admin etc.

5. Multi location: user terdapat di berbagai lokasi dan waktu yang berbeda.

- Advantage test automation

1. More test frequencies: bisa dilakukan test berulang kali, jika manual test terdapat kejenuhan test berkali — kali.

2. Test parallel: bisa lebih stable, bisa di trigger saat code changes berhasil di deploy di suatu environment. contoh : terdapat 200 test cases, bisa di runing 20 test cases, sehingga ada 10 parallel test.

3. Remote test: bisa melakukan test suatu sistem di device tertentu melalui Remote Test Lab yang sudah disediakan oleh Samsung.

4. Test run faster: bisa lebih cepat karena menggunakan mesin & paralel

5. Quicker feedback regarding software quality: test early, test often

6. Improve system reliability (e.g repeatability, consistency, etc)

Advance manual test :

• Exploratory test : test yg kreatif & eksploratif

Testops solution : untuk layering ke persona — persona agar dipermudah excecution

. Test infrastructure explained

1. Report: obtain valuable insight to help decision making from test report. Dari data -> information -> knowledge -> wisdom -> decision making. Decision making oleh developer dan product.

2. Execution: everyone can execute the test from test infrastructure

QnA

1. Mengapa pindah dari test management xray ke squash? Apa keunggulan squash? Karena squash opensource dan untuk mendukung testops solution

2. Automation di run setiap kapan? Di trigger manualkah setiap mau release? Atau sudah di schedule kah di CI? Atau seperti apa? Sebaiknya running setiap hari. Triggernya sesuai kebutuhan, bisa manual, bisa setiap changes dari developer

3. Bagaimana perkembangan rpa di industri IT yang ada di Indonesia? Apakah mungkin dari telkom ada menerapkan testing dengan rpa? Belum menerapkan testing dengan rpa dan bisa dimasukkan dalam backlog

4. Telegram hanya dipakai untuk notification dari jenkins atau bisa melakukan trigger dari sana? Jika hanya notification, triggernya by test failed atau seperti apa ya? Kalo sekarang telegram hanya dipakai notification, execution runningnya melalui dashboard, karena masih ada concern jika execution running melalui telegram, tapi bisa jadi masukan juga. Notificationnya berupa report scenario yg passed, failed, berapa scenario yg passed, failed

5. API Test yang berkaitan dengan pihak lain, apakah di automate juga? Ada obstacle tidak test bersama dengan party lain? Kami tidak langsung mentah2 hit api pihak lain, ada integrasinya. Sebelum hit service mereka, hit service kami dulu. Kalo bisa di automate, contoh register. Obstacle nya mengenai limitasi policy dari setiap instansi, seperti register hanya bisa sampe jam 8 malam. API test bisa untuk menganalisis root cause sistem. Di katalon bisa 1 repo untuk mobile android, ios, backend dan frontend.

6. Untuk penggunaan katalon, jenkins, dan lainnya, apakah selalu menggunakan versi terbaru, karena ada batasan versi? Contoh hold di katalon v.7.x.x. Kami selalu menggunakan katalon terbaru karena memiliki licensenya.

7. Bagaimana handle error jika menggunakan feature reusable? Karena itu dependence akan saling ketergantungan, jika error satu akan ketergantungan yang jika error satu maka akan error yang lain. Apakah bisa handle gRPC? Karena secara struktur beda dengan restAPI. Salah satu test automation patern adalah atomic test, test nya sekecil mungkin. Bikin test nya se isolasi mungkin, kemudian di group. Membuat suatu function yg isolir dan stabil. Kalau tidak stabil akan mempengaruhi scenario yang lain. Bisa handle grPC dengan postman, newman. Di kami masih jarang yang handle gRPC. Policy di kami backend menggunakan restfull. Dalam sebuah aplikasi, terdapat sebuah mekanisme untuk bertukar data antar aplikasi dengan menggunakan teknologi REST API. Teknologi ini menggunakan format data JSON sebagai struktur datanya dan sering digunakan di berbagai aplikasi. Cara lain yang dapat digunakan untuk bertukar data adalah dengan menggunakan gRPC yang menggunakan protocol buffers sebagai struktur datanya. gRPC memiliki berbagai keunggulan seperti menggunakan HTTP 2 dan memiliki fitur untuk melakukan generate kode tanpa menggunakan aplikasi tambahan seperti Swagger atau Postman untuk REST API.

Reference :

https://www.dicoding.com/blog/menguji-appgame-dengan-rtlremote-test-lab/

https://medium.com/@shubameg48/serialization-and-deserialization-in-rest-assured-api-testing-6e676c9adefa

https://betterprogramming.pub/serialization-and-deserialization-ba12fc3fbe23

https://kotakode.com/blogs/14169/Belajar-gRPC---1-Perkenalan