DevOps Jakarta Kickoff Meeting

Untuk pertama kalinya komunitas dari Devops Jakarta bekerjasama dengan Bukalapak mengadakan event dengan nama DevOps Jakarta kickoff meeting. Bertempat dikantor Bukalapak, pada tanggal 19 Januari 2017 event ini dihadiri kurang lebih 60 peserta.

Pembicara pertama dalam event ini adalah Addhe Warman Putra (Head of Infrastructure KMKLabs) menjelaskan tentang apa itu DevOps, seperti apa bentuknya dan langkah apa saja yang harus dilakukan untuk mengadopsi devops diperusahaan serta peluang devops dalam industri teknologi informasi.

 

persentasi-addhe-warman

 

Di sela-sela presentasi, Addhe Warman selaku pembicara memberikan pertanyaan kepada peserta event dan untuk yang bisa menjawab pertanyaan tersebut akan mendapatkan hadiah menarik yang akan diberikan di akhir acara dan dilanjuti dengan sesi tanya jawab seputar materi yang disampaikan oleh pembicara.

Acara dilanjutkan oleh pembicara kedua, Nugroho Herucahyono (CTO Bukalapak) yang membawakan materi tentang Monitoring di Bukalapak.

cinux

 

Karena acara ini baru pertama kali diadakan, dalam event ini juga dilakukan voting untuk menentukan jadwal agenda dan materi pembahasan meetup selanjutnya. Acara ini ditutup dengan pembagian Goodie bag dan buku Site Reliability Engineering oleh Addhe Warman dan panitia kepada peserta yang beruntung.

whatsapp-image-2017-01-25-at-12-32-43

 

Kami sebagai panitia berterimakasih kepada Bukalapak karena telah menyediakan fasilitas untuk mendukung acara ini serta kepada semua peserta yang telah bersedia hadir.

whatsapp-image-2017-01-25-at-12-33-29

Untuk materi presentasi bisa di download di https://github.com/devopsjakarta/meetup-2017-01-19

Untuk update info dan jadwal meetup selanjutnya dapat di cek di

  • Twitter : @devopsjakarta
  • Github : devopsjakarta
  • Meetup link : meetup.com/Devops-Jakarta
  • Milis : groups.google.com/d/forum/devopsjakarta

See you in the next meet up 🙂

DevOps Jakarta Kickoff Meeting

Having a good proportion of Developer Test

Code have different purposes, sometime significantly (logic/algorithm vs storage access/store) and interact with different type of resources. So, to have a good and effective test coverage but also practically testing them we need a different type of tests for different kind of code. Below are the type of testings that we do to address them.

Unit Testing

This type of test exercise the computational/logic part of the software which makes it the test with the least cost (easy to setup, fast to run) but the most value (can easily cover a lot of test cases and logic variations). It is quite obvious then that majority of the test should be of this type.

To be unit-testable, our code need to be decoupled from external dependencies like I/O, storage or services so it can be tested independently i.e: have a proper boundaries/contract with the external world.

Integration test

This is the part where we test parts outside the boundaries as mentioned earlier. Given a good coverage on the unit tests,  this part only need to tests whether I/O and other kind of services give proper response given certain request. The aim is to ensure this layer give a proper output to be used as input by our logic above.

Acceptance test

This test check that all the parts run together as fully functioning use case after being tested independently as the above. It is an end-to-end test and being done as close as possible to how user actually using it. It is to show and prove the feature works. The UI part that is purely rendering is tested here also which make it sometime we refer to it as UI test.

We are focusing here on how everything fit and works together. Thus, we no longer tested logic and variations that already tested on the previous tests, at least not extensively and for different purpose and audience. For example on testing the date is displayed we only need to some sanity assertions e.g: tha value is there and not empty, but no longer check how the month and date string is formatted in detail which sould already be extensively tested in, much less costly, unit test.

Testing Pyramid and Clean Architecture

The type proportions of the test above typically refered to as Test Pyramid. There are some variations on what constitute Integration and Acceptance test but basically it is a guideline on how an effective composition of tests should be. It ensure we cover most of the thing without being impractical by having more of unit tests and more effective use of the more costly (but still necessary) type of test.

We can watch our code and test as we do them to more aligned with this proportion, but one natural way to get a good composition like above is following Clean Architecture. It’s an  architectural guideline which has been around for quite sometime, at least in the core idea and with different name e.g: port-adapter, domai-driven-design. It basically put your use case and domain as the inner part of your code base while the rest e.g: I/O as external part that is separated cleanly by boundaries/contract.

Here are the parts on clean architecture that would be in unit test :

  • Interactor : application logic e.g: sort displayed item by date
  • Entity : business logic e.g: video that wins need to have x number of vote and min y number of play
  • Presenter : ui logic e.g: the field should be red when it’s in the wrong formatted
  • Boundaries : interface/contract for external dependencies (Storage, Service), not being tested by itself but used by the above items for testing as a contract for adapter implementation later on below. It also useful to make UI logic in Presenter can be tested independently without the need for concrete implementation for application logic in Interactor that, although fully unit testable, might require some elaborate setup

Integration Test is done on Adapters component which is an implementation on boundaries/contract above.

Acceptance Test is typically done on fully-built application using UI testing framework available on each platform.

As you can see, most of your code (and its related test) would be behind the boundaries while small parts (I/0, rendering, integration) would be outside and generally in smaller amount.

It also show a nice side effect of having your code testable beside having your work easily verified and tested, it also makes your code more modular and each part logically separated e.g: you I/O code dooes not clutter your domain logic part.

Having a good proportion of Developer Test

Testathon – Hackathon For Software Testers

Pada 21 Januari 2017, bertempat di Tanamera Cuisine Jakarta Selatan, 3 orang dari team Test Engineer kami yaitu Dewi Jayanti, Matius Kristian dan Moh Rasyid Fahroni berkesempatan untuk mengikuti kontes bertajuk Testathon – Hackathon For Software Testers. Acara ini cukup bergengsi karena hanya 50 orang terpilih dari semua pendaftar di seluruh Indonesia yang bisa mengikuti acara ini. Berikut adalah report dari acara tersebut yang bisa kami sampaikan. Lanjutkan membaca “Testathon – Hackathon For Software Testers”

Testathon – Hackathon For Software Testers

Persiapan Development Aplikasi Mobile Bola.com – Part 2

Sebagai lanjutan dari post sebelumnya, sekarang kita akan membahas mengenai Design Sprint aplikasi mobile Bola.com.

Design Sprint

Design sprint adalah sebuah proses untuk desain, prototyping, dan melakukan user test terhadap prototype tersebut untuk menjawab pertanyaan bisnis yang dilakukan dalam 6 tahapan dan dalam waktu tertentu, biasanya dilakukan dalam 5 hari. Design Sprint dilakukan untuk mengurangi resiko ketika meluncurkan sebuah produk atau fitur. Dengan Design Sprint kita tidak perlu menunggu minimum product untuk diluncurkan ke pasar terlebih dahulu untuk mengetahui respon dari user, karena di akhir step ada user testing terhadap prototype kita. Tim yang biasanya terlibat dalam Design Sprint ini adalah kolaborasi dari desainer, product manager, decision maker, business team (marketing, sales). 

design-sprint

6 Tahapan Design Sprint

  1. Understand: pada tahapan ini kita mencoba memahami users dan kebutuhannya, kompetisi yang ada serta peluang bisnis. Pada tahapan ini kami melakukan canvasing-exercise untuk memetakan user-profile dengan value-map. User profile menjelaskan lebih jauh mengenai user kita dan value-map menggambarkan bagaimana kita dapat memberikan value untuk user tersebut. (Silakan baca lebih lanjut mengenai The Value Proposition Canvas untuk mengetahui canvasing ini lebih dalam.)
  2. Define: design principles ditetapkan pada tahap ini berdasarkan value propotition yang akan kita berikan.
  3. Diverge: berdasarkan summary yang didapatkan dari tahapan sebelumnya, setiap orang akan membuat beberapa alternatif solusi untuk menyelesaikan permasalah yang ada. Pada tahapan ini feasibility masih belum dipertimbangkan. Setiap orang membuat sketsa solusi masing-masing, agar tidak saling mempengaruhi.
  4. Decide: pada tahap ini, solusi dipilih oleh seluruh tim dengan mempertimbangkan bagaimana solusi tersebut dapat menyelesaikan permasalahan dan tetap dapat dibuat mempertimbangkan limitasi yang ada (teknologi, waktu, dsb.). Kami melakukan Zen Voting dan team review untuk menentukan solusi yang akan dipilih. Kemudian membuat storyboard untuk solusi tersebut dengan lebih detail.
  5. Prototype: desain dan mempersiapkan prototype yang dapat digunakan oleh user. Karena kami akan membuat aplikasi Android, maka prototype yang dibuat menggunakan prototyping tool untuk mobile, agar user experience-nya sama dengan aplikasi yang sebenarnya.
  6. Validate: melakukan user testing menggunakan prototype yang ada kepada primary target audience. Kami melakukan observasi ketika user menggunakan prototype aplikasi Bola.com, kemudian mengajukan beberapa pertanyaan seputar experience, feedback dan ekspektasi mereka terhadap aplikasi tersebut.

Biasanya Design Sprint dilakukan dalam 5 hari, namun karena keterbatasan yang ada kami berhasil untuk menjalankan Design Sprint aplikasi Bola.com dalam 4 hari. Berikut adalah pembagian hari dan aktifitas per hari-nya.

  • Day 1: Understand- Define
  • Day 2: Diverge-Decide
  • Day 3 Prototype-Validate (Internal Validation: primary target user yang merupakan rekan kerja kami)
  • Day 4 Prototype-Validate (primary target user yang sudah dipilih berdasarkan kriteria yang sudah ditentukan)

Specification

Setelah Design Sprint selesai dilakukan, spesifikasi untuk aplikasi Bola.com dibuat dan diprioritaskan untuk selanjutnya masuk ke dalam proses development kami.

Setelah persiapan selesai, masuklah kami ke tahapan development. BTW, aplikasi Bola.com kini sudah ada di Playstore, silakan download aplikasinya di sini.

 

 

Persiapan Development Aplikasi Mobile Bola.com – Part 2

Persiapan Development Aplikasi Mobile Bola.com – Part 1

Aplikasi Android Bola.com, ya/tidak?

Saat ini, publishing plaftform KMK memiliki produk Liputan6.com, Bola.com dan Bintang.com. Liputan6.com sebagai produk publishing perdana sudah memiliki versi web dan mobile app (Android dan iOS). Selanjutnya kami mengembangkan versi aplikasi Android untuk Bola.com. Sebelum memutuskan apakah development aplikasi mobile Bola.com diperlukan, kami menyebarkan kuesioner kepada user Bola.com yang salah satu pertanyaannya adalah apakah user membutuhkan aplikasi mobile Bola.com dan jawabannya adalah 60.2% responden menjawab bahwa mereka membutuhkan bola.com hadir dalam bentuk aplikasi mobile. Jadi, kami melanjutkan ke proses selanjutnya.

Beberapa rangkaian proses yang kami lakukan sebelum memulai development ini adalah sebagai berikut:

1.Kuesioner

Tujuannya adalah untuk mengetahui kebiasaan user serta kebutuhan user akan berita olah raga terutama yang berhubungan dengan penggunaan bola.com saat ini.

2. Design Sprint

Memahami kebutuhan user (berdasarkan hasil dari kuesioner), menjawab kebutuhan user dengan mengajukan solusi-solusi berupa fitur, mengembangkan desain, membuat prototype dan memvalidasi prototype.

3. Specification

Menjabarkan fitur-fitur yang akan dikembangakan sejelas mungkin untuk menghindari kesalahpahaman dan mengidentifikasi sedini mungkin jika ada ketidak-konsistenan requirements.

design-sprint-2

 

Kuesioner

Sebelum memulai pengembangan Bola app, kami memiliki hipotesis awal yaitu, user penggemar bola membutuhkan aplikasi untuk membaca berita Bola, seperti halnya user Liputan6 membutuhkan berita terupdate.

Kuesionerpun disebarkan kepada user Bola.com dan user kanal Bola di Liputan6 melalui email dan media sosial. Pertanyaan seputar kebiasaan user dalam mengakses aplikasi berita olahraga, hingga keinginan dan kebutuhan mereka.

Hasil yang diterima cukup memuaskan, beberapa merupakan insight baru dan lainnya sesuai dengan ekspektasi. Yang pasti, hipotesis awal kami bahwa user Bola mengharapkan berita terbaru dari aplikasi Bola, kurang tepat. Meskipun mereka membutuhkan berita yang update mengenai perkembangan Bola, ada hal lain yang lebih mereka butuhkan. 

Input dari kuesioner ini kami jadikan referensi untuk menentukan pengembangan fitur-fitur aplikasi mobile Bola.com. Tetapi input kuesioner ini saja tidak cukup sebagai dasar pengembangan aplikasi Bola. Seperti quote terkenal dari Henry Ford: “If I had asked people what they wanted, they would have said faster horses.” Jadi, apa tahapan selanjutnya? Kami coba gali lebih jauh kebutuhan user seperti apa bukan hanya apa yang mereka inginkan. Dari beberapa metode yang mungkin, kami memilih untuk melakukan Design Sprint. Apa itu Design Sprint? Bagaimana kami melakukan Design Sprint untuk pengembangan Bola?

Tunggu postingan Part-2 ya.

(Update: Baca part 2 di sini)

Persiapan Development Aplikasi Mobile Bola.com – Part 1