Hãy luôn nghĩ về Ethics trong khi kiểm thử

Khi chúng ta nói về "Đạo đức trong kiểm thử", các ví dụ thường nhất định là những vấn đề hết sức khó xử đẩy chúng ta vào tình trạng "tiến thoái lưỡng nan". Chúng ta có tránh report lỗi hay không? Chúng ta có báo cáo rằng việc thử nghiệm của mình đang diễn ra theo đúng kế hoạch hay không, mặc dù tình hình thực tế chắc chắn là muộn? Những câu hỏi này gọi là dành cho trẻ em để chúng chỉ có thể trả lời một là có hai là không? nó quá dễ dàng với chúng vì tình huống chỉ có đen - trắng. Nhưng thực tế cuộc sống của người lớn chúng ta - những người làm nghề kiểm thử phần mềm nói riêng sẽ cho bạn những tình huống, những trường hợp phức tạp mà ở đó câu trả lời là không rõ ràng bởi vì một thực tế là: “Giữa màu đen và màu trắng còn có cả màu nâu nữa”.

Nhiều ngành nghề đều có một quy tắc về đạo đức nghề nghiệp khác nhau và nghề kiểm thử phần mềm cũng không ngoại lệ. Bạn có thể đọc một phiên bản ngắn gọn về bộ quy tắc trên website ISTQB - nó là một phần của giáo trình cấp cơ sở.

Phiên bản trong chương trình học này là một bản tóm tắt ngắn gọn về bộ quy tắc là nơi khó để đọc và làm theo. Bạn nên làm nó, nếu không thể bạn có thể chỉ cần đọc một lần, toàn bộ văn bản của " The Software Engineering Code of Ethics and Professional Practice". Trong tài liệu này, bạn có thể dễ dàng nhận thấy rằng bộ quy tắc đó không chỉ liên quan đến khía cạnh công nghệ mà còn liên quan đến các khía cạnh xã hội và cá nhân.

Giả sử tất cả chúng ta là những người trung thực và có phẩm chất, tại sao chúng ta lại cần bộ quy tắc này? Và nếu có người không trung thực, bạn có nghĩ rằng có một bộ quy tắc đạo đức sẽ giải quyết được vấn đề hay không?

Có vẻ như đó là điều tầm thường và dư thừa. Chỉ cần để chứng minh quan điểm đó của bạn, chúng ta hãy cùng làm một bài kiểm tra ngắn.

1. Trong quá trình kiểm thử phần mềm, bạn tìm thấy một lỗi, mà lỗi đó ảnh hưởng đến chức năng quan trọng của người dùng hệ thống. Trong khi đó hệ thống sẽ được phát hành vào hai ngày nữa, và sửa lỗi thì sẽ trì hoãn cho việc phát hành này. Vậy bạn có báo cáo lỗi hay không?

   a. Có b. Không

2. Bạn đang kiểm thử một ứng dụng đã được phát triển cho một công ty của bạn bởi một công ty bên ngoài, theo hợp đồng. Nhà thầu gợi ý rằng nếu bạn không đào sâu và thay vì báo cáo rằng phần mềm không có lỗi, nó sẽ tác động tích cực về tài chính vào tài khoản ngân hàng của bạn. Bạn có làm theo yêu cầu không?

   a. Không b. Có

Tôi cho rằng trong cả hai trường hợp, bạn đã chọn câu trả lời là "a" mà không hề do dự gì cả. Không cần một quy tắc đạo đức. Trả lời “có” hoặc “không”

Khi chúng ta nói về "đạo đức trong kiểm thử phần mềm", thường xuất hiện trong tâm trí chúng ta là những vấn đề tương tự nhỏ. Chúng ta có tránh báo cáo lỗi hay không? Chúng ta có báo cáo rằng việc thử nghiệm đang tiến triển theo kế hoạch không, mặc dù nó chắc chắn là muộn?

1. Tình huống phức tạp hơn

Những câu hỏi này tương đối đơn giản vì nó chỉ cần trả lời: có - không, nói dối hoặc nói ra sự thật. Và câu trả lời cũng dễ dàng với vì tình hình quá đen - trắng. Tất nhiên bạn báo cáo lỗi; tất nhiên bạn không nói dối về sự tiến bộ. Nhưng cuộc sống sẽ cho bạn những trường hợp phức tạp mà câu trả lời là không rõ ràng. Đây là một ví dụ:

Một công ty lớn đã điều tra lựa chọn đầu tư vào việc khởi nghiệp. Công ty đã chỉ định Joe điều phối công việc đánh giá. Joe nhìn vào quá trình khởi nghiệp, càng nhìn vào ông càng trở nên tin tưởng rằng đầu tư là một ý tưởng hay. Tuy nhiên, để chắc chắn 100%, ông đã nhờ Jane, một người kiểm thử phần mềm, thực hiện một chu trình thử nghiệm ngắn trên mẫu thử nghiệm của sản phẩm khởi đầu. Jane chạy một số xét nghiệm và kết luận:

• Nói chung, giải pháp được cung cấp bởi sự khởi đầu là hoạt động tốt.

• Các kết quả tốt hơn đáng kể so với các giải pháp khác mà Jane đã kiểm tra trong quá khứ

• Có một khía cạnh mà kết quả là kỳ lạ; cần nhiều thời gian hơn và cần nhiều thử nghiệm hơn để kết luận vấn đề này nghiêm trọng như thế nào?

Jane đã viết một báo cáo và trước khi gửi nó đi, đã yêu cầu Joe cho ý kiến. Với sự ngạc nhiên của Jane, Joe đã yêu cầu cô đưa ra kết luận cuối cùng. Joe đã biện minh cho yêu cầu của mình bằng một lời giải thích thú vị: Mục tiêu của báo cáo là giúp ban lãnh đạo quyết định có đầu tư hay không? Jane đồng ý rằng họ nên đầu tư, vì vậy lý luận của Joe, tại sao nhầm lẫn quản lý với một chi tiết mà sẽ làm cho họ do dự? Rò ràng, họ không mong đợi để có được sản phẩm có lỗi hay là không. Vì họ biết đó là một nguyên mẫu đòi hỏi công việc nhiều hơn với nhiều thơi gian hơn.

Jane nên làm gì?

Sự thật, không cần phải xây dựng các trường hợp bí truyền. Có những vấn đề hàng ngày mà cũng không phải là đơn giản:

• Một người thử nghiệm tìm thấy hàng chục lỗi trong một khu vực nhất định của mã. Người kiểm thử biết rằng nhà phát triển sở hữu mã này không phải là để đổ lỗi cho điều này. Mã được thừa hưởng từ người khác đã làm ra lỗi. Người kiểm tra có thể báo cáo tất cả các lỗi này, nhưng tại một điểm nào đó, điều này sẽ gây nguy hiểm cho sự nghiệp của nhà phát triển, vì người quản lý dự án sẽ gắn thẻ anh ta là nguyên nhân chính gây ra các vấn đề về chất lượng. Nếu người kiểm tra báo cáo những lỗi này chính thức? Hoặc anh ta nên vượt qua các báo cáo trực tiếp với đồng nghiệp của mình, bảo vệ cả công việc ngang hàng của mình và chất lượng sản phẩm?
• Người quản lý phát triển yêu cầu người kiểm tra trì hoãn việc báo cáo một lỗi nghiêm trọng vào mộc ngày. Lý do là ngày hôm nay ông đã xem xét chương trình và một lỗi quan trọng mới sẽ gây ra một phản ứng nghiêm trọng từ các nhà quản lý của ông. Nó không phải là lỗi sẽ không được fix. Nó chắc chắn sẽ được fix, nhưng hãy để ngày mai.

Và như vậy. Thật dễ dàng để nghĩ đến những trường hợp như thế.

Tôi đã cố gắng để xem nếu tham khảo ở cuốn: "ISTQB Code of Ethics" để đưa ra một giải pháp cho các xung đột bên trên.

Trường hợp 1: QA cần phải công bằng đưa ra lỗi.

Đối với trường hợp đầu tiên, cuốn sách cho biết:

"Người kiểm thử phần mềm phải công bằng và hỗ trợ đồng nghiệp của họ, thúc đẩy hợp tác với các nhà phát triển phần mềm"

Mặt khác cuốn sách cũng cho thấy điều này: "Người kiểm thử phần mềm sẽ duy trì tính toàn vẹn và độc lập theo quan điểm chuyên môn của họ". Theo quan điểm ở các trường đại học, đặc biệt là trong các trường hợp nghiên cứu, thông qua các lỗi trực tiếp với các nhà phát triển thì có vẻ như đây là điều đúng đắn cần làm. Nhưng còn về tính toàn vẹn thì sao? Tính độc lập thì sao? Việc xem xét đội ngũ ở các trường Đại học có vẻ không khả quan.

Trường hợp 2: Không báo cáo lỗi mà report trong nội bộ team để Dev fix vào ngày hôm sau.

Trường hợp thứ hai thậm chí còn phức tạp hơn. Cả sản phẩm, khách hàng, nhà quản lý và công chúng sẽ bị ảnh hưởng tiêu cực bởi sự chậm trễ trong báo cáo. Có nhiều khả năng, theo cách khác: Báo cáo sẽ tạo ra phản ứng tiêu cực, tiêu cực từ quản lý, cùng với nhu cầu tiếp theo cho nhiều phiên họp báo cáo, nơi mọi người sẽ phải chứng minh rằng họ đang làm công việc của họ.

Thay vào đó, lỗi sẽ được xử lý một cách lặng lẽ và hiệu quả vào ngày hôm sau.

Có lẽ điều này thực sự là hành vi chuyên nghiệp và chính xác mà bộ quy tắc gợi ý - việc nhận thức rằng đôi khi tốt hơn là không nên làm theo quy trình mà không suy nghĩ?

Dường như trong khi quy tắc về đạo đức có vẻ tốt trên giấy, khi áp dụng nó cho các trường hợp hàng ngày là tương đối phổ biến, nó không đưa ra các chỉ thị rõ ràng.

Như vậy, "Code of Ethics" có thừa hay không? Làm thế nào chúng ta có thể quyết định điều đúng để làm?

Tôi thấy rằng quyển sách này đã có bằng khen miễn là bạn không mong đợi nó có một giải pháp đơn giản cho tất cả các tình huống. Để bắt đầu, sự tồn tại của các nguyên tắc chỉ chú ý tới thực tế rằng công việc của chúng tôi có các khía cạnh về đạo đức và chúng ta nên mong đợi để đối mặt với xung đột về đạo đức. Nguyên tắc nhấn mạnh rằng đạo đức phải là một tham số khi đưa ra quyết định.

Nó cũng không thừa nhận rằng không được bao gồm không chỉ các cân nhắc về mặt kỹ thuật mà còn có các khía cạnh "mềm" như hỗ trợ bạn hàng, thực tiễn quản lý hợp lý và hơn thế nữa. Đây là những khía cạnh nếu không phải là bằng văn bản, chúng tôi nghĩ rằng không nên đóng vai trò đánh giá tình hình. Rất hiếm khi bạn sẽ nhận được câu trả lời rõ ràng và cuối cũng trực tiếp từ: "Code of Ethics", nhưng trong nhiều trường hợp đó là một điểm khởi đầu tốt cho một cuộc trao đổi.

Trường hợp 3: Không báo cáo lỗi cụ thể mà viết trong báo cáo gửi khách hàng thể hiện phần mềm vẫn còn lỗi.

Tôi tự cho rằng mình may mắn vì bản thân đã gặp rất ít xung đột về đạo đức trong sự nghiệp của mình với tư cách là người kiểm thử phần mềm. Trong tất cả các trường hợp này, nó xảy ra khi có ai đó yêu cầu tôi làm việc một mình mà tôi nghĩ là không phù hợp.

Khi một chuyện như thế xảy ra, bạn hoàn toàn bị sốc. Thứ nhất, bởi vì bạn yêu cầu không hợp lệ. Và sau đó, khi bạn nhận ra rằng những câu trả lời bằng văn bản là quá đơn giản (không rõ ràng), nhưng trong thực tế thì tình huống lại không đơn giản như vậy - hoặc có thể là do thứ tự ưu tiên của người yêu cầu, tình trạng của dự án hoặc các trường hợp khác. Bạn nhận ra nó không dễ dàng để từ chối.

Nó thậm trí trở nên phức tạp hơn khi yêu cầu từ người quản lý trực tiếp của bạn. Nếu nó không thường xuyên như vậy, một khi mà bạn biết, nó sẽ là nguyên nhân ngay lập tức xa thải người quản lý của bạn, đó là một chút mà bạn có thể làm. Chắc chắn rằng, bạn có thể gặp người quản lý của quản lý của bạn. Về lý thuyết, đây là những gì mà bạn nên làm. Có lẽ có thể bạn sẽ được bảo vệ bằng chính sách của công ty, nhưng thực tế, sau đó bạn sẽ cảm thấy rất áp lực thậm chí là muốn rời bỏ nơi mà bạn đang làm việc.

Bạn có thể tranh luận với quản lý của mình và đưa ra một số hành động có lợi, có đạo đức hơn, nhưng việc đối đầu trực tiếp với quản lý của bạn hoặc là hành động tố cáo hành vi thiếu đạo đức là một công thức làm hỏng quan hệ công việc của bạn. Cuối cùng, bạn phải quyết định xem trường hợp có vấn đề có đến mức cần phải biện minh hay không?

Trong hầu hết các trường hợp, tôi nghĩ bạn thực sự không có lựa chọn nào khác ngoài việc tuân thủ và cố gắng giảm thiểu hành vi vi phạm đạo đức.

Ví dụ, trong khi không báo cáo một lỗi nghiêm trọng, bạn hãy thêm vào báo cáo rằng: "Quá trình thử nghiệm vẫn đang tiếp diễn và có thể chúng tôi vẫn sẽ tìm thấy lỗi nghiêm trọng". Ít nhất bạn cũng có thể truyền tải được thông điệp đến khách hàng là: "Rõ ràng sản phẩm chưa sẵn sàng cho phát hành nó".

Nếu những yêu cầu đó xảy ra nhiều lần, cuối cùng bạn sẽ không có lựa chọn nào khác ngoài việc để lộ nó ra ngoài, để lộ nó lên quản lý cấp cao hơn và hi vọng rằng tình huống sẽ được khắc phục mà không ảnh hưởng tiêu cực đến bạn.

Trong bất kỳ trường hợp nào, nguyên tắc này đã gợi ý rằng nơi làm việc mà đạo đức đang bị bỏ qua thường không phải là nơi bạn muốn làm việc.

Khi đó không phải là người quản lý trực tiếp của bạn, tôi thấy rằng chiến lược tốt nhất để quyết định nên làm gì là tham khảo ý kiến của người khác. Trước tiên, hãy nói chuyện với người quản lý trực tiếp của bạn để họ biết được vấn đề này và cũng là quan trọng. Sẽ giúp bạn quay trở lại trường hợp có người nào đó đã tuyên bố với bạn rằng bạn đã hành động phi đạo đức. Tư vấn với các đồng nghiệp từ các dự án khác là một cách tiếp cận có hiệu quả, giúp cho bạn có thể tin tưởng vào những quyết định mà họ đưa ra.

Một người không cảm xúc với tình trạng khó xử mà bạn gặp phải có thể suy nghĩ rõ hơn về điều đó. Sự không rõ ràng của họ về khía cạnh cá nhân và chính trị sẽ cho phép họ đưa ra những lời khuyên vô tư nhất. Ở một mức độ nào đó, có một số tình huống sẽ không thực tế vì họ không biết tình hình chung, nhưng cuộc hội thoại như vậy sẽ giúp bạn hiểu rõ hơn các thông số và cân nhắc liên quan. Nó sẽ giúp bạn thấy rõ ràng hơn những gì quan trọng khách quan và những gì chỉ là có vẻ quan trọng vì tình huống cảm xúc của bạn và có thể bỏ qua.

Những cuộc trò truyện như vậy có thể giúp tìm ra các giải pháp có đạo đức để tránh những xung đột mà chủ yếu là do sự thiếu linh hoạt gây ra. Ngoài ra, vì lời khuyên đến từ những người không liên quan và không bị ảnh hưởng bởi bất cứ điều gì bạn chọn làm, nó sẽ hỗ trợ bạn chấp nhập phương pháp tiếp cận trung gian mà không cảm thấy bạn bị đẩy ra ngoài chỉ vì việc làm đúng là không thoải mái.

Nếu bạn gặp một tình trạng "Tiến thoái lưỡng nan" về đạo đức trong nghề nghiệp, quyển sách: "ISTQB Code of Ethics" là một điểm khởi đầu tốt để tìm ra cách bạn hành động. Nhưng việc tư vấn các đồng nghiệp đáng tin cậy hoăc các nhà quan lý cũng là một ý tưởng thông minh để đảm bảo bạn đang suy nghĩ về mọi yếu tố. Và luôn luôn để cho lương tâm của bạn cảm thấy thoải mái nhất.

Trong bất kỳ trường hợp nào, tôi cũng khuyên bạn rằng: Nơi làm việc mà đạo đức đang bị bỏ qua thường không phải là nơi bạn muốn làm việc. Vì vậy, trước khi để nó xảy ra bạn hãy chuẩn bị các kiến thức cũng như kinh nghiệm nhiều nhất có thể trong quá trình làm việc ở nhiều dự án khác nhau và ở các bậc anh chị đàn anh bên trên để phòng trống ngăn chặn không cho các tình huống xấu có thể xảy ra mà cụ thể ở đây là hãy ngăn chặn lỗi ngay từ những vòng đầu của một chu trình phát triển phần mềm.

Cám ơn các bạn đã đọc bài viết!

Bài dịch được tham khảo từ nguồn: https://www.stickyminds.com/article/ethics-software-testing