- vừa được xem lúc

Cách quản lí ticket trên tool (Redmine/Backlog)

0 0 31

Người đăng: Trinh Thi My Duyen

Theo Viblo Asia

Nội dung chính:

  1. Môi trường test

  2. Process khi nhận một task

  3. Format viết Title của một task

  4. Mô tả trong task cần những gì

  5. Target của task

  6. Impact range của task

  7. Độ ưu tiên của task

  8. Khi nào một task là CR

Giới thiệu

Redmine/ Backlog là tool quản lý các ticket, document, tiến độ...của dự án.

1. Môi trường test

Môi trường test của dự án cần phải được xác định đầu tiên khi bắt đầu bắt tay vào làm và cần đặt các câu hỏi:

  • Môi trường test là gì?

  • Xác định hệ thống là Web PC hay Mobile/ Webview Mobile.

  • Nếu hệ thống là Web trên PC cần xác định test trên trình duyệt nào (Chrome/ Firefox), hệ điều hành là gì (Win 10, Win 7, Ubuntu), version là gì?

  • Nếu hệ thống là Mobile cần xác định: Device test là gì (IP, IPad, Samsung..), version yêu cầu là gì?

  • Nếu hệ thống là Webview Mobile cần xác định: Device test là gì (IP, IPad, Samsung..), version yêu cầu là gì? Test trên Safari hay Chrome...

2. Process khi nhận một task

3. Format viết title của một task

Ví dụ: [Front][RE-01][Registration]Đăng ký hội viên của hệ thống

Phân tích:

Khi nhìn vào title của task người đọc dễ dàng hình dung ra nơi task cần làm là ở đâu, tên màn hình của task là gì? Mã màn hình để thuận lợi cho việc quản lý đó là: Trên Front hệ thống người sử dụng, màn hình đăng ký thành viên, đăng ký một vài thông tin cho thành viên trước để có thể sử dụng được hệ thống.

Nhìn vào title này người đọc sẽ không thể nhầm lẫn sang site của Admin được và cũng không thể nhầm lẫn nó là màn hình Profile của member được, và tất nhiên nó không thể là màn hình dạng list được

4. Mô tả trong task cần những gì?

  1. Mô tả ngắn gọn về task

  2. Nếu không có flow di chuyển màn hình thì có thể đặt câu hỏi nhờ khách hàng cung cấp nếu không có thì cần confirm sau khi đăng ký xong thì đi đến đâu?

4.1. Mô tả ngắn gọn về task

Ex: Trong task này: [Registration]Đăng ký hội viên của hệ thống

  • Các trường cần đăng ký cho member là gì?

  • Có file validation: Format, Required, Optional, Min-Maxlength

  • Sau khi đăng ký xong thì có những output gì? Có gửi mail không? Đối tượng hệ thống gửi mail là những ai?...

  • Sau khi đăng ký xong thì member có cần phải thanh toán khoản nào không? Nếu có thanh toán cần làm rõ dùng phương thức nào thanh toán (Stripe/ …)

4.2. Flow di chuyển màn hình

Xác định fow di chuyển màn hình của task.

5. Loại task

Task

Research

CR

6. Status

Open

In-Progress

Resolved

Testing

Re-open

Close

7. Priority

Immediatly

High

Medium

Low

8. Impact Range

What is impact range?

  • Impact range là phạm vi ảnh hưởng, đối tượng xác định bao gồm cả Dev và test. Dev/ Test: Xác định task ảnh hưởng đến chức năng nào ngoài phạm vi task mô tả. Test: Define testcase cho vùng ảnh hưởng liên quan.

Ví dụ: Màn hình đăng ký có chức năng thông tin của member khi đăng ký Country = Japan => State = Select box Impact range: Cần phải test chức năng tương tự trên màn hình Profile.

9. Khi nào một task là CR và cách quản lý CR.

Các mô hình dự án ngày nay hầu như không còn theo mô hình thác nước mà hầu hết là theo "Agile". Vì thế chúng ta luôn luôn chào đón sự thay đổi trong spec. Mặc dù vậy nhưng không có nghĩa là cứ thay đổi là làm. Mọi thay đổi của khách hàng, hơn ai hết chính bản thân chúng ta cần chủ động trao đổi để làm rõ vấn đề, tạo sao lại có sự thay đổi như vậy?

Khi nào một task là CR:

  • Đó là sự thay đổi function logic, UI (Text, thứ tự của từng item trong màn hình)...trong một task đã có.
  • Thêm một item mới vào bên trong màn hình
  • Thay đổi giá trị mặc định với từng loại: Textbox, Textarea, Selectbox, Radio button, Kiểu Boolean...
  • Thay đổi logic trong cách tính toán của bài toán đặc thù trong dự án.

Cách quản lý change request:

Về cách quản lý CR như nào cho hiệu quả để dự án chắc chắn thành công các bạn có thể tham khảo tại đây:

https://viblo.asia/p/6-dieu-rut-ra-khi-lam-viec-o-du-an-lon-bxjvZOBjGJZ

10. Process Close task

Một task có thể close được khi nào?

  • Không có bug làm chết chức năng hiện tại
  • 70% số testcase pass (phụ thuộc vào process của từng dự án)
  • Chỉ còn bug UI nhỏ: Bug về sai text...

Kết luận:

Trên đây là nội dung normal khi thực hiện làm một task. Tùy theo từng dự án mà sẽ có process khác nhau, tôi muốn nói nhưng gì chung và cơ bản nhất để các bạn dễ hình dung.

Bình luận

Bài viết tương tự

- vừa được xem lúc

Các mô hình phát triển phần mềm

1. Định nghĩa. Mô hình phát triển phần mềm hay quy trình phát triển phần mềm xác định các pha/ giai đoạn trong xây dựng phần mềm. Có nhiều loại mô hình phát triển phần mềm khác nhau ví dụ như:.

0 0 94

- vừa được xem lúc

Tìm hiểu về kỹ thuật phân tích giá trị biên và phân vùng tương đương trong kiểm thử hộp đen

Để đảm bảo được chất lượng của một hoặc nhiều dự án phần mềm QA cần phải tạo được bộ testcase phù hợp.Để thực hiện việc kiểm tra phần mềm với thời gian ngắn nhất mà vẫn đạt chất lượng cao nhất cần phải hiểu sâu về nghiệp vụ của phần mềm và linh hoạt trong việc thiết kế testcase.

0 0 224

- vừa được xem lúc

Single Page Application Concept

Bạn đã từng nghe về một trang wed Single page hay chưa? Dạo gần đây Single page application là một cái tên đang nổi trong xu hướng phát triển web. Mặc dù concept này đã ra đời hơn chục năm nay.

0 0 35

- vừa được xem lúc

Top 15 xu thế kiểm thử phần mềm trong năm 2021

. Năm 2021 dự kiến những công nghệ sau sẽ lên ngôi:. . AI (Artificial intelligence) và ML (Machine Learning). Robotics.

0 1 164

- vừa được xem lúc

Xử lý Table, Frame và Dynamic Element của Web trong Selenium Script – Selenium Tutorial #18

Table, Frame và Dynamic Element là các phần thiết yếu không thể thiếu của bất kỳ web project nào. Chúng ta hãy cùng nhau tìm hiểu cách xử lý chúng trong tập lệnh selenium nhé.

0 0 84

- vừa được xem lúc

Exploratory testing - Kiểm thử thăm dò

I. Định nghĩa. 1. Exploratory testing là gì.

0 0 129