[rtSupporter]::Thông tin chung dành cho Tester

A. THÔNG TIN CHUNG

1. Dành cho Tester

1.1 Mô tả công việc của Tester

Sơ lược về E-form:

  • Là bảng hỏi điện tử dùng để thu thập dữ liệu.
  • Sử dụng Excel để tạo ra một bảng hỏi Excel (xlsform)↠ sử dụng công cụ chuyển đổi bảng hỏi này thành một e-form.
  • E-form cần được thiết kế chặt chẽ về logic để kiểm soát và loại trừ các lỗi trong quá trình điền câu trả lời của đáp viên.

Nhiệm vụ:

  • Tester có nhiệm vụ kiểm tra và phát hiện tất cả các lỗi sai trong e-form, bao gồm các lỗi sai liên quan đến nội dung (câu hỏi, phương án lựa chọn, gợi ý trả lời), logic, bước nhảy, điều kiện ràng buộc, tính bắt buộc….

Phương pháp thực hiện:

  • Tester sử dụng bảng hỏi giấy (bảng hỏi chính thức được thiết kế theo phương pháp truyền thống) làm chuẩn từ đó kiểm tra nội dung e-form đã khớp bảng hỏi giấy hay chưa.
  • Để phát hiện ra lỗi sai, Tester cần đọc kỹ tất cả các nội dung hiển thị trên e-form từ câu hỏi, phương án lựa chọn, đến gợi ý,… và đối chiếu với bảng hỏi giấy.
  • Tester có thể giả định mình là người thiếu cẩn thận và nhập vào những giá trị không phù hợp, nếu e-form chấp nhận và cho qua tức là e-form bị mắc lỗi sai.
  • Cần dựa vào thông tin trong bảng hỏi giấy, tự đặt ra các kịch bản/tình huống khác nhau điền vào form. Nhấp nút sang trang và quan sát kết quả hiện lên bao gồm các lỗi về bước nhảy, cảnh báo, trùng lặp câu hỏi…) đánh giá tiến trình trên form đã đúng logic và chặt chẽ, kín kẽ hay chưa.

1.2 Kiến thức cơ bản về test form mà Tester cần phải nắm

1.2.1 Phân loại lỗi sai cơ bản (chủ yếu ở các bảng hỏi khảo sát) E-form có thể gặp các loại lỗi sai như sau:

1.2.1.1 Nội dung bảng hỏi

1.2.1.1a. Thiếu/sai nội dung câu hỏi/ phương án lựa chọn

Xem chi tiết tại đây.

So với bảng hỏi giấy, e-form thiếu/sai nội dung như thiếu câu chữ trong câu hỏi hoặc trong phương án lựa chọn.
Gợi ý:
– Đọc kỹ và đối chiếu từng câu chữ trong bảng hỏi giấy và e-form.
– Đếm số lượng phương án.
image

1.2.1.1b. Thiếu/ sai gợi ý/ hướng dẫn:

Xem chi tiết tại đây.

E-form thiếu/sai các gợi ý/ hướng dẫn cách trả lời câu hỏi.

Lưu ý: Nếu gợi ý/hướng dẫn đã được thể hiện qua cấu trúc của e-form thì không cần phần văn bản hướng dẫn nữa.

Gợi ý:

– Đọc kỹ và đối chiếu từng câu chữ trong bảng hỏi giấy và e-form.
image

1.2.1.1c. Thiếu/ sai gợi ý/ hướng dẫn:

Xem chi tiết tại đây.

E-form thiếu câu hỏi so với bảng hỏi giấy

Gợi ý:

Theo dõi số thứ tự câu hỏi hoặc đếm số câu hỏi trong bảng hỏi giấy và e-form

image

1.2.1.1c. Thừa câu hỏi:

Xem chi tiết tại đây.

E-form chứa câu hỏi không tồn tại trong bảng hỏi giấy.

Gợi ý:

Theo dõi số thứ tự câu hỏi hoặc đếm số câu hỏi trong bảng hỏi giấy và e-form.

image

1.2.1.1e. Sai trình tự câu hỏi:

Xem chi tiết tại đây.

E-form sắp xếp trình tự câu hỏi không giống trình tự bảng hỏi giấy.

Gợi ý:

Theo dõi số thứ tự xuất hiện các câu hỏi.

image

1.2.1.1f. Thiếu dòng cụ thể để ghi đáp án khác:

Xem chi tiết tại đây.

Nếu trong bảng hỏi giấy, có phương án lựa chọn là “Khác, ghi rõ:…” thì trong e-form cần thêm một dòng để ghi nội dung “ghi rõ” này, khi chọn phương án “khác”. Nếu e-form không xuất hiện dòng “ghi rõ” để đáp viên trả lời thông tin chi tiết cho nội dung “khác” tức là e-form mắc lỗi.

Gợi ý:

Chọn phương án “Khác” để xem có xuất xem có xuất hiện thêm dòng “ghi rõ:…” hay không. Vì thông thường e-form được thiết kế ẩn dòng này, nó chỉ xuất hiện khi chọn phương án “khác”.

image

1.2.1.2 Bước nhảy sai hoặc thiếu bước nhảy

Xem chi tiết tại đây.

Bước nhảy là tình huống mà tùy theo phương án được lựa chọn, đáp viên sẽ bỏ qua (một số) câu hỏi kế tiếp và chuyển đến câu hỏi khác, hoặc tùy thuộc phương án được lựa chọn, hoặc câu trả lời mà phần tiếp theo sẽ chuyển đến các nhóm câu hỏi khác nhau.

Sau khi chọn phương án của câu hỏi có bước nhảy, e-form cần chuyển (nhảy) đến đúng các câu hỏi theo thiết kế trong bảng hỏi giấy. Nếu e-form thiếu bước nhảy hoặc nhảy sai câu hỏi tức là e-form mắc lỗi sai bước nhảy.

Gợi ý:

Chú ý ký hiệu mũi tên trong bảng hỏi giấy để biết rằng chọn phương án đó thì tiếp theo sẽ chuyển đến câu hỏi nào, thực hiện trên e-form và đối chiếu.Trong một số trường hợp trên e-form cần chuyển sang trang tiếp theo để theo dõi bước nhảy.
image
image

1.2.1.3 Ràng buộc

1.2.1.3a. Thiếu ràng buộc chặt

Xem chi tiết tại đây.

Ràng buộc chặt là điều kiện (các ngưỡng giá trị) áp dụng đối với câu trả lời, nếu câu trả lời không thỏa mãn điều kiện ràng buộc sẽ không được chấp nhận. E-form cần đưa ra thông báo và chỉ chuyển sang phần tiếp theo khi đáp viên đưa ra câu trả lời thỏa mãn điều kiện.

Nếu trong bảng hỏi giấy có đưa ra điều kiện ràng buộc chặt đối với đáp án mà trong e-form không xuất hiện thông báo và cho tiếp tục trả lời phần tiếp theo như không có điều kiện ràng buộc, tức là e-form thiếu ràng buộc chặt.

Gợi ý:

Nhập giá trị nằm ngoài các ngưỡng cho phép, điền đủ các câu trả lời trong màn hình hiện có và (gạt màn hình sang trái) chuyển sang trang tiếp theo.

Nếu e-form thiết kế chuẩn thì sẽ xuất hiện cảnh báo, bạn phải sửa lại đáp án cho đúng khoảng cho phép mới sang phần tiếp theo được. Nên thử nhiều giá trị khác nhau, từ điểm gần ngưỡng đến giá trị xa ngưỡng.
image

1.2.1.3b. Tạo thừa/ sai ràng buột chặt:

Xem chi tiết tại đây.

Trong bảng hỏi giấy không có giới hạn phạm vi giá trị đối với đáp án, nhưng khi điền thông tin vào e-form thấy có thông báo và/hoặc khống chế giá trị được phép nhập vào, tức là e-form thừa ràng buộc chặt.

Trong bảng hỏi giấy có giới hạn phạm vi giá trị đối với câu trả lời nhưng các ngưỡng giá trị cho phép nhập trong e-form không khớp với ngưỡng trong bảng hỏi giấy, tức là e-form tạo sai ràng buộc chặt.

Gợi ý:

_ Thử nhiều ngưỡng giá trị lớn nhỏ khác nhau (đặc biệt là các giá trị rất lớn) để xem có xuất hiện cảnh báo hay không.

_ E-form xuất hiện thông báo (màu vàng) trong khi bảng hỏi giấy không có điều kiện ràng buộc chặt tức là e-form thừa ràng buộc chặt.

_ Thử các giá trị gần ngưỡng giá trị trong bảng hỏi giấy để xem có xuất hiện thông báo (màu vàng) đúng như kỳ vọng hay không.
image
image

1.2.1.3c. Thiếu/ tạo sai ràng buộc mềm/ cảnh báo:

Xem chi tiết tại đây.

Cảnh báo được coi là ràng buộc mềm. Trong bảng hỏi giấy sẽ quy định ngưỡng giá trị đưa ra cảnh báo, theo đó e-form hiển thị lời cảnh báo nếu câu trả lời vượt ngưỡng quy định. E-form có thể bị thiếu các cảnh báo này, hoặc đưa ra cảnh báo không khớp với ngưỡng quy định trong bảng hỏi giấy.
Gợi ý:
Thử nhiều ngưỡng giá trị lớn nhỏ khác nhau (đặc biệt các giá trị gần ngưỡng và những giá trị rất lớn) để xem có xuất hiện thông báo (màu vàng) hay không.

image

1.2.1.3d. Thiếu ràng buột ngầm:

Xem chi tiết tại đây.

Các câu trả lời cần thỏa mãn logic thông thường (ngầm hiểu), do đó không xuất hiện quy định hay giới hạn giá trị trên bảng hỏi giấy nhưng một e-form tốt cần có ràng buộc (chặt hoặc mềm) để giảm thiểu những lỗi sai logic này. Tester cần sử dụng tư duy logic của mình để phát hiện ra loại lỗi này.

Gợi ý:

Giả sử câu hỏi đó hỏi về năm sinh của đáp viên, thì không thể nào là năm hiện tại phỏng vấn họ.

1.2.1.4 Lỗi sai khác

1.2.1.4a. Tính bắt buộc:

Xem chi tiết tại đây.

Hầu hết các câu hỏi trong bảng hỏi đều mang tính bắt buộc, ngoại trừ những câu dành riêng cho đối tượng cụ thể, thông thường sẽ được lưu ý ngay trong phần câu hỏi. Lỗi thiếu tính bắt buộc của e-form là cho tiếp tục/kết thúc phỏng vấn khi đáp viên chưa hoàn thành các câu hỏi mang tính bắt buộc.

Gợi ý:

Khi kiểm tra một màn hình mới trong e-form, bạn hãy dùng tay vuốt màn hình sang phải, để chuyển tiếp sang màn hình tiếp theo, e-form sẽ lập tức có thông báo yêu cầu bạn nhập thông tin. Với những câu hỏi không có thông báo, bạn hãy kiểm tra lại phiếu giấy xem có lưu ý là không bắt buộc trả lời hay không. Nếu bảng hỏi giấy không có lưu ý về tính không bắt buộc (nghĩa là bắt buộc) mà e-form không có cảnh báo tức là e-form bị mắc lỗi về tính bắt buộc.

1.2.1.4b. Loc sai dữ liệu:

Xem chi tiết tại đây.

Theo điều kiện cho sẵn, e-form cần lọc ra danh sách đối tượng đáp ứng các yêu cầu được đưa ra trong bảng hỏi giấy. Tuy vậy e-form có thể có sai sót dẫn đến thông tin lọc ra không đáp ứng yêu cầu, bị thiếu hoặc thừa đối tượng.

Gợi ý:

Tự xác định danh sách đối tượng sẽ được lọc ra và đối chiếu với danh sách do e-form lọc ra. Ví dụ: Bảng hỏi giấy có phần hỏi riêng các thành viên trong hộ gia đình là nam & trên 20 tuổi. Do đó e-form cần lọc ra danh sách các đối tượng thỏa mãn các điều kiện này. Để biết e-form có khả năng thực hiện đúng hay không, tester cần: - Nhập thông tin hộ gia đình bao gồm nhiều thành viên trong đó có các đặc tính: nam & dưới 20, nam & trên 20 và nữ & dưới 20 và nữ & trên 20 tuổi. Nếu e-form lọc ra danh sách chỉ bao gồm các thành viên có đặc tính: nam & trên 20 tuổi nghĩa là e-form đã lọc đúng danh sách.

1.2.1.4c. Sai loại câu hỏi:

Tùy theo từng câu hỏi mà câu trả lời có thể ở các dạng khác nhau: dạng văn bản, số nguyên, số thập phân hoặc lựa chọn 1 phương án, nhiều phương án. Trong bảng hỏi giấy sẽ quy định một câu cụ thể là lựa chọn 1 phương án hay nhiều phương án nên Tester dễ dàng phát hiện nếu e-form thiết kế sai loại câu hỏi.

Các câu hỏi mở trong bảng hỏi giấy sẽ không chỉ ra câu trả lời phải ở dạng văn bản, số nguyên hay số thập phân nhưng e-form cần được định dạng đúng. Tester cần sử dụng kiến thức thực tế để xác định định dạng phù hợp

Gợi ý:

_ Số thành viên trong hộ phải là số nguyên dương. Số điện thoại di động là số nguyên có 10 hoặc 11 chữ số. Khoảng cách, số tiền là số thập phân,…Thì e -form phải hiện thị là bàn phím số

_ Các câu trả lời có thể bao gồm cả chữ và số thì định dạng của chúng phải là văn bản

_ Câu hỏi chỉ cho chọn 1 đáp án nhưng e-form lại cho nhiều đáp án → định dạng sai dữ liệu.

1.2.2 Một số thao tác lỗi sai khác

Xem chi tiết tại đây.
  • Khi muốn lướt sang trang kế tiếp hoặc lướt về trang trước, điều tra viên cần sử dụng 2 ngón tay (để tránh ảnh hưởng đến đáp án đã chọn).

  • Tester cần kiểm tra hiển thị Font chữ, nội dung bảng hỏi được thiết kế có dễ nhìn hay không. Có dễ dàng lựa chọn/chỉnh sửa đáp án hay không.

  • Khi nhập dữ liệu quá nhiều vào hệ thống, tester lưu ý app hoạt động có vấn đề gì so với lúc ban đầu.

  • Vì bảng hỏi khá dài nên lướt trang sẽ gây khó khăn khi điều tra viên cần xem/chỉnh đáp án ở các trang cách xa nhau. Trong trường hợp đó bạn nhấp chọn biểu tượng TOC (Table Of Content - Mục lục) để đi đến đáp án cần xem/chỉnh sửa. Lúc này Tester cần lưu ý dữ liệu đã nhập như thế nào? Có còn đầy đủ hay sai thông tin đã nhập không?
    image

  • Cần chú ý đến wordings trong e-form.

  • Ở bộ form này chứa nhiều câu hỏi có đáp án sẽ nhảy qua các câu hỏi khác nhau và chứa nhiều các ràng buộc chặt ở nhiều câu hỏi.

  • Vì chứa nhiều bước nhảy trong từng đáp án nên tester cần lưu ý đến câu được nhảy sang có liên quan hay không liên quan (tùy trường hợp) đến câu hỏi/đáp án trước đó hay không. Đòi hỏi tester cần test kỹ với từng đáp án khác nhau ở mỗi câu hỏi.

  • Trong điều kiện internet kém thì app có hoạt động tốt không. Có điền form được không.

  • Các bạn tesster cũng cần lưu ý về instance name trong mục edit đã được lưu đúng theo qui tắc hay không (Mã dự án-Mã form-Mã hộ/làng/người trả lời ,… - Mã enum hoặc tên đăng nhập - Thời gian mở phiếu).

1.3: Các thuật ngữ thường dùng trong công việc

1.3.1Thuật ngữ về quản trị nhân sự của công ty

Xem chi tiết tại đây.
  • Check-in: sử dụng form để check-in, bằng việc quét QR code, đợi 5s để hoàn thành xong việc check-in

  • Check-out: sử dụng form để check-out, bằng việc quét QR code, đợi 5s để hoàn thành xong việc check-out

  • Check-in ad hoc: điền form này khi bạn có việc đột xuất và đến văn phòng muộn nhưng được sup cho phép

  • Check-out adhoc: điền form này khi bạn có việc đột xuất và rời khỏi văn phòng sớm

  • Daily briefing: cuộc họp mỗi sáng ở phòng họp change, bắt đầu từ 8h30

  • Daily planning : lập kế hoạch công việc cần làm trong ngày hoặc ngày kế tiếp

  • Daily report: điền biểu mẫu (form) để báo cáo tiến độ và mức độ hoàn thành công việc hàng ngày

  • Apply leave: điền biểu mẫu xin nghỉ phép (khi xin nghỉ phép bạn cần điền biểu mẫu và thông báo thêm cho Supervisor của bạn)

  • Approve leave: Supervisor điền biểu mẫu để duyệt đơn xin nghỉ phép của nhân viên

  • Notification (viết tắt là notif): mục quả chuông trong app. Các thông báo: Check-in/out, Daily Planning/ Daily Report thì chỉ có người nộp biểu mẫu đó nhận đưược. Còn Đối với các Notif: Check-in adhoc, check-out adhoc, check in late, check out early, apply leave, approve leave,…thì tất cả mọi người trong công ty đều nhậận được.

  • Part- time schedule: đăng kí lịch làm việc trong tuần dành cho Tester. Tester báo kế hoạch làm việc trong tuần cho giám sát bằng việc mở form Part-time schedule (trong module HR).

  • Task: là tên công việc mà bạn sẽ phải làm trong ngày.

  • rtSolutions Team: rtSolutions Team là đội ngũ chịu trách nhiệm phát triển các giải pháp phục vụ quản lý doanh nghiệp/tổ chức, nghiên cứu thị trường và các dự án phục vụ phát triển cộng đồng.

  • rtSupporter:

– Kiểm định hệ thống và phần mềm: cần kiên nhẫn và có độ nhạy bén để thực hiện việc test các bảng hỏi điện tử, các chức năng của app hay hệ thống nhằm đưa ra sản phẩm tốt nhất đến khách hàng.

– Xây dựng tài liệu hướng dẫn cho khách hàng và nội bộ: cần tư duy tổ chức tốt và hệ thống để tạo ra các bộ tài liệu trực quan sinh động và dễ hiểu về cách thức sử dụng app và hệ thống cho khách hàng và các thành viên trong công ty.

– Hỗ trợ khách hàng: cần tự chịu trách nhiệm, thái độ vui vẻ hòa nhã và một tinh thần tích cực khi trả lời thắc mắc của khách hàng, khi hướng dẫn khách hàng sử dụng app hay khi cần xử lý khiếu nại.

– Thực hiện/ hỗ trợ các cuộc điều tra xã hội học và khảo sát thị trường.

– Giám sát và quản lý Tester.

  • rtDeveloper: Thiết kế e-form để thu thập dữ liệu: cần tư duy logic và phản biện để biến các bảng hỏi giấy thành bảng hỏi điện tử nhằm khai thác triệt để các lợi thế công nghệ của smartphone / tablet / Internet.

  • rtAnalytics: Viết báo cáo phân tích: sử dụng kỹ năng viết lách và phần mềm phân tích dữ liệu như R, Stata để cung cấp các bản báo cáo, phân tích nhằm phục vụ mục đích vận hành / giám sát / quản trị doanh nghiệp hay tổ chức.

  • Dev form/ Dev rtSolutions:

  • rtLab:

1.3.2 Thuật ngữ được sử dụng trong công việc

Xem chi tiết tại đây.
  • App version: là các phinê bản của app rtWork, rtSurvey, rtHome

  • Form: là những biểu mẫu để điền thông tin vào, dữ liệu sau khi điền xong sẽ được gửi trực tiếp ngay lập tức

  • Device: thiết bị dùng để test form: có thể là điện thoại Xiaomi, Infinix, iphone 6, máy tính bảng Samsung,…

  • OS: xem thông tin phiên bản của hệ điều hành Android hoặc iOS.

  • Bug/issue: là những bất thường về app, site. Có thể về giao diện hoặc về tính năng.

  • Module:

  • Sub-module:

  • Component:

  • Task: là tên công việc mà bạn sẽ phải làm trong ngày.

  • Data Module viết tắt/ gọi tắt là DM - nghĩa là cơ sở dữ liệu, nơi lưu trữ dữ liệu có thể được nhập lên thông qua các biểu mẫu hoặc dữ liệu có sẵn trên hệ thống.

  • Stuck: Nghĩa là bị nghẽn lại, không thế tiếp tục làm các bước, các việc tiếp theo nữa, mất quá nhiều thời gian để xử lý. Trong quá trình thực hiện task, có thể bạn sẽ gặp trường hợp bạn gặp khó khăn hoặc không hiểu rõ task bạn đang làm cho nên bạn loay hoay, mất nhiều thời gian để xử lý ( 10 - 15 phút), khi đó bạn cần báo ngay cho người giám sát của bạn để báo tình hình bạn đang gặp phải, khi đó giám sát sẽ hỗ trợ bạn tìm ra cách giải quyết vấn đề bạn đang gặp, tránh làm mất thời gian (take time).

  • Hold: Khi bạn đang thực hiện một task nào đó nhưng bạn được phân công thực hiện một task khác gấp hơn. Lúc đó bạn sẽ hold (tạm dừng) task bạn đang thực hiện để thực hiện task giám sát vừa yêu cầu. Bạn hãy hỏi thêm thời gian bạn có thể tiếp tục task bạn đang làm dang dở.

1.4: Thông tin cơ bản về app rtWork

Xem nội dung chi tiết ở link sau:

Hướng dẫn cài đặt và sử dụng rtWork cơ bản:


Thao tác cơ bản cần phải nắm khi thực hiện trên app rtWork: https://rthelp.rta.vn/t/faq-m-t-s-l-u-y-khi-s-d-ng-rtwork/321

1.5 Thông tin cơ bản về app rtSurvey

1.5.1 Hướng dẫn cài đặt và sử dụng rtSurvey cơ bản:
Thao tác cài đặt app rtSurvey tương tự như cách cài đặt rtWork

1.5.2 Thao tác cơ bản cần phải nắm khi thực hiện trên app rtSurvey
Xem thêm link sau, mục 2. Hướng dẫn sử dụng ứng dụng rtSurvey:

1.6 Các hướng test form cơ bản dành cho Tester

  • Test theo hướng phát hiện Bug liên quan đến app: chẳng hạn như Crash app (app thoát đột ngột khi bạn điền form),

  • Test theo hướng phát hiện Bug liên quan đến giao diện app trong quá trình điền form (lỗi format, lỗi về dữ liệu, tính toán của app,…)

  • Test về form: bao gồm test theo flow - tức là đường đi của dữ liệu trong các form. Ví dụ: Chỉ mở được form B sau khi điền và nộp dữ liệu form A. Như vậy bắt buộc người dùng phải điền đủ dữ liệu của form A thì mới có thể mở tiếp Form B. Test theo Mockup (bản phác thảo của form) để kiểm định xem form có được thiết kế giống như trong Mockup phác thảo
    Wording của form: tìm ra sự khác nhau giữa bảng hỏi điện tử E-form và bảng hỏi giấy (cho dự án khảo sát sử dụng app rtSurvey), sự khác nhau giữa Mockup (bản phác thảo form) và E-form.

  • Test Stress app: khi đó Tester giả định là một người dùng bất cẩn trong việc sử dụng app (thực hiện các thao tác: đóng/ mở app, đóng/mở form nhiều lần), điền nhiều biểu mẫu và nộp lên

1.7: Cách mô tả bug/issue khi test Form

Trong quá trình test form, bạn cần tương tác trao đổi qua room test, thường các room này sẽ có rtDeveloper (gọi tắt là Dev hoặc SolDev - người làm ra form chạy trên thiết bị điện thoại, máy tính bảng), Supervisor, Leader và một số Supporter có liên quan. Bạn cần trao đổi lên room các vấn đề bạn thắc mắc hoặc những issue trong lúc bạn test form để làm cơ sở cho việc điều chỉnh form và cải thiện app ngày càng hoàn thiện hơn. Các hình thức mô tả bug/issue như sau:

  • Đối với các vấn đề bạn thắc mắc về nội dung form, về đường đi của dữ liệu,…bạn cần trao đổi trực tiếp lên room chat để được giải thích/ thảo luận để chỉnh sửa cho phù hợp hơn với thực tế người dùng.
  • Đối với các issue liên quan đến bug/ app: bạn trao đổi ngắn gọn lên room chat và điền thông tin mô tả trong link Detect Issue (mô tả thông tin issue/bug để Supervisor kiểm tra xem có phải là issue/ bug hay không trước khi chuyển giao cho bên rtLab) hoặc Google sheet để note issue (tùy thuộc vào từng dự án sẽ có hình thức note issue cụ thể)

Link điền Detect Issue:
Room Detect Issue: image Mục đích của room này dùng để thông báo các issue mà nhân viên RTA nộp lên (gồm cả nhân viên Official/ Partime/ Schedule). Khi bạn phát hiện ra điểm bất thường/ nghi ngờ bug app/ issue bạn sẽ điền vào đường link này để thông báo: https://rta.rtcpms.com/cpms/cpmsSurveyData/AddForm?id=md5%3A34ee19a48986acd2e4cdf8b04bdd34b9

Ngay sau khi bạn điền đủ thông tin của Issue/ bug trong link này và bấm nút GỬI thì thông tin về issue/ bug mà bạn vừa điền sẽ hiển thị trong room Detect Issue.

Lưu ý:

Tester cần ghi lại thông tin Issue detected và Instance: uuid: để theo dõi. Sau khi điền đầy đủ thông tin Detect Issue, bạn chỉ nên bấm nút GỬI 1 lần duy nhất và kiểm tra xem room Detect Issue đã hiển thị hay chưa. (Nếu bạn chưa tham gia room thông báo này, hãy nhờ Supervisor của bạn mời vào). Tuyệt đối KHÔNG bấm nút GỬI nhiều lần.
  • Thông tin Issue Detected và Instance: uuid như sau:

image

Link take note issue/bug dạng google sheet: Tùy vào dự án sẽ có đường link google sheet để note issue khác nhau. Thường link này sẽ được gắn trên đầu room test.

Xem hình minh họa room test bộ form Recruit, đường link để note issue sẽ được gắn ở đầu room:image

  • Giải thích template các mục khi post issue/ bug …Khi báo issue/ bug bạn cần phải cung cấp thêm các thông tin sau.

  • Issue type: App /Form/……=> Issue về app hay về form

  • App name: rtWork /rtSurvey/rtHome => tên app bạn đang test có issue

  • App version: => Phiên bản app. Ví dụ rtWork 1.103.1

  • OS: Android/iOS => Phiên bản Android hay iOS. Ví dụ: Android 8.0

  • Device: Samsung/Nexus/Oppo/iPhone….Tên của thiết bị

  • Site: VD: rta.rtcpms.com (c026), rtstdev01.rtworkspace.com (c151), training.rtworkspace.com (c146), ……=> project code và link site của dự án bạn đang test

  • User: VD: rta_sol01

  • Form family: => Bạn hãy nhờ Supervisor của bạn cung cấp

  • Form title: => Bạn có thể mở form lên và xem tên form

  • Issue: VD: Error sent to server => cần phải mô tả ngắn gọn và khái quát, tránh mô tả chi tiết issue

  • Pre-condition: => Điều kiện để có thể mở form đang có Issue. Ví dụ: Đối với Module HR FOR EVERYONE, bạn gặp issue ở form check-out thì khi đó bạn phải điền Pre-condition là: phải điền form check-in trước.

  • Step by step implementation: => mô tả trình tự các bước

  • Step 1

  • Step 2:

  • Actual results: => Kết quả xảy ra không mong đợi khi bạn thực hiện các bước trong form/app

  • Expect result: => Kết quả mong muốn của form/app

  • Crash report (if any):

  • Screenshot / Video: => Đính kèm ảnh chụp màn hình/ video

  • xlsform: => Bạn liên hệ Supervisor nhờ cung cấp

1.8: Nội quy của công ty

1.8.1 Nội quy chung của công ty:

  • Sử dụng form Check-in/Out khi đến văn phòng và khi kết thúc ca làm việc.

  • Giờ làm việc của công ty: sáng từ 8h15 - 12h, chiều từ 13h30 - 17h30 (Bạn check-in lúc 8h16 được xem như đi muộn).

  • Thời gian làm việc của công ty từ thứ 2 - thứ 6 ( thứ 7, chủ nhật chỉ làm khi có dự án gấp cần phải hoàn thành cho kịp/ đúng tiến độ)

  • Bạn cần phải điền form Daily Planning (lập kế hoạch làm việc cho 1 ngày/ buổi) và điền form Daily Report để báo cáo tiến độ thực hiện công việc.

  • Các team sẽ bắt đầu họp đầu ngày (Daily Briefing) từ 8h30 - 8h50.

  • Vào cuối mỗi tuần, bạn phải điền form đăng kí lịch làm việc trong tuần để giám sát sắp xếp công việc

  • Xin nghỉ phép: Nếu có việc đột xuất (nghỉ 1 buổi/ 1 ngày) bạn cần phải báo với giám sát của bạn. Nếu bạn nghỉ >=1 tuần thì bạn phải gửi email/ nhắn tin/ gọi điện thông báo cho giám sát của bạn trước 2 tuần để giám sát và Leader chủ động phân công công việc.

Lưu ý: Điền các form trong module Quản trị giao việc và module HR For Everyone phải bằng tiếng anh. TUYỆT ĐỐI KHÔNG ĐƯỢC ĐIỀN THÔNG TIN TRONG FORM BẰNG TIẾNG VIỆT.

Mục đích của module HR FOR EVERYONE: bao gồm các nghiệp vụ liên quan đến quản lý nhân sự như: chấm công (check-in, check-out, check-in ngoại lệ, check-out ngoại lệ,…), xin nghỉ phép, xem kết quả duyệt nghỉ phép, kế hoạch làm việc theo tuần của thực tập sinh (Intern) và cộng tác viên (Part-time)

  • Check-in/out: sử dụng form check-in/out khi đến văn phòng làm việc và khi kết thúc ca làm việc. Bạn mở form và sau đó quét QR code. Trong trường hợp bạn quên check-out khi kết thúc ca làm việc, sáng hôm sau bạn không Check-in được thì bạn vào Module HR FOR EVERYONE -> Fix -> Chỉnh quên Check-out và sau đó tiến hành Mở Form Check-in.

  • Đăng kí lịch làm việc
    - Intern schedule: kế hoạch thời gian làm việc trong tuần của thực tập sinh (Intern).
    - Part-time schedule: kế hoạch thời gian làm việc của cộng tác viên (part-time).

image

Bạn lựa chọn các ca làm việc, bao gồm:

  • Off (nghỉ cả ngày)
  • Specific time (thời gian bạn làm việc)
  • Ca sáng tại văn phòng
  • Ca chiều tại văn phòng
  • Full-day (làm cả ngày)

image


Mục đích của module QUẢN TRỊ GIAO VIỆC: bao gồm các nghiệp vụ liên quan đến bàn, giao nhận công việc, báo cáo tiến độ công việc.

  • DAILY PLANNING: Bạn điền form lập kế hoạch làm việc trong ngày để giám sát nắm kế hoạch làm việc hoặc chuyển bạn sang công việc (task) khác.
    Cách điền: Module QUẢN TRỊ GIAO VIỆC -> 2. Daily -> Daily Planning -> Điền thông tin trong form và bấm nộp
  • DAILY REPORT: Ngay sau khi kết thúc ca làm việc, bạn cần điền form này để giám sát nắm được tiến độ thực hiện công việc của bạn.
    Cách điền: Module QUẢN TRỊ GIAO VIỆC -> 2. Daily -> Daily Report -> Điền thông tin trong form và bấm nộp

1.8.2 Nội quy đặc thù của rtSolutions Team:


Xem thêm các bài viết có liên quan về Module HR FOR EVERYONE và Module QUẢN TRỊ GIAO VIỆC

1 Like