• Testing

    Tester có phải là con đường chạy trốn khỏi Dev?

    Đáp: Không.

    Testing không phải là nơi an toàn cho những ai muốn tìm một nơi chỉ để trú ẩn (dù là từ Dev hay bất cứ ngành nào khác chuyển sang). Tester là một nhánh nghề nghiệp với một career path rõ ràng và lâu dài dành cho những bạn có đam mê với công việc tìm lỗi cũng như hướng đến sự hoàn thiện của sản phẩm. Nơi đó không an toàn vì nhữ lý do sau đây:

    • Bạn phải cập nhật thêm công nghệ và kiến thức liên tục, bạn cần tiếp xúc và test trên những môi trường mới nhất mà người dùng đang hoặc sắp sử dụng trên thị trường. Nếu bạn không thích sự thay đổi thì rất khó theo được công việc.
    • Bạn phải làm OT (over time) như ai, nhất là những lúc sản phẩm sắp lên môi trường production.
    • Testing chịu khá nhiều áp lực về thời gian, số lượng công việc cũng như áp lực trong lúc làm việc với các roles/team khác, nhất là khi người kia nghĩ kiểm tra và đảm bảo chất lượng là việc của riêng tester.
    • Bạn phải chịu trách nhiệm về chất lượng sản phẩm, tuy hiện nay mọi người thường nói chất lượng sản phẩm là trách nhiệm chung của cả nhóm, nhưng tin tôi đi – của bạn là chính đó, khi sản phẩm có lỗi thì dù ai là nguyên nhân chính thì hình ảnh cá nhân bạn cũng bị ảnh hưởng. Khi phần mềm chạy tốt khách hàng sẽ khen đội ngũ developer giỏi, nhưng khi có lỗi hay vấn đề gì là họ sẽ hỏi ai đã test phần này? và bạn là tester chứ ai.
    • Sẽ phải code, có lẽ lý do bạn nghĩ test là con đường chạy trốn vì ở nơi đó bạn không phải lập trình, nhưng thật ra trước sau gì bạn cũng sẽ phải học code, không phải HTML, CSS thì là SQL, không SQL thì cũng Java hay C#, để tồn tại lâu dài và thăng tiến nhanh thì việc biết code là điều gần như thiết yếu. Ngoài ra Automation cũng đang phát triển và thành xu hướng trong hiện tại và tương lai rất gần, bạn cần phải code.
    • Sẽ rất chán, nếu bạn thấy việc làm dev chán và muốn chuyển sang test “cho vui” thì nên nghĩ lại. Vì đôi lúc bạn phải làm đi làm lại một việc gì đó để đảm bảo là nó vẫn còn chạy tốt, có khi việc lặp lại quá lâu và nhiều sẽ làm bạn phát điên lên. Chỉ có niềm đam mê tìm lỗi mới giúp bạn vượt qua được cảm giác khó chịu này.

    Testing là nghề hấp dẫn, nhưng không phải là con đường để chạy trốn, vì nó không nhẹ nhàng.

  • Testing

    Cách viết một email hiệu quả

    Viết tốt một email không chỉ giúp người nhận nắm đầy đủ và chính xác các thông tin cần trao đổi mà còn thể hiện được kinh nghiệm, kiến thức và cách làm việc chuyên nghiệp của người gởi. Bài này tôi chia sẻ về cách viết một email sao cho đúng cách và hiệu quả dựa trên kinh nghiệm và công việc hiện tại.

    1. Cách trình bày.

    Về cấu trúc, một email nên có các thành phần sau:

    • Subject
    • Greeting
    • Introduction
    • Main content
    • Final sentence
    • Closing
    • Your name & signature

    – Subject: Tiêu đề của email cần gởi nên ghi ngắn gọn nhưng bao quát được vấn đề chính, một tiêu đề tốt sẽ giúp người đọc dễ dàng biết được nội dung của bức thư, có thể xếp độ ưu tiên để đọc cũng như dễ dàng lưu trữ và tìm kiếm lại về sau. Một ví dụ về Good & Bad Subject:

    Bad Subject: Process Meeting.
    Good Subject: Project ABC Testing Process Meeting – 10 a.m. February 01, 2016.

    – Greeting: Có nhiều cách để chào mở đầu email, bạn có thể dùng Dear, Hi, Hello hoặc đơn giản là ghi tên người nhận tùy thuộc vào văn hóa của mỗi tổ chức, tôi thường dùng “Hi” cho thân thiện và không quá trang trọng. Một vài Greeting tham khảo:

    Dear Professor Smith,
    Hello Ms. McMahon,
    Hi Mary Jane,
    Bill,

    Introduction: Nếu là lần đầu tiên trao đổi và người nhận chưa biết bạn là ai thì cần thiết thêm phần này để giới thiệu ngắn gọn who you are? where are you from? để người nhận biết được họ đang trao đổi với ai. Nếu đã biết nhau thì không cần phần này.
    Main content: Nội dung chính của email, cần ghi ngắn gọn và đi thẳng vào vấn đề, chia thành nhiều đoạn nhỏ nếu nội dung trao đổi nhiều, tránh ghi chung tất cả thành một đoạn dài.
    – Final sentence: Sau phần nội dung chính thường sẽ có một dòng ngắn gọn để cảm ơn người nhận, nhất là khi bạn yêu cầu hay nhờ giúp đỡ một việc gì đó, một vài câu hay dùng sau phần main content.

    Thank you for your time and consideration
    I’m looking forward to hearing from you
    Have a wonderful Thanksgiving!

    Closing: Có khá nhiều cách để kết thúc email như:

    Thank you,
    Best wishes,
    See you tomorrow,
    Regards,
    Sincerely,
    Respectfully yours, 

    Your name & signature: Tên bạn (người gởi) và chữ ký. Thông tin này cũng khá quan trọng cho việc nhận biết người gởi cũng như liên lạc lại nếu cần. Chữ ký nên kèm các thông tin cá nhân của người gởi bao gồm Tên, chức danh, bộ phận, thông tin liên lạc (email, phone, social links). Ví dụ một mẫu chữ ký:


    Mary Johnson
    Web Developer
    University Communications

    Drexel University
    3141 Chestnut Street
    Main Building, Suite 305
    Philadelphia, PA 19104
    Tel: 215.895.2000 | Fax: 215.895.6903
    drexel.edu

    Nếu hoàn thành tốt các phần trên bạn sẽ có một email với định dạng tương tự bên dưới, đây là một mẫu email khá tốt có thể tham khảo và học hỏi:

    good_email_format

    …Và đây là một mẫu email chưa tốt để rút kinh nghiệm:

    bad_email_example

    2. Mẹo nhỏ:

    • Đọc lại email trước khi bấm “Gởi”. Kiểm tra lỗi chính tả, dấu chấm câu, viết hoa thường.
    • Ghi nội dung email trước, sau khi hoàn chỉnh mới nhập email người nhận vào sau. Tránh trường hợp gởi nhầm khi email chưa hoàn chỉnh.
    • Tập trung vào vấn đề chính, bỏ bớt các ý hay câu từ không cần thiết.
    • Kiểm tra file đính kèm trước khi gởi, rất nhiều trường hợp gởi mail nhưng quên đính kèm và phải recall hay gởi lại mail mới.
    • Keep CC tất cả những người bạn đề cập đến trong email.
    • Hạn chế dùng định dạng màu sắc, in đậm, in hoa nếu không cần thiết. Ưu tiên dạng chữ plain text.
    • Kiểm tra lại các link bạn đính kèm trong mail trước khi gởi bằng cách click hoặc truy cập thử.
    • Nếu nội dung phần main content quá ngắn, bạn có thể ghi vào tiêu đề (Subject). Ví dụ Subject: Could you please send the February sales report? Thanks!
    • Tránh gởi nhầm địa chỉ, hoặc Reply All đến nhiều người không liên quan.

    Đây là những chia sẻ của tôi, hy vọng nó sẽ hữu ích!

  • Testing

    Học gì để trở thành một Tester?

    Tôi viết bài này để chia sẻ với các bạn sinh viên có dự định làm về kiểm thử phần mềm (tester) trong tương lai, hy vọng sẽ cung cấp thêm thông tin giúp các bạn dễ dàng có được định hướng cho con đường của mình. Để trả lời câu hỏi “Học gì để trở thành một Tester?” tôi nghĩ cần phải đi qua các ý sau:

    1. Tester sẽ làm những công việc gì?

    Nhìn chung công việc chính của tester là đảm bảo chất lượng của phần mềm, kiểm tra để phát hiện các lỗi  đang tồn tại trước khi giao sản phẩn cho khách hàng, tùy thuộc vào dự án cũng như công ty mà vai trò của tester tham gia sâu đến mức nào. Tester thường chia ra làm 2 hướng chính là Manual test và Automation test.

    • Manual testing: đây là lựa chọn của đa số các bạn bắt đầu làm test, với lựa chọn này bạn không cần nhiều kiến thức về lập trình cũng như sẽ ít đụng vào code trong lúc làm, tuy nhiên cần phải nắm khá vừng về các định nghĩa, kỹ thuật test manual và có tư duy tìm lỗi tốt.
    • Automation testing: đây thường là lựa chọn của các bạn đang làm Developer mà muốn chuyển sang làm Tester, hoặc các bạn làm manual lâu năm muốn học hỏi thêm cái gì đó mới mẻ và nâng cao trình độ của mình. Automation test có thể nói là Dev trong Test, công việc chính là sẽ viết code để thực hiện việc kiểm tra một cách tự động và phần lớn thời gian sẽ làm việc với code như một developer. Người làm automation sẽ không cần thiết phải nắm sâu về các kiến thức test manual nhưng thay vào đó phải biết rõ về các automation tools & frameworks cũng như có thể làm việc được trên nhiều ngôn ngữ lập trình khác nhau như Java, C#, AutoIT, Python, C++ v.v, tùy theo yêu cầu dự án.

    Automation không phải là nâng cao của manual vì nó là hai nhánh khác nhau, cả hai đều quan trọng cũng như có độ khó nhất định nếu phải học và tìm hiểu sâu. Người làm manual tốt không chắc có thể viết code được và người làm automation cũng chưa chắc sẽ có được tư duy, khả năng quan sát & kiến thức kiểm thử manual nên bạn cứ chọn một hướng phù hợp với khả năng và bắt đầu học, không nên tìm hiểu cùng lúc cả hai trong giai đoạn mới vào sẽ tốn rất nhiều thời gian.

    2. Tester cần những kiến thức gì?

    – Đầu tiên, tester cũng giống như bất cứ ngành nào khác trong lĩnh vực phần mềm là cần một nền tảng căn bản về máy tính. Kiến thức căn bản này bạn có thể học được trong chương trình cao đẳng, đại học. Hiện nay giáo trình đào tạo cao đẳng, đại học về công nghệ thông tin của các trường cũng khá đầy đủ, bao quát nhiều kiến thức như hệ điều hành, database, lập trình, mạng…. Những kiến thức này tuy có vẻ không ứng dụng được gì trong lúc học nhưng sẽ rất hữu ích cho việc học test và đi làm sau này, nếu bạn tập trung học trong giai đoạn sinh viên thì sau khi ra trường việc học thêm một khóa về kiểm thử là khá nhanh và đơn giản hơn nhiều.

    – Nếu bạn học ngành khác nhưng muốn chuyển sang làm test (chưa học gì nhiều về công nghệ thông tin trong trường) thì sẽ khó khăn và tốn nhiều thời gian hơn vì bạn phải học lại căn bản, cũng như sẽ bị sót nhiều kiến thức nếu chỉ đăng ký một khóa học test ngắn hạn. Nhưng nói vậy không có nghĩa là không thể, cũng có nhiều bạn đang làm test và khá thành công nhưng xuất phát từ các ngành khác như sư phạm, kinh tế. Nếu bạn cũng đang học trái ngành thì có 2 bước cần thực hiện đó là dành thời gian học cách sử dụng tốt máy tính, tin học văn phòng, đọc thêm các sách căn bản về máy tính, lập trình (có thể mượn từ các bạn đang học CNTT). Giai đoạn này sẽ tốn khoảng 3 đến 6 tháng (hoặc hơn), tuy hơi dài nhưng sẽ rất có giá trị. Tiếp theo bạn cần học thêm về các kiến thức chuyên ngành testing, giai đoạn này sẽ ngắn hơn, thường là khoảng 2 đến 3 tháng, chi tiết học gì tôi sẽ nói ở phần sau.

    – Tiếng Anh, cái này không liên quan test nhưng rất quan trọng, tiếng Anh tốt bạn có nhiều cơ hội để đậu vào các công ty hơn cũng như dễ dàng học thêm về test sau này vì tài liệu đa số là tiếng Anh.

    Vậy tóm tắt lại, có 3 kiến thức tester cần trang bị là Nền tảng về máy tính + Kiến thức Test căn bản + Tiếng Anh

    3. Học gì để trở thành tester?

    3.1. Kiến thức chung: (dù bạn chọn theo hướng nào thì cũng nên nắm các kiến thức này).

    – Kiến thức căn bản về máy tính, tin học văn phòng căn bản, cài đặt phần mềm, sử dụng internet.
    – Kiến thức về lập trình: Căn bản SQL, HTML, CSS. Đây là 3 món tôi nghĩ rất cần thiết khi làm test, bạn không cần phải học sâu để viết code nhưng ít ra phải đọc hiểu được và có thể chỉnh sửa code đơn giản.
    – Kiến thức tổng quan về test, bao gồm việc hiểu các định nghĩa cơ bản, các thuật ngữ, quy trình phát triển phần mềm, quy trình test. Bạn có thể học theo cuốn ISTQB Foundation hoặc tham khảo các mục gợi ý sau:

    • What is Software Testing? – Tìm hiểu phần này để biết được testing là gì? các định nghĩa, khái niệm căn bản về kiểm thử phần mềm.
    • Why is Software Testing Important? – Tại sao testing lại quan trọng và cần thiết? nếu không có tester thì sản phẩm sẽ ra sao?
    • Software Development life cycle: Vòng đời phát triển phần mềm, vị trí của testing trong các giai đoạn phát triển sản phẩm.
    • Software Test life cycle: Vòng đời của kiểm thử, thứ tự các công việc kiểm thử.
    • Defect Life Cycle: Vòng đởi của lỗi và trạng thái qua các giai đoạn.
    • Quality Assurance vs. Quality control, Verification vs Validation: Phân biêt sự giống nhau và khác nhau giữa một số khái niệm.
    • Software Testing Levels: Các mức độ trong kiểm thử, đi từ nhỏ nhất đến các mức độ cao nhất.
    • Software Testing types: Các loại testing thư Functional testing, Non-functional testing, Structural testing, Change related testing.

    3.2. Phần kiến thức riêng:

    Manual Test:

    Đây là danh sách các kiến thức bạn nên tìm hiểu sâu thêm nếu sẽ làm test theo hướng manual.

    • Create a Test Plan: Các thành phần cần có trong một test plan cơ bản, cách viết test plan.
    • Design Test case: Cách tạo và viết một testcase thông dụng.
    • Test Design Techniques: Các kỹ thuật thiết kế testcase, giúp cho testcase hiệu quả và tối ưu hơn.
    • Test reporting, Daily status reports – cách viết report để báo cáo kết quả test của mình.
    • Defect management: Finding defects, Logging defects, Tracking and managing defects – Học cách report & quản lý một bug cũng như sử dụng tools tracking thông dụng như Jira, Mantis, Bugzilla, Application Lifecycle Management (ALM).
    • Mobile application testing (iOS, Android, Windows Phone): Cách cài đặt và test ứng dụng mobile, cách giả lập thiết bị điện thoại trên máy tính.
    • Windows, Website testing & Tools support: Cách test một ứng dụng desktop, một trang web và giả lập các trình duyệt khác nhau trên máy tính.
    • Risk based testing process and implementation: Đánh giá rủi ro trong kiểm thử, đây là phần nâng cao nhưng cũng nên tìm hiểu qua.
    • Coding: SQL, HTML, CSS.

    Một số trang để tự học các kiến thức về manual testing căn bản, các trang này cung cấp đầy đủ các kiến thức bên trên cũng như mở rộng thêm khá nhiều kiến thức liên quan đến test khác:

    Automation Test:

    • Học thêm về lập trình: Java, C# (.Net) là hai ngôn ngữ căn bản mà những người làm automation hay sử dụng, ngoài ra có các ngôn ngữ khác dùng để hỗ trợ như AutoIT, Python.
    • Học về các Automation Tool/Framework phổ biến như: Ranorex, Selenium, Appium, TestComplete.
    • Các Tools khác như: Jmeter, SoapUI.

    Các địa chỉ học về Automation & Lập trình:

    Nếu chưa biết nên bắt đầu từ đâu tôi gợi ý là bắt đầu vơi bộ tools Selenium (thường dùng Java) hoặc Ranorex (C# hoặc .Net nói chung). Với Selenium (miễn phí) bạn có thể làm được automation cho website còn Ranorex thì có thể làm được trên website, mobile application và desktop application nhưng có tốn phí khá cao.

    4. Học test ở đâu?

    • Có ba cách cơ bản để học test là tự học, học ở trung tâmhọc nhóm. Đa số các tester thuộc thế hệ 8x hay 9x đời đầu đều tự học mà làm vì giai đoạn đó testing chưa phát triển và cũng chưa có trung tâm chuyên đào tạo, các trường đại học cũng chưa đưa vào chương trình dạy. Nhưng tôi thấy đa số tester ở giai đoạn này thường xuất thân từ CNTT nên việc tự học và học thêm về test cũng khá nhanh. Để tự học test bạn có thể vào các nguồn tôi cung cấp ở phần bên trên, nó khá đầy đủ kiến thức căn bản.
    • Thứ hai là có thể đi học ở trung tâm hay một nhóm nào đó, các trung tâm thường có các khóa đào tạo ngắn hạn trong khoảng 3 tháng đỗ lại, một số trung tâm thì có chương trình dài hơn nhưng thường không quá 6 tháng. Tôi tự học và chưa trải nghiệm qua trung tâm nào nên cũng không rõ chất lượng ở những nơi đó, nhưng tôi cũng rất vui lòng nếu bạn gởi email cá nhân đến tôi để tham khảo về các trung tâm bạn đang định học, tôi sẽ thông qua một số mối quan hệ và bạn bè để hỏi giúp ban chất lượng của những nơi đó.
    • Ngoài ra còn một cách học khác là học nhóm, dạy kèm test, cách này tôi đang áp dụng ở một vài nhóm và thấy khá hiệu quả vì nó vừa linh động về thời gian và số lượng học viên thường giới hạn ít nên sẽ dễ tiếp thu hơn, thời gian học khoảng 1 đến 2 tháng. Nếu bạn quan tâm đến những khóa học này cũng có thể email đến tôi, khi nào bắt đầu khóa mới về testing căn bản tôi sẽ cho bạn biết.

    5. Tổng kết.

    Trong giai đoạn mà chất lượng sẽ quyết định sự tồn vong của sản phẩm phần mềm thì tầm quan trọng của Tester ngày càng được nâng cao và đóng vai trò quan trọng, các dự án cũng cần nhiều tester hơn nên trong tương lai nghề test sẽ phát triển mạnh mẽ, việc định hướng và trang bị kiến thức sớm từ bây giờ là rất cần thiết. Sau khi nắm được các kiến thức căn bản, bạn hãy tìm một công ty hay một dự án nào đó để bắt đầu làm, giai đoạn này rất quan trọng vì chỉ có bắt tay vào làm bạn mới hình dung rõ ràng hơn các khái niệm đã đọc cũng như học thêm cái mới trong lúc làm thực tế. Hy vọng bài này sẽ cung cấp những thông tin giúp bạn có thể bắt đầu vào việc học thuận tiện hơn.

    Như mọi khi, đừng ngại email đến tôi hoặc comment tại bài này nếu bạn có thắc mắc hay muốn trao đổi thêm điều gì đó trong lúc học, tôi rất vui để chia sẻ.

  • Testing

    Đặt một câu hỏi hay

    Tôi có tham gia vài nhóm trên facebook và skype để trao đổi về testing, có khá nhiều câu hỏi được đặt ra mà không có câu trả lời phù hợp và nguyên nhân chủ yếu chính là do cách đặt câu hỏi thiếu quá nhiều thông tin và không nêu rõ vấn đề cần hỏi, nhìn chung là chưa hay. Đặt câu hỏi khi tham gia một cộng đồng không chỉ đơn giản là để giải quyết khó khăn của bản thân, mà từ câu hỏi đó những thành viên khác có thể học hỏi thêm một điều gì đó mới mẻ, có thể giải quyết thêm một vấn đề khó khăn nào đó nên việc đặt một câu hỏi là quan trọng và cần sự đầu tư nghiêm túc. Tôi viết bài này để chia sẻ suy nghĩ và kinh nghiệm của bản thân về việc đặt câu hỏi sao cho hay và có được những câu trả lời hữu ích khi tham gia một cộng đồng.

    ask

    1. Nhận diện một câu hỏi không hay:

    “Anh chị chia sẻ giúp em kinh nghiệm để học test với, em mới vào nghề chưa biết gì cả”.

    Câu hỏi này không hay vì nó quá chung chung, không đề cập đến một vấn đề cụ thể nào. Nếu phải chia sẻ về cái gọi là “kinh nghiệm test” thì không ai có đủ thời gian để gõ ra cũng như chia sẻ tức thì được, và thậm chí có thời gian cũng không thể chia sẻ hết nỗi. Còn thông tin “mới vào nghề” cũng không giúp ích gì cho câu hỏi cả. Nhưng rất buồn vì đây là một trong các câu hỏi chúng tôi hay gặp nhất.

    Một vài câu hỏi không hay khác:
    Hỏi: “Cho mình hỏi những chương trình nào test web thông dụng vậy?”
    Đáp: Làm sao chúng tôi có thể giúp khi không biết bạn cần test web là test những gì trên web (giao diện, chức năng hay tốc độ load)? rồi làm sao chúng tôi biết được bạn đang dùng Windows, MacOS hay Linux? Thật sự chúng tôi cần nhiều thông tin hơn để lọc và đưa ra một gợi ý phù hợp.

    Hỏi: “Bạn nào có mẫu về testcase chia sẻ mình với”
    Đáp: Câu hỏi này đáng lẽ không nên hỏi, bạn có thể tự google hàng trăm mẫu testcase đang chia sẻ và tìm xem cái nào phù hợp. Hay bạn không có thời gian để tìm? hay không biết cái nào là phù hợp? hay bạn mong muốn chúng tôi mang cái đang làm ở cty gởi cho bạn?. Thay vì hỏi bạn nên tự tìm kiếm và tìm hiểu, sau đó làm một bản testcase theo những gì mình biết và gởi chúng tôi góp ý, mọi người sẽ rất vui lòng vì ít ra họ thấy được sự cố gắng của bạn, thậm chí học hỏi thêm được chút ít từ bản testcase chưa hoàn thiện đó.

    Hỏi: “Có bạn nào trong nhóm đang làm về Selenium không?”
    Đáp: Đây là một câu hỏi ư? bạn đang cần gì? bạn tìm họ vì mục đích gì? hay bạn nghĩ rằng có ai đó giỏi selenium sẽ giơ tay lên? Nếu gặp khó khăn gì về một vấn đề nào đó hãy hỏi thẳng, tránh hỏi vòng vo như vậy.

    2. Câu hỏi hay là gì?

    • Là một câu hỏi chứa đầy đủ thông tin và phải cụ thể: Nó bao gồm các thông tin như bạn đang làm gì? Vấn đề bạn gặp phải là gì? Mong muốn của bạn là gì? Thông tin về hệ thống/cấu hình hiện tại như thế nào (nếu hỏi về kỹ thuật). Nếu có thể, hãy cung cấp hình ảnh để người đọc dễ dàng biết được bạn đang gặp vấn đề gì.
    • Trong câu hỏi phải cho mọi người thấy được bạn đã làm những gì để giải quyết vấn đề của mình hay chưa? Bạn đã google để tìm thông tin và thử tự giải quyết hay chưa? Bạn đã đọc tài liệu hướng dẫn chưa? Bạn đã thử nghiệm trước khi hỏi chưa? Nếu chưa thì bạn nên làm những thứ đó trước khi hỏi, đa số các câu trả lời đều có trên google chỉ có điều bạn không chịu tìm trước mà thôi. Vậy tại sao mọi người lại bỏ thời gian để tìm câu trả lời giúp bạn trong khi bạn chưa chịu đầu tư thời gian cho chính mình?
    • Đặt câu hỏi chung một dòng. Hãy viết tất cả trong một dòng, sau khi hoàn chỉnh hãy enter để gởi. Không nên hỏi dạng chat mỗi dòng một ý.
    • Thông báo khi bạn đã tìm được câu trả lời (kèm chi tiết về giải pháp): việc này sẽ giúp mọi người biết câu hỏi bạn đã có giái pháp và không mất thời gian tìm kiếm câu trả lời nữa, ngoài ra thông tin bạn đưa lên sẽ giúp những người khác có câu hỏi tương tự không phải tìm kiếm thêm.
    • Chỉ nêu vấn đề, không phỏng đoán hay đánh giá, điều này sẽ đánh lạc hướng người khác hiểu sai theo bạn. Ví dụ máy bạn bị lỗi abc thì hãy nêu rõ lỗi đó, không nên đoán “tôi nghĩ do máy tôi bị nhiễm virus nên bị lỗi này…”, việc phỏng đoán sai có thể phá hỏng một câu hỏi hay.
    • Không than vãn những câu như: em mới vào nghề, chưa chưa biết gì hết, em mới làm test nên…Những câu than vãn này không giúp ích được gì cho câu trả lời nên bạn không cần ghi vào, điều đó chỉ khiến bạn trông có vẻ đáng thương.
    • Tôn trọng quy tắc cộng đồng:
      • Tham gia nhóm là để trao đổi thông tin và giải quyết vấn đề cùng nhau, rất hạn chế việc pm hỏi riêng một thành viên nào (trừ trường hợp vấn đề đó không thể trao đổi chung).
      • Viết tiếng Việt có dấu rõ ràng, hạn chế các biểu tượng (smile icon) không cần thiết. Nhất là trên Skype vì những icon đó khá lớn và mất tập trung.
      • Lịch sự với cộng động, một câu hỏi bắt đầu bằng lời chào và kết thúc bằng câu cảm ơn luôn nhận được sự chào đón.
      • Hỏi đúng nơi cần hỏi và không lặp lại liên tục. Không spam các thông tin ngoài lề (vd tuyển dụng, báo mạng…).
      • Tìm hiểu về quy định của nhóm bạn đang tham gia, có một vài nhóm có quy tắc là thêm chữ “QA” hoặc “Q/A” trước mỗi câu hỏi, bạn cũng nên tuân theo.

    Một số ví dụ về câu hỏi hay:

    “Chào các bạn, mình đang tìm một tool để giả lập 100 user truy cập cùng lúc vào trang web. Mình đã tìm trên mạng và ra được một vài tools như Jmeter, Gatling, LoadRunner, LoadUI nhưng chưa biết cái nào đáp ứng tốt được các yêu cầu như: chạy trên windows và linux, giá cả phù hợp, có xuất report rõ ràng. Mình cảm ơn.”

    Đáp: (câu hỏi này hay đây, anh ta biết rõ mình muốn làm gì và cũng cung cấp được kha khá thông tin cần thiết. Có vẻ anh ta cũng đã chịu khó tìm hiểu để có được một danh sách ứng dụng cần thiết, chúng ta nên giúp a ấy một tay).
    Anh có thể dùng Jmeter, nó miễn phí, chạy được trên nhiều môi trường và đáp ứng được yêu cầu giả lập 100 user.

    Hỏi: “Hello mọi người, Mình đang tìm hiểu cách viết testcase, mình có tham khảo một số tài liệu và mẫu trên mạng nhưng thấy họ có ghi một mục là “Pre-Conditions”, cho mình hỏi mục đó có công dụng gì và có cần thiết trong testcase hay không? Mình cảm ơn.”

    Đáp: (có vẻ bạn này đã tìm hiểu và tự làm được testcase rồi, nhưng còn một số thông tin chưa rõ, mình nên giải thích thêm chút giúp bạn ấy).
    Chào bạn, mục “Pre-Conditions” gọi là điều kiện tiên quyết, dùng để chứa hoặc ghi các thông tin về môi trường, trạng thái, các bước cần chuẩn bị trước khi thực hiện testcase đó. Ví dụ để thực hiện một case về login thì Pre-conditions là thông tin về username & password của thành viên đó. Mục này là cần thiết nhé.

    3. Tổng kết.
    Một câu hỏi hay không chỉ giúp cho vấn đề được trợ giúp một cách nhanh chóng và chính xác mà còn thể hiện được sự siêng năng, ham học hỏi của tác già. Câu hỏi hay sẽ giúp cho mọi người (kể cả người hỏi, người giúp và cộng đồng) học thêm được điều gì đó mới mẻ.