Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Web Design
  2. Documentation
Webdesign

Cara Mendokumentasikan Desain Anda Menggunakan Cerita Pengguna Berbasis Perilaku

by
Length:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Ike purnaniwati (you can also view the original English article)

Masalah umum saat mendokumentasikan persyaratan adalah mengambil sikap dari perspektif sistem untuk menggambarkan apa yang dibutuhkan, melupakan bahwa itu adalah pengguna yang akan berada di pusat interaksi. Kisah-kisah pengguna, yang diperkenalkan oleh Agile, mengatasi masalah ini dengan menjadikan pengguna sebagai pusat persyaratan, dan Behavior Driven Development (BDD) mengambil langkah selangkah lebih jauh dalam menyediakan kerangka kerja di mana perilaku penggunalah yang mendorong pengembangan.

Menggunakan teknik BDD untuk membuat cerita pengguna membuat persyaratan pendokumentasian lebih mudah untuk ditulis dan dibaca. Juga, ia menyediakan alat tambahan untuk mengkomunikasikan pengalaman pengguna yang diinginkan dari sebuah desain, yang desainer, pengembang, dan insinyur QA dapat digunakan untuk melacak cepat dan bahkan mengotomatiskan sebagian dari pekerjaan mereka. Dalam artikel ini saya akan menjelajahi pendekatan ini dan menunjukkan bagaimana Anda dapat menggunakannya untuk dokumen desain sendiri, mulai dari kisah-kisah kecil untuk mengorganisir cerita-cerita untuk berkomunikasi berfungsi penuh fitur. 

Persyaratan UI vs Persyaratan UX

Ada perbedaan penting untuk membuat antara persyaratan UI (juga dikenal sebagai spesifikasi) dan persyaratan UX. Di satu sisi, persyaratan UI adalah dokumen teknis yang daftar spesifik tentang antarmuka pengguna, termasuk jenis font, warna, dimensi dan tata letak elemen. Contoh bagus dari jenis dokumentasi ini adalah Panduan Gaya Hidup.

Persyaratan UX, di sisi lain, menggambarkan pengalaman apa yang seharusnya untuk pengguna tertentu, mengingat bahwa pengguna ini dalam skenario tertentu melakukan tindakan tertentu. Kisah pengguna dapat menangkap persyaratan UX dengan cara yang sangat ringkas. Sebagai contoh:

  • Sebagai... penerbit pengguna,
  • Saya ingin .. dapat meninjau artikel sebelum dipublikasikan,
  • Sehingga .. saya dapat memberikan umpan balik dan memastikan kualitas secara tepat waktu.

Kisah ini menunjukkan pertama peran pengguna, apa yang ingin dicapai pengguna ini, dan kemudian menjelaskan alasan di baliknya. Ini bagus karena memberikan wawasan kepada pengembang dan penguji tentang apa tujuan utamanya adalah: untuk mencukupi kebutuhan pengguna. Perhatikan bahwa kata-kata dalam huruf tebal adalah template yang digunakan untuk menulis cerita. Selalu ada pengguna, yang ingin melakukan sesuatu, sehingga mereka dapat mencapai tujuan tertentu. Anda dapat mengikuti kiat-kiat ini untuk menulis cerita pengguna yang baik.

Dengan mengingat kisah ini, tim desain dapat memutuskan bahwa tindakan 'persetujuan' diperlukan untuk mencapai tujuan pengguna. Kemudian untuk memberikan spesifik tentang bagaimana ini akan benar-benar bekerja, Anda dapat menggunakan sintaks Gherkin, yang merupakan alat BBD untuk menulis persyaratan yang dapat dibaca bisnis. Sintaks Gherkin mirip dengan cerita pengguna yang tangkas karena menyediakan cara penulisan persyaratan yang juga dapat digunakan sebagai templat. Keuntungannya adalah Anda bisa lebih spesifik, menyediakan skenario dan tindakan yang akan diambil pengguna tanpa mengetahui bagaimana implementasi harus dilakukan. Mari kita lihat lebih dekat.

Menulis Cerita Pengguna Menggunakan Gherkin Syntax

Dasar-dasar cerita menggunakan sintaks Gherkin dapat diringkas di bagian-bagian ini:

  • Fitur
  • Skenario
  • Prasyarat
  • Tindakan
  • Hasil

Fitur adalah tempat untuk menggambarkan nilai bisnis keseluruhan dari implementasi. Ini juga dapat digunakan untuk memberikan informasi tambahan, seperti aturan bisnis, atau apa pun yang membuat fitur lebih mudah dipahami (seperti tautan ke prototipe atau persyaratan UI).

Skenario menggambarkan keadaan khusus di mana pengguna berada. Dari perspektif desain pengguna, skenario memungkinkan mengkomunikasikan beberapa variabel dari desain, dan bagaimana UI harus menangani itu, menurut pengguna.

Prasyarat membantu membangun skenario dan menghilangkan ambiguitas apa pun. Sebagai contoh, dalam skenario yang menggambarkan pengguna pertama kali mengakses layar tertentu, prekondisi dapat memperjelas bahwa pengguna login.

Tindakan menunjukkan dengan tepat apa yang dilakukan pengguna di antarmuka, dan biasanya merupakan 'pemicu', seperti mengklik tombol, mengirimkan formulir, atau menavigasi ke tempat lain.

Hasilnya adalah konsekuensi dari tindakan, dan harus selalu menjadi sesuatu yang dapat diuji.

Dengan mempertimbangkan bagian-bagian ini, mari tulis kisah pengguna untuk fitur yang kami jelaskan sebelumnya:

  • Sebagai... penerbit pengguna,
  • Saya ingin .. dapat meninjau artikel sebelum dipublikasikan,
  • Sehingga .. saya dapat memberikan umpan balik dan memastikan kualitas secara tepat waktu.

Menggunakan sintaks Gherkin cerita ini akan terlihat seperti ini:

Fitur
Memungkinkan penerbit untuk meninjau artikel sebelum penerbitan akhir dan stamping persetujuan mereka pada mereka.
Skenario
Menyetujui sebuah artikel yang siap untuk penerbitan.
Prasyarat
  • Mengingat bahwa penulis telah mengajukan sebuah artikel untuk penerbitan.
  • dan penerbit telah diakses tampilan edit artikel
Aksi
  • ketika penerbit memilih "menyetujui"
Hasil 
  • kemudian artikel ini diterbitkan sesuai dengan tanggal yang dijadwalkan
  • dan penerbit melihat tanda keberhasilan menunjukkan artikel berhasil diterbitkan
  • dan artikel adalah ditandai sebagai "disetujui"
  • dan pemberitahuan dikirim ke penulis menunjukkan artikel mereka disetujui.

Anda dapat melihat bagaimana kisah awal berubah menjadi alur yang lebih mendetail yang dapat diikuti oleh pengguna dan oleh karena itu dapat diuji. Juga, perhatikan bahwa kata-kata yang dicetak tebal adalah kata kunci yang digunakan perangkat lunak seperti mentimun untuk mengotomatiskan pelaksanaan tes. Saya akan menjelaskan lebih lanjut tentang ini nanti, tetapi untuk sekarang, saya ingin menunjukkan bahwa kata kunci tersebut sangat berguna juga untuk menulis cerita karena mereka membantu membedakan berbagai cerita.

Hal lain yang perlu diperhatikan adalah bahwa meskipun ceritanya memberikan lebih banyak rincian tentang aliran pengguna, antarmuka tidak dijelaskan. Alasannya adalah bahwa mendeskripsikan UI dapat dengan cepat mengubah cerita menjadi persyaratan UI, yang menghadirkan masalah besar karena mereka bisa menjadi ketinggalan jaman agak cepat. Misalnya, jika ceritanya menggambarkan bagaimana tampilan peringatan sukses dan apa yang harus dikatakan oleh pesan khusus, maka ceritanya dapat menjadi tidak sinkron jika ada perubahan ini, yang menciptakan potensi kegagalan pengujian.

Jadi triknya adalah memberikan detail yang cukup, tanpa melakukan pekerjaan alat yang lebih memadai, seperti desain maket, prototipe, dan panduan gaya. Dalam hal ini, Anda akan melihat bahwa tindakan itu menunjukkan 'memilih menyetujui' vs. hanya menggunakan 'menyetujui'. “Memilih menyetujui” tidak spesifik seperti apa kontrol ini terlihat (bisa berupa tombol, tombol yang terlihat seperti tautan, atau kotak yang dapat diklik), tetapi ini menyiratkan bahwa elemen di UI terpicu. Ini juga menunjukkan bahwa elemen ini telah tertulis di dalamnya 'menyetujui'. Ini adalah area abu-abu di mana Anda perlu menggunakan akal sehat, karena dalam beberapa kasus Anda akan ingin menjadi spesifik ini sehingga tindakan dapat dibedakan dari yang lain. Misalnya, jika ada cara lain untuk menyetujui artikel pada halaman yang sama, menunjukkan bahwa dalam skenario ini pengguna harus 'memilih', memungkinkan membuat perbedaan.

Pentingnya skenario

Selain sintaks yang bijaksana yang Gherkin sediakan, salah satu hal yang menurut saya paling berguna adalah menggunakan bagian 'skenario'. Skenario sangat kuat karena dapat digunakan untuk menguji desain dan memastikan semua basis tercakup.

Biasanya, desain apa pun dimulai dengan 'jalur bahagia', yang berarti apa yang terjadi ketika semuanya berjalan dengan baik di antarmuka, dan bagaimana itu berlaku untuk sebagian besar pengguna. Dalam contoh kami sebelumnya, kami memiliki:

Skenario
Menyetujui artikel yang siap dipublikasikan.

Juga, karena kami tahu bahwa artikel memiliki tanggal penerbitan, kami juga dapat menyatakan: Ini adalah skenario pertama kami karena dalam banyak kasus artikel yang perlu disetujui harus siap untuk dipublikasikan. Tapi ini membawa pertanyaan: apa yang terjadi ketika sebuah artikel tidak siap untuk diterbitkan dan penerbit mengaksesnya? Haruskah mereka bahkan dapat mengakses artikel-artikel itu?

  • Apa yang akan terjadi jika sebuah artikel yang disetujui memiliki tanggal penerbitan di masa lalu? Haruskah artikel itu diterbitkan segera, atau haruskah mereka masuk ke antrian?
  • Dan melangkah lebih jauh, bagaimana jika penerbit menyetujui artikel karena kesalahan? Bagaimana prosedur untuk membatalkan tindakan ini? Siapa yang harus diberi tahu?

Semua pertanyaan ini adalah bagian dari proses desain dan kemungkinan besar pada saat Anda melompat ke persyaratan dokumentasi Anda akan tahu jawabannya. Kabar baiknya adalah bahwa menggunakan skenario dalam dokumentasi cerita Anda akan membantu Anda menyusunnya dan dalam banyak kasus akan membantu Anda QA desain Anda sendiri, memastikan ada desain dan aliran yang ditujukan untuk masing-masing.

Mari kita lihat bagaimana cerita kita akan terbentuk dengan skenario tambahan:

Fitur Izinkan penerbit untuk meninjau artikel sebelum publikasi akhir dan memberikan persetujuan mereka.
Skenario 1 Menyetujui artikel yang siap dipublikasikan.
  • Mengingat bahwa penulis telah mengirimkan artikel untuk diterbitkan
  • dan penerbit telah mengakses tampilan artikel edit
  • ketika penerbit mengklik "menyetujui"
  • kemudian artikel ini diterbitkan sesuai dengan tanggal yang dijadwalkan
  • dan penerbit melihat peringatan sukses yang menunjukkan artikel itu berhasil dipublikasikan
  • dan artikel ditandai sebagai 'disetujui'
  • dan pemberitahuan dikirim ke penulis yang menunjukkan artikel mereka disetujui.
Skenario 2

Mengakses artikel yang belum siap dipublikasikan.

  • Kapan...
Skenario 3

Menyetujui artikel yang memiliki tanggal jatuh tempo

  • Kapan...
Skenario 4

Tidak menyetujui artikel yang memiliki tanggal penerbitan di masa mendatang

  • Kapan...
Skenario 5

Tidak menyetujui artikel yang telah dipublikasikan

  • Kapan...

Bergantung pada fiturnya, ada banyak skenario yang harus dipertimbangkan. Kunci mereka adalah menjaga mereka pendek, sehingga Anda dapat menggambarkan dan mengujinya dengan mudah. Anda juga dapat mencoba mengelompokkan mereka, menggunakan penyebut umum. Misalnya, jika beberapa skenario berbagi prakondisi yang sama, Anda dapat merangkum ini ke dalam 'Latar Belakang' yang dapat digunakan oleh beberapa skenario. Sebagai contoh:

Latar belakang
Penulis telah mengirimkan artikel untuk diterbitkan dan penerbit telah mengakses tampilan artikel edit.
Skenario 1
Menyetujui artikel yang siap dipublikasikan.
  • Mengingat latar belakangnya terpenuhi
  • Kapan...
Skenario 2
Menyetujui artikel yang memiliki tanggal jatuh tempo.
  • Mengingat latar belakangnya terpenuhi
  • Kapan...
Skenario 3
Tidak menyetujui artikel yang memiliki tanggal penerbitan di masa mendatang.
  • Mengingat latar belakangnya terpenuhi
  • Kapan...

Mengatur Cerita untuk Mengkomunikasikan Fitur

Tantangan umum yang muncul ketika mendokumentasikan persyaratan adalah menentukan urutan untuk melakukannya. Alasannya adalah bahwa dalam banyak kasus semuanya sedang dalam pembangunan, yang membuat sulit untuk menguji interaksi ketika bagian-bagian interaksi belum dibangun. Misalnya, dalam interaksi sederhana 'menyetujui' artikel, banyak hal harus siap:

  1. UI harus dapat mengembalikan pesan sukses jika persetujuan berhasil dan pesan kegagalan jika ada masalah sistem.
  2. UI harus dapat 'menandai' artikel sebagaimana disetujui.
  3. UI harus dapat menampilkan artikel sesuai dengan logika bisnis 'yang dipublikasikan'.
  4. Notifikasi sistem harus diaktifkan, sehingga penulis dapat diberi peringatan ketika persetujuan terjadi.

Suatu pendekatan untuk mendokumentasikan persyaratan untuk masing-masing dependensi ini untuk merekam mereka sebagai fitur berbeda yang kemudian dapat diprioritaskan menurut nilai bisnis mereka.

Fitur
Deskripsi
Prioritas
Sistem Siaga
UI harus dapat mengembalikan pesan sukses, serta pesan kegagalan, jika ada masalah sistem
2
Sistem Pemberian Tag
UI harus dapat 'menandai' artikel sebagaimana disetujui
4
Sistem penerbitan
UI harus dapat menampilkan artikel sesuai dengan logika bisnis 'yang dipublikasikan'
1
Sistem pemberitahuan
Notifikasi sistem harus diaktifkan, sehingga penulis dapat diberi peringatan ketika persetujuan terjadi
3

Kemudian Anda dapat membuat cerita 'integrasi' untuk menyatukan semuanya. Misalnya, cerita pengguna untuk sistem pemberian tag akan seperti ini:

Fitur
Izinkan pengguna dan sistem untuk menandai artikel sesuai dengan keadaan tertentu (tidak dipublikasikan, disetujui, dipublikasikan, atau diarsipkan).
Skenario 1
Menandai artikel sebagai tidak dipublikasikan.
  • (rincian...)
Skenario 2
Menandai artikel sebagai disetujui.
  • (rincian...)
Skenario 3
Penandaan artikel yang diterbitkan.
  • (rincian...)
Skenario 4
Penandaan artikel sebagai arsip.
  • (rincian...)

Dalam kisah integrasi, Anda dapat mereferensikan kisah pemberian tag, jika detail untuk skenario tersebut perlu diverifikasi lagi atau jika Anda hanya ingin mengetahui apakah kasus tersebut sudah diverifikasi.

Fitur
Memungkinkan penerbit untuk meninjau artikel sebelum penerbitan akhir dan Cap persetujuan mereka pada mereka.
Skenario 1
Menyetujui sebuah artikel yang siap untuk penerbitan.
  • Mengingat bahwa penulis telah mengirimkan artikel untuk diterbitkan
  • dan penerbit telah mengakses tampilan artikel edit
  • ketika penerbit mengklik 'menyetujui'
  • maka artikel itu diterbitkan sesuai dengan tanggal yang dijadwalkan
  • dan penerbit melihat peringatan sukses yang menunjukkan artikel itu berhasil dipublikasikan
  • dan artikel ditandai sebagai 'disetujui' (skenario referensi 2 dari kisah pemberian tag)
  • dan pemberitahuan dikirim ke penulis yang menunjukkan bahwa artikel mereka disetujui.

Intinya adalah untuk menghindari pengulangan dokumentasi yang tidak hanya menghabiskan waktu yang tidak perlu, tetapi juga yang dapat menjadi tidak sinkron.

Mengubah Cerita Pengguna menjadi Kasus Uji

Kami telah melihat betapa bergunanya Behavioral Driven User Stories dapat untuk menulis persyaratan yang terfokus, ringkas, tetapi juga menyeluruh dan deskriptif. Mulai dari tahap desain, alat ini dapat meminjamkan primer yang baik untuk insinyur QA untuk menulis kasus uji yang sebenarnya.

Selain keuntungan besar ini, Kisah Pengguna yang Dipengaruhi Perilaku dapat benar-benar diubah menjadi tes fungsional dengan bantuan perangkat lunak, seperti Ketimun atau Selada. Ide dasarnya adalah bahwa setelah cerita ditulis menggunakan sintaks Gherkin, Anda dapat menempatkannya dalam file .fitur di dalam aplikasi Anda, dan kemudian menjalankannya sebagai tes untuk menunjukkan apakah mereka berhasil atau tidak. Untuk tutorial mendalam tentang cara menggunakan Selada untuk pengujian penerapan Python, tutorial David Sale:

Kesimpulan

Menulis cerita pengguna menggunakan prinsip-prinsip BDD dapat berfungsi untuk berkomunikasi secara rinci persyaratan bisnis dan desain, dengan pendekatan yang berpusat pada pengguna, sementara menggunakan bahasa yang dapat dibaca manusia namun dapat diperpanjang untuk interpretasi perangkat lunak. Selain itu dapat digunakan untuk menguji:

  • desain Anda sendiri saat Anda mendokumentasikan persyaratan
  • aplikasi yang sebenarnya secara manual, sekali berubah menjadi kasus uji oleh seorang insinyur QA
  • aplikasi yang sebenarnya secara otomatis, ketika berubah menjadi tes fungsional yang menggunakan perangkat lunak BDD.

Ini berarti lebih banyak lapisan untuk bug untuk pergi melalui, mencegah kesenjangan dalam desain dan lebih lanjut bulletproofing aplikasi Anda dari bug kegagalan.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.