Chỉ tiêu chất lượng của một Tester: 22 sức mạnh cốt lõi để trở thành một Good Tester - P1

Bài viết này cung cấp cho bạn một danh sách các đặc điểm đặc trưng mà bất kỳ tester nào cũng phải sỡ hữu để trở thành một good tester. Và với các đặc điểm này, lần lượt, giúp đỡ rất nhiều trong việc xác định các chỉ tiêu chất lượng của một tester.

Tại sao tôi chỉ đề cập đến Tester? Và tại sao tôi không đề cập đến Developer hay chức vụ nào khác?

Tôi chỉ thấy rằng tất cả các công việc liên quan đến SDLC trong việc phát hành một phần mềm là khá đơn giản khi so sánh với trách nhiệm của một Tester.

Phạm vi công việc của developer thì rất dễ dàng được xác định thông qua framework họ làm, tuy nhiên đối với 1 tester thì không có cơ sở/ranh giới cụ thể để xác định phạm vi công việc của họ.

Trong khi đó, khả năng, hiệu quả, và độ tập trung của tester ảnh hưởng trực tiếp đến hành vi sản phẩm trong suốt quá trình sản xuất.

Vậy, điều gì làm cho một người trở thành một Good Software Tester?

P/s: Làm ơn hiểu rằng tôi không có ý nhận định developer hay bất kỳ một vị trí khác nào ít quan trọng hơn vị trí Tester trong một dự án. Ở đây tôi chỉ lấy nó làm tài liệu tham khảo thôi.

Chỉ tiêu chất lượng của một Tester

Đây là một bài viết chi tiết bao gồm tất cả các khía cạnh của chủ đề. Vì vậy hãy ngồi xuống, thư giãn và uống một tách cà phê để đọc nhé.

Tất cả các chức vụ ngoại trừ tester, đều liên quan đến các kỹ năng có sẵn bên ngoài thị trường, và họ chỉ cần học và sử dụng nó khi thực hiện công việc của họ trong phát triển phần mềm. Nhưng với một tester, đó là các đặc điểm cá nhân và sự chu đáo mà mỗi người sở hưũ riêng.

Nghĩa là, bạn có thể trở thành một developer nếu học một ngôn ngữ coding nào đó. Nhưng, tester không thể chỉ học một công nghệ, hoặc một tool, hoặc có được kiến thức về domain, rồi vỗ ngực nói: "Tôi đã học Python hoặc Selenium hoặc Security Testing trong lĩnh vực tài chính, hoặc lĩnh vưc FMCG, và bây giờ tôi là một Good tester". Vì vậy, học không bao giờ là kết thúc với tester.

Là một Developer, anh ấy có thể đơn giản bắt đầu viết code với những kiến thức mà mình có. Nhưng một tester thì không thể bắt đầu công việc trừ khi bạn có đủ kiến thức kỹ năng nhất định. Do đó, trừ khi và cho đến khi anh ấy sở hưũ đủ các kỹ năng đó, thì bạn không thể thực hiện hiệu quả công việc của mình.

Một tester phải làm việc trong một lĩnh vực kỹ thuật hoặc domain cụ thể cùng với công cụ được sử dụng cho dự án cụ thể mà anh ấy/cô ấy được assign. Nhưng nó sẽ không giống với lần assign tiếp theo. Nó là một cái gì đó khác. Nó sẽ khá mới, một công nghệ mới, một tool mới, và đặc biệt là một phương pháp mới.

Trong một khoảng thời gian, người ta đã chứng minh rằng Tester luôn có thể thu thập kiến thức về domain cần thiết dành riêng cho dự án, các công cụ và công nghệ được sử dụng trong dự án. Và cũng trong một khoảng thời gian quy định, Tester đã có thể thực hiện test hiệu quả và cung cấp phần mềm.

Good tester:

Thông thường mọi người sẽ hỏi: "Phẩm chất của good tester là gì?? Làm thế nào tôi có thể trở thành một good tester?? Làm thế nào tôi có thể giới thiệu tôi là một good tester??"

Không chỉ dựa trên Phương pháp kiểm tra, Quy trình thiết kế test, Test Execution, Automation hoặc Performance testing, mà một Tester cần phải biết tất cả để anh ấy/cô ấy là một good tester.

Đó là văn hóa hoặc phẩm chất cơ bản mà một tester nên sở hữu, sau đó củng cố thêm bằng cách học tập thêm bên ngoài, và nó sẽ khiến một người mạnh mẽ hơn và trở thành một good tester.

Mọi người cũng quan tâm đến việc: " Điều gì bạn cảm thấy tốt hơn một Tester? Bạn đã đem đến cái gì từ nghề kiểm thử?" Vâng, nó không có gì ngoài sự hài lòng về chất lượng, sự hoàn hảo, gọn gàng, v...v..., đảm bảo rằng bạn đã làm một số điều tốt cho khách hàng của bạn.

Tôi không chỉ nói về những kỹ năng kỹ thuật dành riêng cho dự án mà một người nên sở hữu để trở thành một good tester. Sỡ hữu những kỹ năng và kiến thức này là điều bắt buộc. Dù chỉ mình nó không thể khiến một cá nhân trở thành expert tester, nhưng nó sẽ làm cho anh ấy/cô ấy trở thành một trong những Tester có thể hiểu dự án và thực hiện test.

Do đó, hơn cả việc học, các phẩm chất hoặc đặc điểm nhất định nên được xây dựng trong một cá nhân để trở thành một good tester. Và tất nhiên những điều này là không thể học được, hoặc không thể được chứng nhận từ các viện có sẵn. Mà nó là sự sở hữu của mỗi người. Và sau đó những phẩm chất này sẽ được củng cố khi có nhiều kinh nghiệm hơn.

Vậy, bạn nghĩ tôi đang cố gắng viết về điều gì?

Tôi đang đề cập về những đặc điểm tính cách nhất định mà tôi sẽ gọi là "Core Strength -Sức mạnh cốt lõi" để trở thành một good tester.

Theo tôi, bất kỳ kỹ năng nào mà bạn thêm vào bản thân như: công nghệ test, quy trình, tool, và bất kỳ chứng chỉ nào như ISTQB, CSM, Agile Tester, ... mà bạn gắn vào tên của bạn, không bao giờ biến bạn trở thành một tester tốt hơn, trừ khi bạn có tất cả các giá trị cốt lõi được giải thích bên dưới đây.

"Sức mạnh cốt lõi" để là một Good Tester

#1. Đam mê công việc bạn đang làm:

Đặc điểm đầu tiên và quan trọng nhất cần sở hữu để trở thành một good tester đó là: Đam mê công việc đang làm. Tôi tự hỏi có bao nhiêu tester đã chọn vai trò, nghề nghiệp như một Tester??

Trừ khi có đam mê với Testing, anh ấy/cô ấy chắc chắn không thể tìm thấy động lực để hàng ngày làm công việc lặp đi lặp lại, không phân biệt dự án, công nghệ, độ phức tạp và những người liên quan. Đam mê là một đặc điểm sẽ làm cho tester khám phá nhiều hơn trong việc xác định các issue của phần mềm.

Đam mê là điều duy nhất khiến anh ấy/cô ấy không bao giờ bằng lòng với kiến thức mình có và khối lượng công việc mình hoàn thành. Do đó đam mê khiến họ làm hoặc học nhiều hơn nhiều hơn nữa.

Tôi nghĩ đây là sự so sánh tốt nhất mà tôi có thể đưa ra. Nó giống như nghề bác sỹ. Không phải tất cả những ai đạt điểm cao trong các môn học và có thứ hạng cao nhất đều có thể lấn sân sang lĩnh vực y học. Mà Đam mê là điều khiến ho vào được nghề này.

Thử tưởng tượng sẽ như thế nào với các bệnh nhân nếu gặp một bác sỹ không có đam mê? Tương tự, cho đến khi và trừ khi có đam mê với Testing, anh ấy/cô ấy không thể trở thành một good tester được.

Tôi sẽ cho bạn một ví dụ thể hiện niềm đam mê về công việc họ làm.

Một người bạn của tôi trở thành bác sỹ dưới sức ép của gia đình anh ấy. Để duy trì hạnh phúc gia đình, anh ấy đã theo học ngành Y với rất nhiều đấu tranh, và cuối cùng cũng hoàn thành chương trình Y khoa của mình.

Khi anh ấy bắt đầu hành nghề, anh ấy không có bất kỳ một sự đam mê nào với công việc hàng ngày, và thấy nó nhàm chán sau một thời gian. Anh ấy rất thích làm kinh doanh. Mặc dù anh ấy đã đấu tranh (với cả bệnh nhân) trong suốt một thời gian để lấy cảm hứng, nhưng anh ấy không thể tiếp tục làm công việc này. Sau đó, anh ấy đã bỏ việc, chuyển sang làm kinh doanh như đúng đam mê của anh ấy.

Bây giờ anh ấy đang làm việc rất tốt và cảm thấy hạnh phúc hơn. Vì vậy, trừ khi bạn có đam mê với công việc của mình, thì bạn mới có thể làm tốt nhất.

Qua đó, tôi muốn nói rằng, để thực hiện testing, đặc biệt là quality testing, chắc chắn người ta phải có đam mê với nghề nghiệp và công việc làm hàng ngày.

Bạn đam mê như thế nào?

Đam mê testing và thái độ đối với chất lượng nên ăn sâu vào dây thần kinh, vào máu và DNA của mỗi Tester. Đam mê sự "Xuất sắc" sẽ làm cho mỗi cá nhân Tester trở nên mạnh mẽ hơn.

Đam mê giúp họ luôn tỉnh táo và mở to mắt nhìn sâu vào các chi tiết. Đam mê giúp họ luôn hoạt động và tham gia. Đam mê testing khiến tester kiểm tra ở mọi lúc mọi nơi và mọi thứ họ nhìn thấy, đó là điều rất cần thiết cho nghề nghiệp của họ.

#2. Sáng tạo và đổi mới:

Sáng tạo và đổi mới thường được gọi là "thinking out of the box" là một đặc điểm tính cách quan trọng khác mà một tester nên sở hữu.

Mục đích test là gì nếu như một người chỉ test những gì được code? Những defect định tính sẽ như thế nào nếu anh ấy/cô ấy chỉ test những gì đã được care?

Vậy, đặc tính của sự sáng tạo và đổi mới là làm cho tester nghĩ xa hơn và thu thập ý tưởng để thiết kế những bài test và scenario sinh động hơn, những cái thường không được cover khi code.

Sự sáng tạo giúp tester cung cấp những feedback về việc tăng cường sản phẩm, và giúp sản phẩm dành được vị trí tốt hơn trên thị trường bằng cách làm nó nổi bật hơn những sản phẩm tương tự khác.

Một tester có thể suy nghĩ và hình dung ra sản phẩm chỉ với các chi tiết được cung cấp thông qua các yêu cầu. Do đó họ khá sáng tạo. Họ cũng có thể rip sản phẩm bằng cách xác định các thiếu sót của sản phẩm, chỉ ra mức độ hiệu quả của sản phẩm, thậm chí chứng minh nó bằng cách xác định các cách sử dụng sai.

Tư duy đổi mới của tester là sử dụng tốt nhất sự kết hợp giữa tool và công nghệ khác nhau có sẵn trên thị trường để tùy chỉnh yêu cầu của họ, để đạt được các mục tiêu thử nghiệm với chi phí giảm, từ đó có thể tăng tốc ra thị trường.

Với những thay đổi trong phạm vi công việc của một tester, trách nhiệm của tester không chỉ là tìm kiếm defect mà còn phải tăng giá trị cho sản phẩm, tăng giá trị cho khách hàng và doanh nghiệp của mình. Để làm được điều đó, tester cần phải khá đổi mới, sáng tạo, luôn luôn nghĩ xa hơn và độc đáo hơn.

Một tester có thể nghĩ về một cái gì đó vượt quá mức suy nghĩ của người bình thường. Phải vượt qua những suy nghĩ thông thường, tưởng tượng những kịch bản có thể xảy ra, và tự đặt câu hỏi, kiểu như: Cái gì sẽ xảy ra nếu nó như thế này? Cái gì sẽ xảy ra Nnu trường hợp đó xảy ra?, .... dựa trên tình hình cụ thể.

#3. Khả năng đặt mình vào vị trí của khách hàng:

Yếu tố quan trọng tiếp theo trong vai trò Tester đó là khả năng đặt mình vào vị trí của khách hàng.

Tôi biết rất dễ dàng để nói, nhưng thực sự khá khó khăn để trải nghiệm cảm giác và diễn biến bằng cách đặt mình vào tình huống của người khác, đặc biệt dưới vai trò người dùng cuối hoặc khách hàng.

Việc đứng trong vị trí của khách hàng, suy nghĩ khách hàng sẽ sử dụng sản phẩm của chúng ta như thế nào trong thực tế, từ đó hiểu mong muốn của họ như một khách hàng cuối cùng thật sự là một thách thức khá lớn.

Việc hiểu những gì chạy qua tâm trí của người khác là không thể. Luôn luôn là bình thường khi cảm thấy sản phẩm, sự sáng tạo, sự đóng góp, và công việc của chúng ta đã tốt và khó để tìm ra bug. Do đó, để hình dung rằng phần mềm đã đúng với mong đợi của khách hàng, việc nghĩ theo suy nghĩ của họ và đóng vai trò là một khách hàng là rất quan trọng với tester.

Luôn luôn nghĩ về khách hàng, nghĩ rằng nếu tôi có thể thực sự test theo cách mà khách hàng sử dụng trong thực tế là nhiệm vụ lớn nhất với một tester, và mô phỏng các kịch bản tương tự là cái tốt nhất của một good tester.

Có nhiều user khác nhau trên những lãnh thổ địa lý khác nhau, và họ cùng sử dụng sản phẩm của chúng ta. Trong những trường hợp như vậy, sử dụng kỹ thuật "test dựa trên cá nhân" là lựa chọn tốt nhất để mô phỏng hành vi của khách hàng, và từ đó mục tiêu đảm bảo quan điểm người dùng cuối sẽ được test.

Luôn cần phải nghĩ về nhiều scenario khác nhau trong thời gian thực và liên quan đến thử nghiệm trong phòng Lab với những diễn biến hàng ngày, có thể dựa trên vị trí địa lý và nhiều người khác nhau. Và chúng ta gọi nó là "Test dựa trên Scenario" và "Test dựa trên Use case".

Do đó, Tester cần phải tương tác với người dùng cuối và thu nhập càng nhiều scenario, use case càng tốt để kết hợp trong việc test của họ.

#4. Kỹ năng hình dung

Một tester nên luôn có kỹ năng hình dung tốt.

Tester cần hình dung trạng thái kết thúc của dự án không được tạo ra, trong quá trình phát triển của nó. Anh ấy/Cô ấy cần hình dung các tính năng và bắt đầu nghĩ về hành vi của nó trong sản xuất, và cách người dùng cuối sẽ sử dụng nó, từ đó dựa vào nó để tạo các scenario.

Anh ấy/Cô ấy cần đưa tất cả những gì đã thu thập được từ các bên liên quan khác nhau, và từ những nguồn khác nhau vào trong tâm trí, từ đó tạo ra một hình ảnh trực quan của sản phẩm. Do đó, Tester cần lấy được bức tranh lớn về sản phẩm, và nó dựa vào kỹ năng hình dung của họ.

#5. Kỹ năng phân tích:

Không chỉ quan trọng để có một bức tranh lớn, mà còn rất cần thiết đi sâu vào chi tiết của sản phẩm và quan sát cẩn thận, tiếp thu nội dung và đưa thông tin đó vào sử dụng đúng trong khi thử nghiệm.

Vì vậy, là một Tester, bạn cần phải quan sát, suy nghĩ và phân tích sâu sắc.

#6. Tầm nhìn bao quát

Để mắt đến từng chi tiết là một đặc tính quan trọng khác của tester.

Tôi tin rằng, trừ khi người ta tìm hiểu sâu hơn và khám phá nhiều hơn về sản phẩm, thì họ không thể hiểu kỹ về sản phẩm và có thể test kỹ lưỡng nó. Do đó, "để mắt đến từng chi tiết" là rất quan trọng với Tester để khai thác được hết tất cả các lỗ hổng của sản phẩm và xác định được những defect khiếm khuyết.

Tôi cũng nên thêm "Lắng nghe từng chi tiết" và nói rằng: "Để mắt và lắng nghe đến từng chi tiết".

Để mắt đến từng chi tiết sẽ mang lại sự rõ ràng hơn trong chủ đề. Mỗi chi tiết của sản phẩm rất quan trọng với khách hàng. Nếu bất kỳ ai nghĩ rằng nó không quan trọng và không cần chú ý đến thì họ đã nhầm. Vì vậy, việc chú ý và coi trọng từng và tất cả chi tiết của sản phẩm và khá quan trọng.

#7. Nghi ngờ

Khi cần xác định những sai sót, defects hoặc lỗ hổng trong sản phẩm, "nghi ngờ", theo nghĩa đen giúp Tester đạt được mục đích trong testing. Tôi có rất nhiều trường hợp mà khi bàn giao bản build cho tester, developer nói rằng "tất cả các defect đã được fix và sản phẩm hoạt động đúng rồi".

Nhưng khi Tester kiểm tra thực tế, đôi khi, defect chưa được fix, hoặc mới được fix một phần, hoặc thỉnh thoảng sinh ra lỗi khác từ lỗi ban đầu. Ở đây, tôi không nói rằng Developer nói dối hoặc gian lận, nhưng bằng cách nào đó, nó xảy ra trong nhiều tình huống.

Vì vậy, như đã đề cập, đặc tính của Tester là luôn nghi ngờ và không tin bất cứ thứ gì trừ khi họ test và chứng minh rằng nó hoạt động đúng. Vì vậy, luôn nghi ngờ. Không bao giờ đồng ý hoặc giải quyết điều gì đó bằng lời nói. Nghi ngờ và tò mò luôn làm tăng giá trị thử nghiệm sản phẩm và phản ánh đặc tính tốt nhất của Tester.

#8. Suy luận và đặt câu hỏi

Suy luận và đặt câu hỏi là một đặc tính quan trọng khác mà Tester cần sở hữu để chứng minh mình là một Tester hiệu quả.

Chỉ những người thật sự hiểu chủ đề mới có thể đặt câu hỏi, và những người có câu hỏi hay hơn cũng được coi là thông minh hơn. Không phân biệt suy luận và đặt câu hỏi, trong trường hợp này, đều cho phép Tester nhận biết rằng việc triển khai của họ là option tốt nhất hay chưa, hay còn có option khác tốt hơn.

Không chỉ như vậy, như đã đề cập trước đó, đặt câu hỏi giúp làm rõ hơn về sản phẩm và cũng để hiểu tại sao solution đó được thực hiện trong số nhiều option khác.

Trong trường hợp như vậy, Tester có thể mở rộng bản thân hơn nữa để suy nghĩ xa hơn và đưa ra ý tưởng tốt hơn, rẻ hơn mà chưa ai nghĩ đến. Chúng ta đều biết "năm nguyên tắc tại sao của việc tìm kiếm phân tích nguyên nhân gốc rễ". Nó chắc chắn giúp Tester tìm ra nguyên nhân gốc rễ của vấn đề và sau đó xác định có vấn đề tương tự nào tồn tại trong các khu vực khác của sản phẩm hay không.

Tester phải luôn luôn suy luận về bất cứ điều gì họ nghe để hiểu rõ hơn và chi tiết hơn. Đôi khi việc tự đặt câu hỏi cũng giúp ích rất nhiều. Tại sao nên thiết kế như này và tại sao không như này? Đường dẫn chi tiết là gì? Solution tối ưu nhất là gì?

Thực tế việc đặt câu hỏi giúp Tester có nhiều kiến thức hơn.

Tester cần có sự nhiệt tình để tìm hiểu cả trong lẫn ngoài sản phẩm, vượt ra ngoài phạm vi của testing để xác định những vấn đề thực sự của sản phẩm.

Một vài lần, tôi đã nhận thấy Developer hoặc Development Manager ra lệnh cho nhóm thử nghiệm khi có khủng hoảng, rằng team đã fix những defect ưu tiên, giờ chỉ cần chạy những test case này là đủ.

Hãy hỏi họ tại sao? Hiểu rõ tại sao những defect cụ thể đó xảy ra, và họ đã làm gì để fix nó. Thành thật mà nói, một good Tester sẽ không ngủ yên, trừ khi tất cả các nghi ngờ đã được làm rõ ràng từ tận gốc rễ.

Khi tôi nói điều này, tôi cũng muốn đề cập rằng Tester không nên chịu áp lực từ Developer và Development Manager hay bất kỳ ai khác trong team. Trách nhiệm của họ là phân tích kỹ lưỡng và quyết định những gì cần được test, thay vì ra lệnh cho tester.

#9. Bảo vệ chất lượng

Chắc chắn, 'bảo vệ chất lượng' là phẩm chất tốt nhất và bắt buộc nhất của Tester.

Chúng tôi biết có nhiều tình huống Tester phải chịu áp lực dẫn đến thỏa hiệp trong khi thử nghiệm, hoặc không được cung cấp đủ chi tiết khi hỏi, hoặc bị cắt giảm phạm vi thử nghiệm, thỏa hiệp trong việc sử dụng công cụ, ...

Trong trường hợp này, tốt hơn hết là dừng lại mọi thứ, chỉ chú tâm đến chất lượng và không có bất cứ sự thỏa hiệp nào.

Tôi đã quan sát một vài tổ chức, nơi người ta bỏ qua yêu cầu của Test Manager hoặc Test group và đưa ra quyết định riêng về testing. Nhưng nếu quyết định đó làm ảnh hưởng đến chất lượng của phần mềm, thì là một good Tester, họ không bao giờ chấp nhận điều đó.

Vì vậy, bảo vệ chất lượng của sản phẩm trở thành trách nhiệm của Tester, mặc dù nó được hình thành và xây dựng bởi toàn đội. Điều này trông có vẻ đơn giản, nhưng việc không làm ảnh hưởng đến chất lượng là một nhiệm vụ rất khó trong thực tế.

Đôi khi, khi mọi thứ đã hoàn thành, team muốn thực hiện một số thay đổi vào phút cuối, điều này thường ảnh hưởng đến chất lượng tổng thể. Vì vậy, bảo vệ chất lượng với những quyết định vào phút cuối như vậy để thực hiện thay đổi code trở thành trách nhiệm của Tester.

Khi chúng ta sử dụng từ "bảo vệ", nó có rất nhiều ý nghĩa. Nó không chỉ là test và tìm defect, mà còn là đảm bảo chất lượng tổng thể của sản phẩm, quan sát sâu sắc nếu có bất kỳ incident xảy ra, hoặc bất kỳ quyết định của bên liên quan gây ảnh hưởng đến chất lượng, và đấu tranh lại các quyết định như vậy trong suốt quá trình thử nghiệm.

#10. Cương quyết

"Cương quyết" trong việc đưa ra quyết định là một đặc tính khác của Tester.

Như đã giải thích trong các tình huống bên trên, nơi mà tester phải thỏa hiệp trong thử nghiệm và không thể thực hiện đủ thử nghiệm. Tôi sẽ nói rằng Tester cần phải cương quyết trong việc đưa ra quan điểm, quyết định, bày tỏ suy nghĩ, nếu không, nó sẽ chắc chắn bị bỏ qua và cuối cùng dẫn đến chất lượng của phần mềm kém.

Khi Tester cố gắng xác định rằng defect là rất nghiêm trọng, thì không một ai chấp nhận điều đó ngay lần đầu tiên. Họ luôn luôn muốn đẩy nó xuống hoặc gọi cho bên thứ ba để quyết định nó là nghiêm trọng hay không. Trong trường hợp như vậy, tester cần phải tích cực đưa ra suy nghĩ của họ.

Tester không nên có thái độ đầu hàng trước những quyết định khác trừ khi họ đánh giá được mức độ quan trọng của quyết định đó.

Nhiều khi, trong áp lực phát hành hoặc kịp tiến độ thời gian, các bên liên quan đề nghị giảm phạm vi thử nghiệm và khuyên bạn chỉ nên kiểm tra một khu vực cụ thể của phần mềm trong trường hợp sửa lỗi, hoặc là chỉ cần chạy các trường hợp kiểm thử này là đủ. Luôn là tốt khi có đầu vào nhưng không nên để bị ảnh hưởng bởi quyết định khác.

Vì vậy, tester cần phải rất cương quyết khi đưa ra quyết định.

Ở bài viết này, tôi giới thiệu với các bạn 10 sức mạnh cốt lõi đầu tiên để trở thành một Good Tester. 12 sức mạnh tiếp theo sẽ có ở bài sau. Các bạn đón đọc nhé.

Link tham khảo: https://www.softwaretestinghelp.com/quality-quotient-of-tester/