Linh hoạt trong kiểm thử
TIL
763
QA
8
PQA
4
White

Thiên Hoàng Minh Vũ viết ngày 08/03/2018

Kiểm thử như dòng nước, uốn lượn và linh hoạt, mọi dòng nước đều khao khát tắm mình trên đất mẹ cũng như mọi phương pháp test đều khao khát đạt tới chất lượng mong đợi . Quy trình như phương pháp trị thủy, tối ưu khả năng điều tiết dòng nước và ngăn không cho dòng nước ấy đi quá đà, làm giảm sự tổn hại một số thứ trên con đường của dòng nước. Khi cần thiết, "phương pháp trị thủy" ấy cũng thay đổi cho phù hợp.

Bài viết chưa hoàn thiện, tạm để TIL để chỉnh sửa thêm...

1. Nhân duyên

Có lẽ tôi cũng chẳng bao giờ nghĩ đến chủ đề này để viết nếu không phải trainning và thẽo dõi toàn bộ quá trình trưởng thành của một em gái từ khi mới bắt đầu vào nghề. Sự thô cứng của em dẫn đến nhiều câu chuyện dở khóc dở cười. Bộ quy trình của tôi cũng vì thế mà ngày càng dày hơn, nhiều quy tắc hơn cho các rủi ro (kể cả các rủi ro lãnh xẹt) và hoàn thiện hơn.

Ngày hôm nay viết bài viết này, xin chúc mừng em đã trở thành 1 SQA trưởng thành hơn, không khù khờ như hồi mới vào nữa, tuy nhiên trên con đường trở thành 1 QA chuyên nghiệp, có lẽ ... em cần phải cố gắng hơn thế nữa rất nhiều.

2. Quyền ưu tiên

'- Khi thời gian có hạn, bạn sẽ làm gì để mang tới chất lượng tốt nhất cho dự án? Bạn không thể mong chờ một chất lượng hoàn hảo, chỉ có thể mong chờ nó tốt nhất trong khả năng.
Kinh nghiệm, tài năng của bạn phải giải quyết được vấn đề đối diện với rủi ro này. Bạn chọn làm cái gì trước, cái nào có thể tạm thời lược bớt hoặc để sau?....

Một dự án luôn tồn tại ít nhất 7 giới hạn có thể khiến bạn phải lựa chọn ưu tiên cái gì:

  1. Cost: Số tiền trả cho bạn luôn có hạn, không phải bạn thích test theo kiểu "móc túi" là được.
  2. Time: Thời gian luôn gò bó, không phải bạn thích test bao lâu cũng được.
  3. Resources: Chỉ có 1 số lượng giới hạn SQA, không ai làm thay công việc như núi của bạn đâu.
  4. Scope/ performance: Phải hoàn thành tất cả công việc đã ước lượng, không phải bạn chỉ test 1 màn hình thì tất cả các màn hình khác đều pass theo.
  5. Quanlity: Công ty chỉ cho phép giới hạn số bug mà KH phát hiện ra sau khi bàn giao, nên đừng nghĩ bạn test qua loa mà yên ổn.
  6. Risk: Công ty quy định không được để xảy ra một cách hạn chế số lượng rủi ro vượt kiểm soát (chưa lường đến), không phải bạn quên lắp não mà có thể test ngon được.
  7. Customer satisfaction: Test đã ngon lại còn phải làm vừa lòng khách hàng, định nghĩa chung chung nhưng nó vẫn tồn tại, không phải làm không có tâm mà có thể mong làm hài lòng người khác.

2. Chiến lược test

Quy trình sinh ra chỉ có thể đảm bảo 1 khuôn phép cố định, chủ yếu cho đa phần một dự án có tình huống tương tự. Trong khi đối với 1 dự án, bao nhiêu tức là bấy nhiêu khác biệt. Đội test có thể linh hoạt theo chiến lược test cho phù hợp với tình hình dự án.

Rõ ràng chiến lược test của một dự án theo scrum và 1 dự án waterfall là khác biệt đáng kể. Đòi hỏi người ứng dụng quy trình một cách linh hoạt, cái nào dùng được, cái nào có thể lược bỏ hay đề xuất thêm vào.

3. Không ép buộc quá đáng vào quy trình, thuận theo tình huống.

Nhiều bạn áp dụng quy trình một cách hết sức máy móc và khuôn khổ. Điều ấy làm gia tăng nặng nề áp lực lên sự nghiệp và cả các mối quan hệ xung quanh.

Kiểm thử như dòng nước, uốn lượn và linh hoạt, mọi dòng nước đều khao khát tắm mình trên đất mẹ cũng như mọi phương pháp test đều khao khát đạt tới chất lượng mong đợi . Quy trình như phương pháp trị thủy, tối ưu khả năng điều tiết dòng nước và ngăn không cho dòng nước ấy đi quá đà, làm giảm sự tổn hại một số thứ trên con đường của dòng nước, khi cần thiết, phương pháp trị thủy cũng thay đổi cho phù hợp.

Quá lạm dụng quy trình vào mọi tình huống và mọi phương pháp test sẽ dẫn đến sự sụp đổ cơ cấu và khiến cho "đất đai" trở nên kém hơn.

4. Nhẹ nhàng là liều thuốc vực bản thân lên đỉnh cao của sự nghiệp

Một QA quyết đoán và làm chủ được mọi tình huống trong chận chiến dành giật chất lượng cho sản phẩm là điều tốt. Nhưng quyết đoán và ba trợn, làm chủ tình huống và đùn đẩy trách nhiệm lại là 2 thứ khác nhau.

Đối với đồng nghiệp trong dự án, chúng ta là hội cùng thuyền, cả dự án đang nước sôi lửa bỏng, kể cả lỗi không phải của chúng ta thì chúng ta cũng chẳng ngồi yên được đâu.

Đối với đồng nghiệp trong công ty, chịu khó lắng tai những gì người khác đã trải qua là cách nhanh nhất để bạn thấy được những rủi ro sẽ xảy ra đối với mình trong tương lai. Bản thân chúng ta, sống có vài chục năm cũng chẳng đủ thời gian để trải nghiệm hết các rủi ro, chỉ có cách học người khác, thu lượm về cho mình mới sớm dày dặn.
Dù cho họ có kém hơn mình, non hơn mình nhưng chắc chắn ở 1 khía cạnh nào đó, vẫn có cái của họ đáng để bạn lưu tâm

Sự nghiệp của bạn không chỉ nằm ở chuyên môn của bạn, đồng nghiệp yêu mến và dành những lời tốt đẹp dành cho bạn. Khi nó đến tai các sếp, mọi thứ như phép màu trong sự nghiệp của bạn vậy. Đúng là ... do ăn ở cả :joy: Đó là trường hợp của một chị công ty mình, cũng là một tờ giấy trắng khi mới vào, thấm nhuần tư tưởng của "người lái đó" này mà giờ đây cũng ... đứng vững giữa đất trời, có khi lương hiện còn cao hơn nhiều người với 4, 5 năm kinh nghiệm rồi ấy chứ =))

5. Thuận theo tình thế

Căn bản của kiểm thử chính là Risk (rủi ro). Có muôn vàn risk ta đánh giá được, nhưng cũng có muôn vàn risk "giời ơi đất hỡi" tự nhiên nó bay đến.

Risk là cơ sở để xác lập việc kiểm thử và trong kiểm thử cũng có risk.

Tùy vào rủi ro, xuôi theo nó và nhanh nhạy xử lý các tình huống, đối mặt với nó. Thực tế, bug không phải vấn đề quá to tát, to tát nằm ở communication. Bug vẫn mãi là bug, còn chúng ta cần phải bảo toàn được cái nhìn của khách hàng dành cho công ty, của sếp dành cho mình.

Khi một risk xảy ra, trước tiên phải:
'- Chưa cần biết là đúng hay sai, trước tiên cứ xin lỗi cái đã, đừng quên xin 1 chút thời gian để kiểm tra lại các evidence của mình
'- Chứng minh trách nhiệm:
'+ Tìm lại toàn bộ bằng chứng kiểm thử của mình (case trong testcase, evidence tương đương, bug đã log, kế hoạch test...)
'+ Kiểm thử được thực hiện bởi con người, vì bởi con người nên không thể tránh khỏi lọt lỗi. Nếu xét thấy trong evidence của mình chưa có, thì nên rút kinh nghiệm sâu sắc về risk đó. Có thể lắm chúng ta sẽ bị mắng vì gây ra lỗi, nhưng cũng nhờ những trường hợp như thế mới có thể hoàn thiện kỹ năng của mình được.
'- Bảo vệ đồng đội:
Chúng ta là những người đã ngồi chung trên một con thuyền, dù chứng minh được trách nhiệm không phải thuộc về mình, thì chúng ta cũng nên bảo vệ và hỗ trợ làm giảm nhẹ trách nhiệm cho đồng nghiệp. Vào một thời điểm nào đó trong cuộc đời, khi chúng ta chẳng may sa lầy, chính họ lại là người giúp ngược lại bạn đấy!

'- Đề xuất hành động khắc phục:
'+ Hãy thể hiện là một người có trách nhiệm trước rủi ro của dự án, bạn có thể đề xuất những giải pháp để phòng chống rủi ro quay lại lần 2. Khách hàng thường có xu hướng bỏ qua cho lần thứ nhất bị lọt lỗi những sẽ rất khó chịu nếu lỗi đó xảy ra đến lần thứ 2. Xin dẫn lại một câu nói triết lý
"Không ai tắm 2 lần trên một dòng sông"
Dù không có ý nghĩa tương đồng nhưng trong nghề IT người ta hiểu là : Chẳng ai lại để risk xảy ra đến lần thứ 2 cả", nếu ông nào gây ra như thế quả là rất khó chấp nhận =))

Cho nên đề ra một chiến lược ngăn ngừa ngay lập tức nếu risk xảy ra ngay trong lần đầu sẽ là cách tốt nhất để dự án của bạn không rơi vào tình huống khách hàng dọa cắt hợp đồng.

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Thiên Hoàng Minh Vũ

26 bài viết.
74 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
45 3
(Ảnh) Người dẫn lại bài này cũng được phen lao đao khi lục lọi lại mớ kiến thức cơ bản cũ. Đối với sự nghiệp của một coder thì phải được thực hiện...
Thiên Hoàng Minh Vũ viết hơn 2 năm trước
45 3
White
15 0
Xưa, giang hồ đồn đại rằng: "Tin học và ngoại ngữ, trong thiên hạ ai nắm được 1 trong 2 thì có thể có được thiên hạ" :v Ấy mà nay, tiểu mỗ đang có ...
Thiên Hoàng Minh Vũ viết gần 3 năm trước
15 0
White
15 0
Nhắc đến công cuộc bảo vệ chất lượng phần mềm, tôi lại nhớ đến các bài viết về đất Nhật cũng như những chia sẻ của các đồng nghiệp đang sống và làm...
Thiên Hoàng Minh Vũ viết gần 3 năm trước
15 0
Bài viết liên quan
White
6 0
1. Định nghĩa Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào...
Thiên Hoàng Minh Vũ viết hơn 2 năm trước
6 0
White
5 0
Khẩu quyết của PQA: Bằng chứng Bằng chứng Bằng chứng và Bằng chứng :joy: Bằng chứng để bảo vệ công ty mình làm. bảo vệ chính bản thân vì mình khôn...
Thiên Hoàng Minh Vũ viết gần 3 năm trước
5 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
26 bài viết.
74 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!