Các nội dung sẽ có trong đề thi

1. Nhớ lại rằng sự thành công của thử nghiệm bị ảnh hưởng bởi các yếu tố tâm lý:
(K1)
• Mục tiêu rõ ràng;
• Sự cân bằng giữa tự kiểm thử và kiểm thử độc lập;
• Ghi nhận giao tiếp lịch sự và phản hồi về lỗi.
2. Đối lập suy nghĩ của một tester và của một nhà phát triển. (K2)

Trong phần này, chúng ta sẽ thảo luận về các yếu tố tâm lý khác nhau ảnh hưởng đến
việc kiểm thử và sự thành công của nó. Bao gồm các mục tiêu rõ ràng để kiểm thử,
các vai trò thích hợp, sự cân bằng của việc tự kiểm thử và kiểm thử độc lập, giao tiếp
và phản hồi rõ ràng, lịch sự và phản hồi về lỗi. Đối chiếu suy nghĩ của một tester và
của một nhà phát triển.

Thuật ngữ trong phần này, independent testing (kiểm thử độc lập)
và independent (tính độc lập).

KIỂM THỬ ĐỘC LẬP - AI LÀ NGƯỜI

KIỂM THỬ?
Tư duy sử dụng trong khi kiểm thử và xem xét khác với tư duy mà sử dụng trong khi
phân tích hoặc phát triển. Nếu đang xây dựng một thứ gì đó, sẽ phải làm việc tích cực
để giải quyết các vấn đề trong thiết kế và hiện thực hóa một sản phẩm đáp ứng nhu
cầu nào đó.

Tuy nhiên, khi kiểm thử hoặc đánh giá một sản phẩm, tức đang tìm kiếm lỗi trong sản
phẩm và do đó, chúng ta sẽ chỉ trích sản phẩm đó.

Giả sử bạn định nấu một bữa ăn để tham gia cuộc thi đầu bếp. Bạn chọn menu, thu
thập nguyên liệu, nấu thức ăn, dọn bàn và phục vụ bữa ăn. Nếu muốn giành chiến
thắng, bạn phải làm tốt từng nhiệm vụ có thể.

Giả sử thay vào đó bạn là một trong những giám khảo đánh giá các bữa ăn của cuộc
thi. Bạn kiểm tra mọi thứ một cách nghiêm túc, bao gồm thực đơn, thành phần,
phương pháp được sử dụng, tuân thủ thời gian và ngân sách cho phép, lựa chọn
nguyên liệu, sự sang trọng của cách bày trí bàn và phục vụ, cũng như hình thức và
hương vị của bữa ăn.
Để phân biệt giữa các đầu bếp cạnh tranh, bạn sẽ khen ngợi mọi khía cạnh tốt trong
màn trình diễn của họ nhưng đồng thời cũng sẽ ghi nhận mọi lỗi và lỗi mà mỗi đầu
bếp mắc phải.

Với kiểm thử phần mềm cũng vậy: xây dựng phần mềm đòi hỏi một tư duy khác với
kiểm thử phần mềm. Không có nghĩa là người kiểm thử không thể là lập trình viên,
hoặc lập trình viên không thể là người kiểm thử, mặc dù họ thường có những vai trò
riêng biệt.
Lập trình viên có phải là tester?

Trên thực tế, lập trình viên là người kiểm thử- họ kiểm tra các thành phần mà họ xây
dựng và sự tích hợp của các thành phần vào hệ thống.

Người đầu bếp giỏi sẽ quan trọng như giám khảo cuộc thi về công việc của chính anh
ta, để ngăn chặn và sửa chữa những sai sót và lỗi trước khi bất kỳ ai nhận ra chúng.

Vì vậy, với tư duy đúng đắn, các lập trình viên có thể kiểm tra code của họ; thực tế thì
các lập trình viên kiểm tra code của họ và tìm ra nhiều vấn đề, giải quyết chúng trước
khi bất kỳ ai khác nhìn thấy lỗi. BA nên xem xét các yêu cầu của chính mình. Các
kiến trúc sư hệ thống cũng nên xem xét lại các thiết kế của họ.

Tuy nhiên, tất cả chúng ta đều biết rất khó để tìm ra sai lầm của chính mình. Vì vậy,
BA, kiến trúc sư và lập trình viên thường dựa vào những người khác để giúp kiểm tra
công việc của họ. Người khác này có thể là một BA, nhà thiết kế hoặc lập trình viên
khác. Một người sẽ sử dụng phần mềm có thể giúp kiểm thử được.

BA có thể thực hiện một số việc kiểm thử. Các chuyên gia kiểm thử (những người
kiểm thử chuyên nghiệp) cũng thường tham gia.

Trên thực tế, kiểm thử có thể liên quan đến nhiều người mà mỗi người tiến hành một
cấp độ kiểm thử khác nhau. Điều này cho phép kiểm thử độc lập hệ thống.

Xem xét các điểm trong vòng đời phát triển phần mềm nơi kiểm thử diễn ra trong
Chương 2, sẽ thấy ở đó một số giai đoạn đánh giá và kiểm thử được thực hiện trong
suốt vòng đời và đây có thể là những đánh giá và kiểm thử độc lập.

Trong giai đoạn đầu của vòng đời, việc xem xét các yêu cầu và tài liệu thiết kế bởi
một người nào đó không phải là tác giả sẽ giúp tìm ra lỗi trước khi bắt đầu lập trình và
giúp xây dựng phần mềm phù hợp.
Sau khi lập trình, phần mềm có thể được kiểm thử độc lập. Mức độ độc lập này giúp
tránh được sự thiên vị của tác giả và thường hiệu quả hơn trong việc tìm ra lỗi.
Có thể xác định một số cấp độ độc lập, được liệt kê ở đây, từ cấp độ độc lập thấp nhất đến cao nhất:

 Kiểm thử được thực hiện bởi người viết ra nó;

 Kiểm thử được thực hiện bởi một người khác trong cùng một nhóm, chẳng hạn
như một lập trình viên viên khác;
 Kiểm thử được thực hiện bởi bởi một người từ một nhóm tổ chức khác, chẳng
hạn như một nhóm kiểm thử độc lập;
 Các bài kiểm tra được thiết kế bởi một người từ một tổ chức hoặc công ty khác,
như kiểm thử thuê ngoài hoặc chứng nhận bởi một tổ chức bên ngoài.
Tính độc lập quan trọng nhất trong việc kiểm thử?

Tuy nhiên, cần lưu ý rằng tính độc lập không nhất thiết phải là yếu tố quan trọng nhất
trong việc kiểm thử tốt. Những nhà phát triển biết cách kiểm thử cũng giống như
những đầu bếp giỏi, tự phê bình bản thân, họ có được lợi ích của sự quen thuộc và
niềm tự hào về công việc đi kèm với sự chuyên nghiệp thực sự.

Các nhà phát triển như vậy có thể tìm ra nhiều lỗi trong code của họ một cách hiệu
quả. Một số phương pháp luận phát triển phần mềm nhấn mạnh vào việc các nhà phát
triển thiết kế các bài kiểm thử trước khi họ bắt đầu lập trình và thực hiện các bài kiểm
tra đó liên tục khi họ thay đổi code.

Cách tiếp cận này thúc đẩy quá trình kiểm thử sớm và phát hiện lỗi sớm, mang lại
hiệu quả về chi phí. Hãy nhớ rằng, kiểm thử độc lập có thể được thực hiện ở bất kỳ
cấp độ kiểm thử nào và việc lựa chọn mức độ độc lập phụ thuộc vào rủi ro trong bối
cảnh cụ thể.

Ở nội dung tiếp theo, chúng ta sẽ đi tìm câu trả lời cho câu hỏi "Tại sao chúng ta
không hòa nhập với phần còn lại của nhóm".

TẠI SAO ĐÔI KHI CHÚNG TA

KHÔNG HÒA NHẬP VỚI PHẦN CÒN
LẠI CỦA NHÓM?
Cũng như tính độc lập, việc tách vai trò người kiểm thử khỏi vai trò nhà phát triển
cũng được thực hiện để giúp tập trung nỗ lực và mang lại lợi ích của các nguồn lực
kiểm thử được đào tạo và chuyên nghiệp.

Trong nhiều tổ chức, các giai đoạn kiểm thử trước đó được thực hiện bởi các nhà phát
triển và tích hợp và các giai đoạn sau một cách độc lập, bởi một nhóm chuyên gia
kiểm thử hoặc bởi khách hàng.

Tuy nhiên, sự tách biệt này có thể dẫn đến các vấn đề như lợi thế của sự độc lập và tập
trung có thể bị mất đi nếu mối quan hệ giữa các nhóm xấu đi.

Mỗi tổ chức và mỗi dự án sẽ có những mục tiêu ngắn hạn và mục tiêu dài hạn
riêng. Các bên liên quan khác nhau, chẳng hạn như khách hàng, nhóm phát triển và
các nhà quản lý của tổ chức, sẽ có quan điểm khác nhau về chất lượng và có mục tiêu
riêng của họ.

Bởi vì con người và dự án được thúc đẩy bởi các mục tiêu, bên liên quan có quan
điểm mạnh nhất hoặc ảnh hưởng lớn nhất đối với một nhóm sẽ xác định một cách có ý
thức hoặc tiềm thức rằng các mục tiêu đó là gì. Mọi người có xu hướng sắp xếp kế
hoạch của họ với những mục tiêu này.
Ví dụ

Tùy thuộc vào mục tiêu, tester có thể tập trung vào việc tìm ra lỗi hoặc xác nhận rằng
phần mềm có hoạt động. Nhưng nếu một bên liên quan ít ảnh hưởng hơn trong quá
trình thực hiện dự án nhưng lại ảnh hưởng nhiều hơn khi giao hàng, thì có thể xảy ra
xung đột quan điểm về việc liệu kiểm thử có đáp ứng được các mục tiêu của nó hay
không.

Một người quản lý có thể muốn xác nhận rằng phần mềm hoạt động và nó "đủ tốt"
nếu đây được coi là cách chuyển giao nhanh nhất có thể.

Một người quản lý khác có thể muốn việc kiểm thử tìm ra càng nhiều lỗi càng tốt
trước khi phần mềm được phát hành, việc này sẽ mất nhiều thời gian hơn để thực hiện
và sẽ cần thời gian để sửa chữa, kiểm thử lại và kiểm thử hồi quy.

Nếu không có mục tiêu được nêu rõ ràng và tiêu chí dừng mà tất cả các bên liên quan
đã đồng ý, thì các tranh luận có thể nảy sinh trong quá trình kiểm thử hoặc sau khi
phát hành về việc liệu kiểm thử đã được thực hiện "đủ" hay chưa.

Chúng ta thường tin rằng mình đã cố gắng hết sức để tạo ra công việc (tài liệu, code,
các bài kiểm thử, bất cứ điều gì) chính xác và hoàn chỉnh. Vì vậy, khi người khác tìm
ra lỗi, chúng ta có thể nhận ra điều này một cách cá nhân và khó chịu, nhất là khi đang
bị áp lực về thời gian. Điều này đúng với các nhà quản lý, nhân viên, tester và nhà
phát triển. Tất cả chúng ta đều mắc sai lầm và cảm thấy khó chịu, bực bội hoặc chán
nản khi ai đó chỉ ra chúng.

Vì vậy, với tư cách là người kiểm thử, họ sẽ chạy một bài kiểm thử (theo quan điểm
của ho), đó là một bài kiểm thử tốt để tìm ra lỗi trong phần mềm.
Phản ứng của các bên liên quan?

Tester rất vui vì đã tìm ra một lỗi tốt! Nhưng BA, nhà thiết kế, nhà phát triển, người
quản lý dự án và khách hàng sẽ phản ứng như thế nào?

Những người xây dựng sản phẩm có thể phản ứng bảo vệ và coi lỗi được báo cáo này
là chỉ trích cá nhân chống lại sản phẩm và chống lại tác giả.

Người quản lý dự án có thể khó chịu với mọi người vì đã trì hoãn dự án. Khách hàng
có thể mất niềm tin vào sản phẩm vì những gì họ có thể nhìn thấy chỉ là lỗi.

Bởi vì kiểm thử có thể được coi là một hoạt động "phá hoại", tester cần chú ý báo cáo
về lỗi một cách khách quan và lịch sự nhất có thể.

Công việc của tester là mang tính xây dựng trong việc quản lý rủi ro sản phẩm, cần
phải cẩn thận khi xem xét và khi kiểm thử:
Truyền đạt những phát hiện về sản phẩm một cách trung lập, tập trung vào sự thật mà không chỉ trích người đã tạo ra sản phẩm đó.

 Ví dụ, viết các báo cáo sự cố khách quan và thực tế và xem xét các phát hiện.
 Đừng hả hê, bạn cũng không hoàn hảo!
 Đừng đổ lỗi, mọi sai lầm có lẽ là của nhóm hơn là của một cá nhân.
 Phê bình một cách xây dựng và thảo luận vềlỗi và lưu vết nó.
Giải thích rằng bằng cách biết về điều này, có thể khắc phục hoặc sửa chữa nó để hệ thống được chuyển giao tốt hơn cho khách hàng.

 Nói những gì bạn thích và những gì hiệu quả, cũng như những gì không hiệu
quả.
 Chi ra rủi ro một cách trung thực, không phải mọi thứ đều được ưu tiên cao.
 Đừng chỉ nhìn thấy mặt bi quan - hãy đưa ra lời khen ngợi cũng như phê bình.
 Chỉ ra những rủi ro nào đã được phát hiện và lợi ích của việc xem xét hoặc
kiểm thử.
Bắt đầu bằng sự hợp tác hơn là trận chiến. Nhắc nhở mọi người vềmục tiêu chung của hệ thống để mang lại chất lượng tốt hơn.

 Lịch sự và hữu ích, hợp tác với đồng nghiệp.

  Cố gắng hiểu đối phương cảm thấy như thế nào và tại sao họ phản ứng như
vậy.
 Xác nhận rằng đối phương đã hiểu những gì bạn đã nói và ngược lại.
 Giải thích bài kiểm thử hoặc bài đánh giá giúp ích cho tác giả như thế nào.
 Đề nghị công việc của bạn cũng được đánh giá.

Nhiệm vụ của tester là cung cấp cho mọi người thông tin rõ ràng, khách quan và để
làm điều này, tester tiến hành tìm kiếm lỗi, khai thác lỗi và sửa lỗi.

Người đánh giá và người kiểm thử giỏi có mong muốn và có khả năng tìm ra vấn đề,
và điều này đúng cho dù việc kiểm thử là công việc chính của họ hay là một phần vai
trò của họ với tư cách là nhà phát triển.

Những người có kinh nghiệm về việc tìm lỗi, được đặc trưng bởi sự tò mò, sự bi quan
chuyên nghiệp, con mắt phê phán và sự chú ý chi tiết. Tuy nhiên, trừ khi tester có kỹ
năng giao tiếp tốt, lịch sự, thấu hiểu người khác và có thái độ tốt với đồng nghiệp,
khách hàng, người quản lý và những người còn lại trong nhóm, còn không tester sẽ
thất bại với tư cách là người kiểm thử vì không ai chịu lắng nghe họ cả.
Giao tiếp nhóm như thế nào?

Tester và test leader cần có kỹ năng cá nhân tốt để truyền đạt thông tin thực tế về lỗi,
tiến độ và rủi ro theo cách có tính xây dựng. Đối với tác giả của phần mềm hoặc của
tài liệu, thông tin lỗi có thể giúp họ cải thiện kỹ năng của mình, nhưng chỉ khi nó
được cung cấp theo cách có ích cho họ.

Một cuốn sách thú vị trong bối cảnh này là Six Thinking Hats (Sáu chiếc mũ tư duy).
Nó không phải là về kiểm thử mà là mô tả một cách để truyền đạt thông tin khác
nhau: sự kiện; cảm xúc; suy nghĩ bi quan, suy nghĩ lạc quan; và những ý tưởng sáng
tạo.

Khi xem xét hoặc kiểm thử, cần truyền đạt sự thật một cách khách quan, nhưng các
loại thông tin khác cũng rất hữu ích: "Điều này đã xảy ra; đây là cách mà tôi cảm thấy
thế nào về nó; những gì đã tốt; những gì có thể xảy ra sai; đây là cách chúng tôi có thể
giải quyết vấn đề".

Là một phần của việc giúp cung cấp đánh giá rủi ro, tester có thể giúp các nhà quản lý
và khách hàng đưa ra các quyết định dựa trên rủi ro dựa trên tác động chi phí và thời
gian của lỗi.

Nếu họ kiểm thử và phát hiện ra lỗi sẽ phải tiêu tốn $ 15.000 để sửa và kiểm thử
lại/kiểm thử hồi quy, nó có đáng để sửa không? Nếu nó có thể là nguyên nhân gây ra
tác động kinh doanh $ 50.000 trong môi trường thật, khách hàng có thể muốn nó được
khắc phục. Còn nếu nó chỉ gây ra tác động kinh doanh là $ 10.000 nhưng bất kỳ sửa
chữa nào khó thực hiện và có khả năng gây tác động tiêu cực ở nơi khác, thì tốt hơn là
không nên sửa.

Bằng cách cung cấp cho nhóm thông tin về lỗi mà họ thấy hữu ích, tester có thể giúp
họ đưa ra quyết định đúng đắn về việc khắc phục hoặc không sửa chữa các vấn đề.
Nói chung, lỗi được tìm thấy và sửa chữa trong quá trình kiểm thử sẽ tiết kiệm thời
gian và tiền bạc sau này và giảm rủi ro, vì vậy cần chỉ ra rằng đó là trường hợp để
kiểm thử có giá trị.