Ini dia hasil karya terakhirku... gelang n kalung yg dibuat dari batik. cekidooot ;)
Itu sih minta dielus, tapi malah digampar
5 years ago
Thursday, February 16, 2012
Berkarya
Berhubung sekarang lg banyak waktu luang, jd daripada terbuang sia-sia lebih baik dimanfaatkan utk buat prakarya deh... untung-untung klo banyak yg suka trus bisa dijual... hihihi... :P
Ini dia hasil karya terakhirku... gelang n kalung yg dibuat dari batik. cekidooot ;)
Ini dia hasil karya terakhirku... gelang n kalung yg dibuat dari batik. cekidooot ;)
Monday, May 2, 2011
Little Note about Bug Advocacy
Lagi cari-cari file buat referensi kerjaan, eh... ketemu tulisan kenangan yang aku buat untuk nge-claim 'Expert' untuk Bug Advocacy competency item di PT M dulu :P
Yah... itung-itung buat share ilmusekalian nambahin postingan di blog ini biar ga sepi-sepi amat... ahahay ^o^
*berhubung yang punya PT M wong londo (a.k.a. bule), dan kebanyakan client nya juga wong londo, jadi kebiasaan disana ya kalo untuk komunikasi yg formal, terutama yg tertulis, yah harus pake bahasanya wong londo... jadinya artikel nya in english deh... belepotan dikit gpp yee, asal intinya tersampaikan ^_^
~~~~~~~~~~~~~~~~~~~~~ ** ~~~~~~~~~~~~~~~~~~~~~~~
Cem Kaner said that Bug Reports are Software Testers’ primary work product. The best tester is not the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.
The question is how could we make programmers (developers) to fix our bug? It is by “selling” our bugs to them.
There were times where developers would make excuses or reasons for defending the code they built. Sometimes they might even argue about the defect that we found. This often happen when my team and I found a defect that only happened in a certain environment; for example, the application runs well in Mozilla, but not in IE7. Therefore, before the testing began, I confirmed the required environment (agreed by stakeholders) first; i.e. IE7. Many developers weren’t aware about this agreement at first, because they were developing using Mozilla as their browser. Therefore I motivated my team to always write the testing environment; the test site we use (because we have many application servers for testing and development purposes), the browser we use and give them the understanding about the agreed environment.
Testing a big system which has many integrated modules is quiet challenging. We often find defects that the main problem is not in the module (area) that we are currently testing. In this case, instead of just report the defect in that particular area, we need to trace the source of the trouble. For example, when I found a page that was sometimes becoming run time error, but some other times it worked just fine. Instead of reporting “if you lucky, you’ll find it” or “keep trying until the error happen” in my defect report, I put some extra effort to isolate the defect. And then, it appears that the defect was caused by the auto numbering feature that caused a SQL deadlock when 2 or more pages with auto numbering value are accessed in the same time. By knowing the exact way of how to reproduce the defect, we make our defect accountable.
Sometimes, in order to make our defects fixed, putting the impact (what would happen if the defect is not fixed) would make our defect report more convincing. For example, I often report defects that related to usability that could potentially be ignored by the developer because they would think that the defect is unimportant. One of my experience, when I was doing localization testing, I found that a description of an item is only displayed when user’s language preference was same as item’s language description that has been inserted. While user is not required to insert description in all language preferences, there is a chance that when user open an inventory list, the list would only display the number without description and it will be annoying for the user. By letting they know about the impact of the bug we reported, will add the “selling point” of our defect.
Talking about impact, it is closely related to severity level. In the beginning of our testing period, the development team argued about severity level that testers have set for several defects. It happened because every person might have different point of view in seeing a problem (defect). In order to minimize this kind of dispute, I decided to share a guideline (the related email is attached) for setting the severity level to help my team and to let the development team knows the standard that the testers follow.
In the current project I tests, my team and I often faced with the fact that the oracle (BRS and SRS) are not up to date; indicated by many functionalities that are not described in the BRS or SRS. When this situation is happening, I always motivate my teammates to confirm the feature to the responsible Analysts (I recommend to use the email, so we could have evidence) and log a requirement defect if the feature has worked properly but has not been documented, or create another defect if the feature is not working as it should.
Tester’s customer (buyer) is developer; therefore, we need to make a good impression to developers so they can trust us and willing to fix our defects. In order to provide a good and convincing defect reports, our soft skills as Software Testers are also challenged. We need to avoid embarrassing or offend the developer’s feeling, in the other hand, we also need to make them fix our bugs. How to convey the issues we found to developers through direct discussion, IM, email and also defect reporting tool are important. At first, we found it difficult to work with developers in this project because we have not got their trust yet. The developers (especially their ANs) often said that we had not tested the system thoroughly even though we had found many critical defects, etc. But our hard work has now been paid; it is a lot easier to escalate issues that we found during our testing and make developers fix our bugs.
Originally created on: 18 Nov 2010
by: Maria Christanti
~~~~~~~~~~~~~~~~~~~~~ ** ~~~~~~~~~~~~~~~~~~~~~~~
Semoga bermanfaat...
Cheers ^^
Yah... itung-itung buat share ilmu
*berhubung yang punya PT M wong londo (a.k.a. bule), dan kebanyakan client nya juga wong londo, jadi kebiasaan disana ya kalo untuk komunikasi yg formal, terutama yg tertulis, yah harus pake bahasanya wong londo... jadinya artikel nya in english deh... belepotan dikit gpp yee, asal intinya tersampaikan ^_^
~~~~~~~~~~~~~~~~~~~~~ ** ~~~~~~~~~~~~~~~~~~~~~~~
Cem Kaner said that Bug Reports are Software Testers’ primary work product. The best tester is not the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.
The question is how could we make programmers (developers) to fix our bug? It is by “selling” our bugs to them.
There were times where developers would make excuses or reasons for defending the code they built. Sometimes they might even argue about the defect that we found. This often happen when my team and I found a defect that only happened in a certain environment; for example, the application runs well in Mozilla, but not in IE7. Therefore, before the testing began, I confirmed the required environment (agreed by stakeholders) first; i.e. IE7. Many developers weren’t aware about this agreement at first, because they were developing using Mozilla as their browser. Therefore I motivated my team to always write the testing environment; the test site we use (because we have many application servers for testing and development purposes), the browser we use and give them the understanding about the agreed environment.
Testing a big system which has many integrated modules is quiet challenging. We often find defects that the main problem is not in the module (area) that we are currently testing. In this case, instead of just report the defect in that particular area, we need to trace the source of the trouble. For example, when I found a page that was sometimes becoming run time error, but some other times it worked just fine. Instead of reporting “if you lucky, you’ll find it” or “keep trying until the error happen” in my defect report, I put some extra effort to isolate the defect. And then, it appears that the defect was caused by the auto numbering feature that caused a SQL deadlock when 2 or more pages with auto numbering value are accessed in the same time. By knowing the exact way of how to reproduce the defect, we make our defect accountable.
Sometimes, in order to make our defects fixed, putting the impact (what would happen if the defect is not fixed) would make our defect report more convincing. For example, I often report defects that related to usability that could potentially be ignored by the developer because they would think that the defect is unimportant. One of my experience, when I was doing localization testing, I found that a description of an item is only displayed when user’s language preference was same as item’s language description that has been inserted. While user is not required to insert description in all language preferences, there is a chance that when user open an inventory list, the list would only display the number without description and it will be annoying for the user. By letting they know about the impact of the bug we reported, will add the “selling point” of our defect.
Talking about impact, it is closely related to severity level. In the beginning of our testing period, the development team argued about severity level that testers have set for several defects. It happened because every person might have different point of view in seeing a problem (defect). In order to minimize this kind of dispute, I decided to share a guideline (the related email is attached) for setting the severity level to help my team and to let the development team knows the standard that the testers follow.
In the current project I tests, my team and I often faced with the fact that the oracle (BRS and SRS) are not up to date; indicated by many functionalities that are not described in the BRS or SRS. When this situation is happening, I always motivate my teammates to confirm the feature to the responsible Analysts (I recommend to use the email, so we could have evidence) and log a requirement defect if the feature has worked properly but has not been documented, or create another defect if the feature is not working as it should.
Tester’s customer (buyer) is developer; therefore, we need to make a good impression to developers so they can trust us and willing to fix our defects. In order to provide a good and convincing defect reports, our soft skills as Software Testers are also challenged. We need to avoid embarrassing or offend the developer’s feeling, in the other hand, we also need to make them fix our bugs. How to convey the issues we found to developers through direct discussion, IM, email and also defect reporting tool are important. At first, we found it difficult to work with developers in this project because we have not got their trust yet. The developers (especially their ANs) often said that we had not tested the system thoroughly even though we had found many critical defects, etc. But our hard work has now been paid; it is a lot easier to escalate issues that we found during our testing and make developers fix our bugs.
Originally created on: 18 Nov 2010
by: Maria Christanti
~~~~~~~~~~~~~~~~~~~~~ ** ~~~~~~~~~~~~~~~~~~~~~~~
Semoga bermanfaat...
Cheers ^^
Wednesday, December 15, 2010
The Palace of Illusion (Istana Khayalan)
The Palace of Illusions by Chitra Banerjee DivakaruniMy rating: 5 of 5 stars
Buku hasil tukeran dengan Mia DQ (lagi) hehe...
Bukunya tebel, jadi rada lama bacanya. Tapi, keseluruhan ceritanya bagus banget. Karena dikisahkan dari sudut pandang perempuan, kisah Mahabharata ini jadi terasa lebih intim dan romantis.
Meskipun Dropadi menikahi para Pandawa yang sangat hebat itu, namun hatinya tidak pernah berhenti mencintai Karna yang sederhana. Mencengangkan bagaimana cinta bisa benar2 tercipta dari pertemuan singkat yang justru menyakitkan. Menyakitkan bukan hanya bagi Karna yang mendapat penghinaan dari wanita yang diingininya, tapi juga bagi Dropadi yang terpaksa menyakiti hati lelaki yang sebenarnya telah merebut hatinya itu demi menghindari kakaknya dari pertengkaran yang mungkin dapat membahayakan nyawa kakak yang dicintainya itu... dan banyak lagi kisah2 menakjubkan lain yang diungkapkan dalam buku ini dengan cara penyampaian khas perempuan.
View all my reviews
Little Women
Little Women by Louisa May AlcottMy rating: 5 of 5 stars
Kisah dari Meg, Jo, Beth n Amy benar2 tak lekang oleh jaman. Walaupun kisah ini sudah ditulis sejak abad ke 19, tapi tetap berkesan sampai saat ini. Sarat dengan nilai-nilai moral yang sangat bermakna, buku ini wajib dibaca oleh semua perempuan di seluruh dunia *rada lebay sepertinya heheheh...
Kesederhanaan tidak menghalangi 4 gadis yang luar biasa ini untuk tetap menikmati dan bahkan berbagi dengan orang lain. Betapa menyenangkan hubungan mereka berempat. Mereka selalu berbagi kisah dan kasih sayang satu sama lain. Meskipun mereka selalu berkeluh kesah mengenai beratnya beban yang harus mereka tanggung, namun selalu ada saja salah satu dari mereka yang bertugas utk 'membangunkan' yang lain sehingga pada akhirnya mereka selalu bersyukur dan optimis kembali dengan keadaan mereka - seringkali Beth lah yang mengambil peran ini ^^
Membaca buku ini benar2 membangkitkan rasa iri... iri dengan kebaikan hati mereka, iri dengan ketabahan mereka, bahkan iri dengan kedekatan mereka satu dengan lainnya... Ah... seandainya aku punya saudara2 perempuan seperti Meg, Jo, Beth n Amy... pasti seru sekali... sayangnya satu2nya saudara perempuanku sudah menjadi orang yg benar2 asing semenjak kenal dengan kekasihnya yg sekarang... *loh, kok jadi curcol... hehehe...
Inget pernah baca versi komik n jatuh cinta ma si Meg, Jo, Beth n Amy ever since hahaha... *tapi sayangnya aku lupa judul komiknya... hicks... seingetku sih judulnya Little March... Tapi kenapa susah banget yah cari komiknya lagi... kemaren beli komik bekas dgn judul Little March, tapi ternyata isinya beda jauh... T__T jadi sedikit meragukan ingatanku sendiri nih... (-.-)'
View all my reviews
Little Vampire Women
Little Vampire Women by Lynn MessinaMy rating: 2 of 5 stars
Read few chapters of this book on a half hour flight from Surabaya to Denpasar. I thought the story would continue the original version. But I was totally wrong *and disappointed :( since I am not a big fan of Vampire. The story is re-telling the original version with the main characters are Vampire. Argh... this vampire thing just broke the sweetness and innocence of March girls.
2 stars are for my forever star, the original March girls; not for the vampire girls.
View all my reviews
Subscribe to:
Posts (Atom)
