Mindset cho Tester người kiểm thử phần mềm

✅ Mindset của Tester trong quá trình phát triển phần mềm

• Trong giai đoạn phân tích yêu cầu, Tester sẽ tìm hiểu toàn bộ ứng dụng. Họ tạo ra các kế hoạch kiểm tra, chiến lược kiểm tra và hiểu phạm vi của ứng dụng.
• Khi quá trình phát triển hoàn tất và ổn định, họ kiểm tra ứng dụng một cách nghiêm ngặt trên các môi trường khác nhau và kiểm tra hiệu suất và chức năng của tổng thể ứng dụng.
• Tester bắt đầu thử nghiệm với suy nghĩ rằng sự phát triển được thực hiện bởi các Developer có thể bị lỗi và cần phải được kiểm tra kỹ lưỡng trước khi bàn giao.
• Bất kỳ lỗi nào phát sinh trong quá trình kiểm tra đều được ghi lại trong công cụ theo dõi lỗi.
• Sau đó, các kịch bản tự động được tạo ra để giảm chi phí thủ công.
• Kiểm tra hồi quy và kiểm tra lại được thực hiện để đảm bảo sản phẩm có chất lượng tốt nhất.

Theo quan điểm cá nhân mình thấy Testing (kiểm thử) cần phải có tư duy (mindset), và nó không đơn thuần chỉ là một role cần được thực hiện. Testing không chỉ là một phần của chu trình phát triển mà nó nên được đi sâu vào mọi giai đoạn. Mọi khía cạnh đều có thể test , cho dù đó là requirements, architectural diagrams, code, unit tests, test scripts, user docs ...

✅ Tester cần hiểu các vấn đề sau 

Khi nào thì start Testing?

Nếu mình bắt đầu làm việc với một dự án, mình sẽ bắt đầu Testing từ lúc được assigned vào dự án . Có một lý do chính đáng cho việc này đó là mình cảm thấy rằng thử nghiệm không chỉ đơn thuần là viết Test plans, execute test cases, developing automation ...

Testing không chỉ là Test Cases

Từ khi bắt đầu start cuộc thảo luận đầu tiên về một sản phẩm hoặc tính năng mới , mình biết là mình đã đang Testing , đang tìm hiểu về các thay đổi, đang hiểu về các tính năng, để nghĩ đến những câu hỏi thích hợp sẽ giúp mình hiểu về sản phẩm để có thể hỗ trợ dev trong việc thiết kế design ,nâng cao xử lý code . Mình sẽ ghi lại những suy nghĩ của mình và cung cấp một số form Test Plan (có thể là sơ đồ mindmap ). Sau đó sẽ viết các trường hợp kiểm thử, tự động hóa(nếu cần) để verify Test cases rồi đưa ra các defects. Dù sao đi nữa thì Testcases cũng vẫn chỉ là một phần trong vai trò tổng thể của Testing .

Testing được sử dụng để cải thiện chất lượng

Testing không chỉ là làm thế nào để phá vỡ sản phẩm, mà còn là về cách chúng ta có thể giúp cải thiện chất lượng của sản phẩm được giao. Hiểu đơn giản là khi có một cuộc họp ở thời điểm bắt đầu một sprint, bạn sẽ đặt những câu hỏi về design và đưa ra các cải tiến nâng cao chất lượng, sau đó bạn tìm cách tạo ra sản phẩm chất lượng tốt hơn. Chắc chắn một điều là khi tìm dk mấu chốt vấn đề ở giai đoạn design sẽ hiệu quả và hiệu quả hơn là phát hiện ra bug sau khi nó được develop vì sau đó sẽ tốn effort để fix chúng .Tuy nhiên thì mọi vấn đề cũng không phải dễ dàng nhìn thấy được nên quan trọng rằng bạn luôn có suy nghĩ để cải thiện chất lượng sản phẩm dù nó đang trong bất kỳ giai đoạn phát triển nào.

Khi nào kết thúc Testing?

Công việc của Tester không bao giờ có định nghĩa hoàn thành , sẽ có thể luôn có nhiều Testcases để xác định và có nhiều kịch bản hơn để chạy, nhưng nếu mức chất lượng đủ cao đã được chứng minh và rủi ro liên quan đến công việc với xác suất là thấp thì bạn hoàn toàn có thể tự tin để nói tôi hoàn thành test . Thực tế thì các định nghĩa về hoàn thành thường sẽ được xác định bởi các tiêu chí do team đặt ra hoặc theo tiêu chuẩn của riêng bạn. Điều đó có nghĩa là, thực ra tất cả các mục Tests đã pass không bao giờ đủ để nói rằng Testing đã hoàn tất, luôn có nhiều việc có thể được thực hiện.

✅ 4 bước cần làm để hướng tới phát triển tư duy Agile Testing

Bước 1: Education, education, education!

Nếu bạn muốn những Tester của bạn bao quát được tư duy nhanh nhẹn, thì điều đầu tiên cần làm là Education (nâng cao kiến thức)

1. Tester phải tự học về những quy trình Agile : Về Quy trình làm việc mới sẽ là gì ? Điều gì sẽ được mong đợi ở họ trong vai trò mới của họ ?

2. Group Testers cần có tiếng nói trong business . Họ phải được trao quyền để quản lý việc nâng cao kiến thức hoặc nhóm chỉ đạo Agile. Điều quan trọng là họ góp phần vào việc áp dụng Agile và cảm thấy rằng các yêu cầu riêng của họ đang được xem xét.

3. Tester phải chủ động trong việc học hỏi về từng dự án. Họ phải được thông báo và bao gồm ngay từ đầu của một dự án mới; họ phải hiểu giá trị doanh nghiệp và làm việc để hiểu nhu cầu của người dùng cuối.

Bước 2: Cân bằng tài liệu

Sự phụ thuộc vào tài liệu là một thói quen trong cách làm cũ và cần phải được phá vỡ và những kỳ vọng xung quanh việc tạo ra nó phải cần xem xét lại. Việc dựa vào các tài liệu yêu cầu được viết trước khi bất kỳ sự phát triển nào bắt đầu sẽ không còn hiệu quả nữa.

Agile là tất cả về việc thích ứng với vòng phản hồi của người dùng, tạo ra sản phẩm cuối cùng trong các lần lặp khi bạn thực hiện . Điều đó có nghĩa là bất kỳ tài liệu nào bạn dựa vào đều phải được cập nhật theo sự phát triển sản phẩm.

Một tư duy Agile Testing có nghĩa là Tester nên tránh sa lầy vào những điều lan man và chưa được thực hiện 1 cách cẩn thận . Người Tester càng dành nhiều thời gian để thực hiện các nhiệm vụ như ghi lại các Testcases , họ càng có ít thời gian để thực hiện các hoạt động giá trị gia tăng như tìm lỗi. Automatic script generation để kiểm tra hồi quy là một lối tắt thông minh bạn có thể thực hiện.

Những gì yêu cầu trong một Agile environment chính là "smart documentation" . Cần phải có một sự chấp nhận rằng không phải tất cả mọi thứ đều có thể được ghi lại và tập trung vào những gì mà thực sự cần thiết để duy trì các quy trình.

Tạo sự cân bằng giữa việc ghi chép tài liệu đủ để cho phép chuyển giao kiến thức trong tương lai trong khi giữ công việc không cần thiết ở mức tối thiểu có thể là một trong những phần khó nhất khi thực hiện quy trình nhanh.

Bước 3: Sắp xếp lại metrics

Có lẽ sự điều chỉnh thái độ lớn nhất cần để chuyển đổi thành công sang agile testing là sự cố gắng thay thế mindset testing theo các số liệu (metrics). Team QA và Testers đã từng sử dụng metrics để đo lường theo dõi hoàn thành các hoạt động Testing và tạo ra các defects . Những metrics đó không phù hợp với bản chất giá trị gia tăng của Agile. Danh sách “Những cái Không” sau đây có thể làm cho những Testers mà đã quen với mindset metrics truyền thống thấy lo lắng , nhưng nó sẽ khiến team có được sự phù hợp hướng tới sự thành công trong dự án:

1. Không tập trung vào tổng số defects . Số lượng lỗi mà người kiểm tra tìm thấy không phải là thước đo đầy đủ về hiệu quả của chúng. Tập trung vào số lượng hơn chất lượng là một sai lầm. Nếu những người Tester cảm thấy bị áp lực phải đánh những con số thì họ có nhiều khả năng bỏ qua những khiếm khuyết đáng ngờ . Yêu cầu tính năng, khoảng cách thiết kế và yêu cầu không rõ ràng không phải là defects.

2. Không tập trung vào số lượng kịch bản thử nghiệm được thực hiện mỗi ngày. Mỗi case không được tạo ra giống nhau. Con số là sai lệch và nên tập trung vào việc cung cấp chất lượng thay vì số lượng.

3. Không tập trung vào tỷ lệ pass trên tổng thể kịch bản. Cho dù các test scripts riêng lẻ chạy mà không xảy ra sự cố thì điều này không nói lên rằng sản phẩm đã tốt với users , hoặc liệu nó có đáp ứng mong đợi của người dùng cuối hay không. Nói cho cùng thì Tester chính là người biện hộ lớn nhất cho người dùng cuối và việc của Tester là quan tâm đến việc người dùng có được sự vui vẻ , thoái mái, tiện lợi nhất khi sử dụng sản phẩm.

Trọng tâm nên chuyển sang sự hài lòng của người dùng cuối và tránh xa việc theo dõi hoạt động. Nếu mọi người trong công ty bạn đang hướng đến việc cung cấp sản phẩm tốt nhất cho khách hàng và lắng nghe phản hồi của họ, thì thành công sẽ chỉ là vấn đề thời gian .

Bước 4: Thay đổi thái độ

Một sự sẵn sàng để giao tiếp và hợp tác là tối quan trọng đối với sự thành công của Agile . Trước đây, các bộ phận QA thường có thể thành công như một đơn vị biệt lập - họ sẽ tự đặt mình là gatekeepers sản phẩm, cảm thấy như thể họ làm việc đối lập với các nhà phát triển. Vâng - Thời kỳ đó đã qua rồi - và đó là thời gian để đưa Tester vào cuộc. Còn việc nâng cao kiến thức , trao quyền cho họ và họ sẽ mang lại giá trị kinh doanh lớn hơn nhiều.

Đây là một con đường hai chiều. Trao quyền cho Tester và chịu trách nhiệm cho sự phát triển của họ . Đề cập việc sắp xếp các mục tiêu trong công ty của bạn để mọi bộ phận và mọi thành viên trong đội ngũ của bạn đều theo cùng một hướng.

Tất cả phải tập trung vào việc tạo ra trải nghiệm tốt nhất có thể cho người dùng cuối.

Tóm lại, bên cạnh việc bạn là một người chăm chỉ, cẩn thận, tỉ mỉ thì Tester ( Tester in Agile) là một nghề cần có tư duy tốt vì đặc thù công việc làm trong lĩnh vực phát triển phần mềm. Đối với mình kinh nghiệm làm việc không thực sự quan trọng bằng tư duy tốt. Vì vậy mỗi cá nhân hãy tự trau dồi và học hỏi để nâng cao mindset của mình. Mọi vấn đề đều được giải quyết nếu bạn có một cái nhìn và một tư duy tốt.

✅ Tester cần rèn luyện tư duy

1. Suy nghĩ chuyên nghiệp

Khi bạn thực hiện kiểm thử một sản phẩm thì bạn hãy suy nghĩ là bạn tiếp cận một sản phẩm đã bị hỏng. Bạn biết rằng nó sẽ có những sai sót và khiếm khuyết và nhiệm vụ của bạn là phát hiện và loại bỏ chúng. Khi thực hiện kiểm thử thì bạn phải nhìn rộng ra. Bạn nên "trưởng thành" hơn các developer. Bạn phải có khả năng nhìn thấy một lỗi từ cả 2 phía.

Trở nên chuyên nghiệp có nghĩa là bạn phải hoàn thành các dự án mà không có sự mơ hồ, chủ quan. Đừng cố lạc quan nghĩ rằng bạn có thể nhận được một dự án mà không gặp vấn đề gì, nó có thể ảnh hưởng đến bạn trong việc vượt qua các vấn đề đó.

2. Luôn luôn hoài nghi

Hoài nghi là một cái tốt đối với một người kiểm thử. Một người kiểm thử nên tò mò về mọi thứ. Khi bạn kiểm thử một ứng dụng thì bạn nên đứng trên lập trường của một người sử dụng chúng (end user). Khi làm việc với developer, bạn hãy tin tưởng đồng nghiệp của bạn, nhưng đừng bao giờ tin tưởng sản phẩm.


Hầu hết các developer đều là những người tuyệt vời và họ luôn làm hết sức mình. Nhưng khi nói đến sản phẩm, thì đối với người kiểm thử đừng tin tưởng sản phẩm và luôn nghi ngờ về chất lượng của sản phẩm. Trong quá trình kiểm thử thì bạn không nên cảm thấy ngại khi nói lên ý kiến của mình.

3. Công bằng, tham mưu, xây dựng với Developer

Người kiểm thử luôn luôn vô tư, tư vấn và xây dựng cho các developer, không chống lại họ vì chúng ta cùng một đội. Bởi vì bản chất của con người là tự hào về công việc của họ và không thích người khác chỉ trích cá nhân, công việc của họ.

Đừng quên các developer viết các phần mềm để vượt qua các lần kiểm thử. Công việc của một tester là tìm ra lỗi và báo cáo lỗi. Nhiều khi sẽ gặp khó khăn với các đông nghiệp trong quá trình làm việc, nhưng bạn hãy nhớ rằng mình đang làm việc chung để tạo ra giá trị nhất định, phục vụ tốt cho khách hàng.

Nếu cả nhóm cùng làm việc bị chậm trễ nhưng bạn hãy yên tâm rằng chúng ta đã phải làm việc rất nhiều giờ để có thể giao hàng đúng hạn. Vì vậy, khi bạn tìm thấy lỗi, bạn đừng tìm đến họ(developer) và nói rằng: "Có quá nhiều lỗi" - làm như vậy thì họ sẽ không hài lòng. Họ cũng đã rất cố gắng làm việc của họ. Vậy nên bạn phải rất cẩn thận về cách bạn giao tiếp vấn đề với họ.

Trong trường hợp nếu developer đổ lỗi cho bạn thì bạn sẽ làm gì? Đây là một vấn đề cũng thường gặp trong quá trình làm việc. Đầu tiên bạn nên ngồi lại, phân tích vấn đề, xem sai chỗ nào mà có lỗi, từ đó tìm giải pháp khắc phục. Đôi khi developer nghĩ rằng lỗi sẽ không có nếu bạn không kiểm tra nó. Bạn phải đối phó tùy vào trường hợp. Theo một số cách, nó giống như phải đối phó với một đứa trẻ. Nên bạn phải cẩn thận. Chúc bạn may mắn!

Trên đây là một số tư duy cho Tester - người kiểm thử phần mềm. Hi vọng nó sẽ có ích đối với bạn.

Tài liệu tham khảo

• https://www.onestopsoftwaretesting.com/testers-mindset/
• https://www.softwaretestinghelp.com/developing-the-agile-testing-mindset/