Chỉ số chất lượng của một tester: 22 giá trị cốt lõi để trở thành người kiểm thử tốt

Hướng dẫn này cung cấp cho bạn một danh sách các tính năng đặc trưng mà bất kỳ người kiểm thử nào cũng phải có để trở thành một người kiểm thử tốt. Và những tính năng này, lần lượt, giúp đỡ rất nhiều trong việc xác định chỉ số Chất lượng của một Tester. Tại sao tôi chỉ nói về một Tester? Và Tại sao không phải là Nhà phát triển hoặc bất kỳ vai trò nào khác? Tôi chỉ cảm thấy rằng tất cả các công việc liên quan đến SDLC (vòng đời phát triển phần mềm) trong việc cung cấp một phần mềm 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 nhà phát triển được xác định rất tốt trong khuôn khổ, trong khi không có ranh giới cho nỗ lực đã bỏ ra, giá trị đã thêm vào cho khách hàng và phạm vi công việc được thực hiện bởi người kiểm thử. Khả năng, hiệu quả và trọng tâm của Tester được phản ánh trực tiếp trong hành vi sản phẩm trong quá trình sản xuất. Vì vậy, những gì cần cho bất cứ ai để trở thành một 'người kiểm thử phần mềm tốt'? Xin lưu ý rằng tôi không có ý định xem xét công việc của nhà phát triển hoặc của bất kỳ ai là thấp hoặc ít quan trọng trong một dự án. Nhưng tôi chỉ lấy nó làm một tham chiếu.

Chỉ số Chất lượng của một Tester Tất cả các vai trò ngoại trừ vai trò của một Tester, có liên quan đến kỹ năng bên ngoài có sẵn trên thị trường và họ cần phải tìm hiểu và sử dụng nó trong việc thực hiện một phần công việc của họ trong phát triển phần mềm. Nhưng đối với một Tester, đó là đặc điểm cá nhân của khả năng và sự chu đáo mà một người nên có. Ý tôi là, người đó có thể là một nhà phát triển bằng cách chỉ học một ngôn ngữ lập trình. Nhưng một Tester chỉ không thể học một công nghệ hoặc công cụ hoặc đạt được một kiến thức về lĩnh vực và nói 'Này, tôi đã học Python hoặc Selenium hoặc Kiểm thử bảo mật trong lĩnh vực Tài chính hoặc linhx vực FMCG và bây giờ tôi là một Tester tốt'. Do đó, việc học không bao giờ kết thúc cho một Tester. Là một nhà phát triển, người ta có thể đơn giản bắt đầu viết mã với kiến thức lập trình mà anh ta có, nhưng một Tester không thể chỉ bắt đầu kiểm thử của mình trừ khi anh ta sở hữu một số kỹ năng nhất định. Do đó, trừ khi và cho đến khi anh ta sở hữu những kỹ năng đó, anh ta không thể có hiệu quả trong công việc kiểm thử của mình. Người kiểm thử phải đã làm việc trong một lĩnh vực hoặc lĩnh vực kỹ thuật cụ thể cùng với công cụ đang được sử dụng cho dự án cụ thể đó trong nhiệm vụ trước đó của mình. Nhưng nó sẽ không giống nhau trong nhiệm vụ tiếp theo. Nó sẽ là một cái gì đó khác. Nó sẽ khá mới, một công nghệ mới, một công cụ mới, và một phương pháp cực kỳ mới. Trong một khoảng thời gian, nó đã được chứng minh rằng các Tester luôn có thể nhận được những kiến thức về lĩnh vực được yêu cầu cụ thể cho dự án, các công cụ và công nghệ đang được sử dụng trong dự án,và đã có thể thực hiện kiểm thử hiệu quả và cung cấp phần mềm tốt. Tester tốt: Mọi người thường tiếp tục hỏi ' Những phẩm chất của một Tester tốt là gì ? Làm thế nào tôi có thể trở thành một Tester tốt '? Làm thế nào tôi có thể giới thiệu rằng tôi là một Tester tốt ?? Nó không chỉ dựa trên phương pháp kiểm thử , quá trình thiết kế kiểm thử, thực thi test,kiểm thử tự động hóa hoặc kiểm thử hiệu suất , nhưng một Tester cần biết về tất cả để làm cho anh ta / cô ấy một Tester tốt. Đó là văn hóa hoặc phẩm chất cơ bản mà người ta nên sở hữu, do đó sẽ được tăng cường bởi những học tập bên ngoài này, và do đó sẽ làm cho một người trở thành một người kiểm thử mạnh mẽ và giỏi. 'Điều gì làm cho bạn cảm thấy tốt hơn một Tester?' , Bạn làm gì từ sự chuyên nghiệp trong việc kiểm thử? Vâng, nó là gì, nhưng sự hài lòng của việc đạt được chất lượng, sự hoàn hảo, gọn gàng, vv, đảm bảo rằng bạn đã làm một số tốt cho khách hàng của bạn. Tôi sẽ không chỉ nói về những kỹ năng kỹ thuật cụ thể của dự án mà người ta phải sở hữu là một Tester tốt. Sở hữu những kỹ năng và kiến thức này là sự cần thiết và điều đó không làm cho cá nhân trở thành một Tester chuyên gia, nhưng nó sẽ chỉ làm cho một người trong nhóm Testers có thể hiểu được những điều cơ bản của dự án và thực hiện kiểmthử Do đó, thay vì chỉ học tập, những phẩm chất hoặc đặc điểm nhất định phải được xây dựng trong một cá nhân để trở thành một Tester tốt. Và tất nhiên nó là cái gì đó mà người ta không thể học hoặc được chứng nhận về những phẩm chất này từ các học viện nhưng người ta phải tự mình sở hữu một cách tự nhiên. Và sau đó những phẩm chất này sẽ được tăng cường với nhiều kinh nghiệm hơn. Vì vậy, bạn nghĩ gì tôi đang cố gắng viết về điều gì bây giờ? Tôi sẽ đề cập đến một số đặc điểm tính cách mà tôi gọi là 'Sức mạnh cốt lõi' để trở thành một người kiểm thử tốt. Theo tôi, bất kỳ kỹ năng nào bạn thêm vào chính mình như công nghệ kiểm thử, quy trình, công cụ và bất kỳ chứng chỉ nào như ISTQB , CSM, Agile Tester, v.v., bạn đính kèm với tên của bạn, không bao giờ có thể biến đổi bạn thành Trình kiểm thử 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. 'Sức mạnh cốt lõi' để trở thành một người kiểm thử tốt

Đặc điểm quan trọng đầu tiên và quan trọng nhất mà người ta phải sở hữu là Người kiểm thử vĩ đại là trở nên Đam mê về công việc mà chúng ta đang làm. Tôi tự hỏi có bao nhiêu người trong số họ trong số các Testers đã chọn vai trò của họ, sự nghiệp, nghề nghiệp như một Tester bởi sự lựa chọn ? Trừ khi người ta có niềm đam mê đối với kiểm thử, anh / cô ấy không thể tìm thấy động cơ chắc chắn trên cơ sở hàng ngày để làm công việc lặp đi lặp lại, lặp đi lặp lại, bất kể dự án, công nghệ, phức tạp và những người liên quan. Niềm đam mê là một đặc điểm, mà sẽ làm cho một Tester để khám phá nhiều hơn và nhiều hơn nữa trong việc xác định các vấn đề phần mềm. Niềm đam mê là điều duy nhất khiến họ không bao giờ hài lòng với kiến thức họ có và số lượng công việc họ đã làm và do đó nó làm cho họ làm hoặc học hỏi nhiều hơn và nhiều hơn nữa mọi lúc. Tôi nghĩ rằng đây có thể là sự so sánh tốt nhất mà tôi có thể đưa ra. Nó giống như nghề của bác sĩ. Nó không phải là tất cả những người đã đạt điểm cao trong các môn học và được xếp hạng cao nhất có thể nhận được vào lĩnh vực Y học. Đó là niềm đam mê mà sẽ làm cho một người nhận được vào nghề này. Hãy tưởng tượng tầm quan trọng của bệnh nhân nếu ai đó không có đam mê hoặc mong muốn làm việc của bác sĩ, hãy tham gia vào nghề đó? Tương tự như vậy cho đến khi và trừ khi người ta có một niềm đam mê để kiểm thử, anh / cô ấy không thể là một Tester tốt. Tôi sẽ cho bạn một ví dụ thể hiện niềm đam mê cho công việc họ làm. Điều gì khác có thể tốt hơn là tự trải nghiệm? Các ví dụ có thể lạ, nhưng nó là đáng nói. Và chắc chắn, chúng ta nên học hỏi từ ngày của chúng ta đến những diễn biến từ môi trường xung quanh. Quan sát và học hỏi từ mỗi và mọi điều nhỏ nhặt xảy ra trong cuộc sống của chúng ta cũng là chất lượng của một Tester. Ngay sau khi tôi thức dậy sớm vào buổi sáng, tôi đi đến ban công để tập yoga. Mỗi ngày tôi thấy một bà già, vào buổi sáng sớm trong những bước chân vội vã vội vã, với cái bộ quần áo của cô ấy buộc cao kéo từ trên xuống. Mỗi ngày tôi nhìn thấy cô ấy với giống như một cơn sốt và giống như tư thế của bộ quần áo trói lại. Sau đó tôi thấy rằng cô ấy là một người giúp việc gia đình, người giặt quần áo và dọn dẹp đồ dùng cho 3-4 ngôi nhà trong làn đường đó. Những gì tôi quan sát thấy trong cô ấy là niềm đam mê mà cô ấy dành cho công việc của mình. Cô không bao giờ bỏ lỡ công việc của mình ngay cả một ngày, cô không bao giờ bỏ lỡ thời gian của mình. Hãy tưởng tượng niềm đam mê và sự chuẩn bị của cô cho công việc mà cô sẽ làm. Trong khi đi bộ trên đường phố, ngay cả trước khi đến chỗ làm việc của mình, cô đặt mình để bắt đầu rửa và làm sạch công việc của mình với bộ quần áo của mình gắn lên. Tôi thực sự thích niềm đam mê mà cô ấy dành cho công việc của mình. Bạn không nghĩ rằng niềm đam mê đánh thức cô ấy mỗi ngày vào sáng sớm để đi làm?

Tôi có một ví dụ khác sẽ giải thích sự vắng mặt của niềm đam mê đối với công việc. Đây là khi một người được thực hiện để lấy nghề mà không có bất kỳ mong muốn và niềm đam mê cho nó. Một người bạn của tôi đã trở thành một bác sĩ vì áp lực từ gia đình của anh ấy. Để duy trì tình trạng gia đình của mình, ông đã lên ngành y tế và với rất nhiều cuộc đấu tranh, ông hoàn thành bằng y khoa của mình Khi ông bắt đầu thực hành y tế của mình, ông không bao giờ có bất kỳ niềm đam mê để làm công việc đó và thấy nó rất nhàm chán sau một thời gian. Nhưng anh ấy rất quan tâm đến việc kinh doanh, sau đó anh rời bỏ nó và chuyển sang làm kinh doanh, đó là niềm đam mê của anh. Bây giờ anh ấy đang làm rất tốt và cũng khá hạnh phúc. Vì vậy,khi người ta không có niềm đam mê cho công việc của họ, họ không thể phát huy hết sức mình. Tôi sẽ nói rằng, để thực hiện kiểm thử, đặc biệt là một kiểm thử chất lượng, một trong những chắc chắn nên có niềm đam mê đối với nghề nghiệp và công việc mà họ hàng ngày. Làm thế nào để bạn là người kiểm thử đam mê? Niềm đam mê để kiểm thử và thái độ về chất lượng sẽ đi vào dây thần kinh Testers, máu của họ, và vào DNA của họ nữa. Niềm đam mê xuất sắc là những gì sẽ làm cho một cá nhân, một Tester mạnh mẽ. Niềm đam mê giữ cho luôn tỉnh táo và giữ cho mắt mở rộng để biết chi tiết. Niềm đam mê giữ cho chúng hoạt động và tương tác. Niềm đam mê để kiểm thử làm cho Tester để có được kiểm thử thử bất cứ nơi nào họ đi và bất cứ điều gì họ nhìn thấy

Sáng tạo và đổi mới thường được gọi là 'suy nghĩ ra khỏi hộp' 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 của kiểm thử là gì nếu một người chỉ thực hiện kiểm thử bất cứ điều gì được mã hóa? Làm thế nào sẽ có một khiếm khuyết về chất lượng, nếu anh ta / cô ấy chỉ kiểm thử bất cứ điều gì đã được chăm sóc rồi? Vì vậy, đó là tính cách của sự sáng tạo và tư duy đổi mới khiến cho một người kiểm thử suy nghĩ ra khỏi hộp và thu thập ý tưởng để thiết kế các kiểm thử và kịch bản sống động, thường có thể không được đề cập trong khi coding. Đó là sự sáng tạo giúp Tester cung cấp phản hồi về việc nâng cao sản phẩm và giúp sản phẩm giành được vị trí tốt hơn trên thị trường bằng cách nổi bật hơn các sản phẩm tương tự khác. Người kiểm thử có thể suy nghĩ và trực quan hóa sản phẩm chỉ bằng các chi tiết được cung cấp thông qua các yêu cầu và do đó chúng phải khá sáng tạo và có thể tách sản phẩm bằng cách xác định các gaps trong sản phẩm và giới thiệu mức độ hiệu quả của sản phẩm và thậm chí chứng minh nó bằng cách xác định các cách để lạm dụng nó. Đó là ý tưởng sáng tạo của Tester để tận dụng tốt nhất sự kết hợp của các công cụ 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ọ, nhằm đạt được mục tiêu Kiểm thử bằng cách giảm chi phí và do đó tăng tốc độ ra thị trường cùng với các khía cạnh chất lượng. Với sự thay đổi trong phạm vi vai trò của Tester, trách nhiệm của Tester không chỉ là để tìm ra khiếm khuyết mà còn để tăng giá trị cho sản phẩm, thêm giá trị cho khách hàng và doanh nghiệp của mình. Vì vậy, để làm được điều này cần phải được khá sáng tạo,đổi mới, luôn luôn suy nghĩ ra khỏi hộp và suy nghĩ độc đáo. Một người kiểm thử có thể nghĩ ra điều gì đó vượt quá mức suy nghĩ của một người bình thường. Phải đi xa hơn điểm suy nghĩ chung, hãy tưởng tượng nhiều kịch bản có thể xảy ra trong thực tế, và đặt ra câu hỏi cho chính họ như thế nào nếu nó như thế này? và nếu đó là trường hợp? vv, dựa vào tình hình.

Khía cạnh quan trọng tiếp theo của vai trò của Tester là khả năng 'đặt mình vào vị trí của khách hàng'. Tôi biết nó rất dễ nói, nhưng thực sự khá khó khăn để trải nghiệm cảm xúc và diễn biến bằng cách ở trong tình huống của người khác, đặc biệt làđóng vai trò người dùng cuối hoặc khách hàng. Đứng trong chiếc giày của khách hàng, suy nghĩ làm thế nào một khách hàng sẽ sử dụng sản phẩm do chúng tôi phát triển trong cuộc sống thực của họ và để hiểu được kỳ vọng của họ với tư cách khách hàng cuối thì khá là thách thức. Người ta không thể chỉ hiểu những gì đang chạy qua tâm trí họ. Nó luôn luôn là phổ biến để cảm thấy rằng sản phẩm của chúng tôi, sáng tạo của chúng tôi, đóng góp của chúng tôi và công việc của chúng tôi là tốt cho chính mình và khó khăn để tìm lỗi trong sản phẩm. Do đó để hình dung nếu phần mềm của chúng tôi đáp ứng được kỳ vọng của khách hàng, suy nghĩ trong dòng suy nghĩ của họ và làm một vai trò như một khách hàng là rất quan trọng đối với một Tester.

Luôn suy nghĩ về khách hàng, nghĩ rằng nếu tôi có thể kiểm thử nó theo cách tương tự như cách khách hàng sử dụng nó trong cuộc sống thực là nhiệm vụ lớn nhất cho Testers và mô phỏng các kịch bản tương tự là tốt nhất cho một Tester tốt. Có thể có nhiều loại người dùng khác nhau từ các khu vực địa lý khác nhau và các loại hồ sơ khác nhau sẽ sử dụng sản phẩm của chúng tôi và trong các trường hợp như vậy, sử dụng kỹ thuật 'kiểm thử 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. quan điểm người dùng cuối được kiểm thử. Do đó, nó là điều cần thiết cho một Tester để tương tác với người dùng cuối và thu thập càng nhiều kịch bản, và sử dụng các trường hợp càng tốt để kết hợp trong kiểm thử của họ.

Một Tester nên luôn có một kỹ năng hình dung rất tốt . Người kiểm thử cần hình dung trạng thái kết thúc của sản phẩm không được tạo ra, trong quá trình phát triển của nó. Anh / cô ấy cần phải hình dung các tính năng và bắt đầu suy nghĩ về hành vi của nó trong sản xuất và cách nó sẽ được sử dụng bởi người dùng cuối và tạo ra các kịch bản dựa trên đó.

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

Nó không những quan trọng để có một bức tranh lớn về sản phẩm mà còn rất cần thiết để có được những chi tiết nhỏ của sản phẩm và quan sát cẩn thận, hấp thụ nội dung và đưa thông tin đó vào đúng sử dụng trong khi kiểm thử. Do đó, là một Tester, người ta cần phải quan sát, suy nghĩ và phân tích sâu sắc.

Eye for detail là một đặc tính quan trọng khác của một Tester. Niềm tin của tôi là, trừ khi người ta tìm hiểu sâu hơn về chủ đề và khám phá ngày càng nhiều điều về sản phẩm, không thể hiểu sản phẩm một cách kỹ lưỡng và thực hiện kiểm thử kỹ lưỡng và do đó là 'quan sát chi tiết', rất quan trọng đối với Bộ kiểm thử để khai thác tất cả các gaps sản phẩm và xác định các khuyết tật ẩn.

Tôi cũng nên thêm ‘Nghe chi tiết' và nói 'Quan sát và nghe chi tiết'. Mắt để biết chi tiết cũng sẽ mang lại sự rõ ràng hơn về chủ đề này. Chi tiết từng phút của sản phẩm rất quan trọng đối với khách hàng. Nếu bất cứ ai nghĩ rằng điều này không quan trọng và không cần phải chú ý nhiều, thì họ đã đi sai. Vì vậy, chú ý và quan tâm đến từng chi tiết của sản phẩm là khá quan trọng.

Khi nói đến việc xác định các sai sót hoặc khuyết tật hoặc gaps trong sản phẩm, 'đang bị nghi ngờ' (ha..ha..ha ..), nghĩa đen sẽ giúp bất kỳ Tester nào đạt được mục tiêu kiểm thử của họ. Tôi đã có rất nhiều trường hợp trong khi bàn giao xây dựng cho Tester, nhà phát triển sẽ nói 'vâng, lỗi đã được sửa và nó hoạt động tốt'. Nhưng khi một Tester được đưa vào kiểm thử thực tế, chúng ta có thể nhận thấy rằng đôi khi, lỗi chính nó không cố định, hoặc một phần cố định hoặc đôi khi nó sẽ làm phát sinh một số khiếm khuyết khác do ảnh hưởng của nó. Ở đây, tôi không nói rằng các nhà phát triển đang nói dối hoặc gian lận, nhưng bằng cách nào đó nó giống như thế này trong nhiều tình huống. Do đó, như đã đề cập, đặc tính của Người kiểm thử là sự nghi ngờ và không tin bất cứ điều gì trừ khi họ kiểm thử và chứng minh rằng nó hoạt động tốt. Vì vậy, hãy nghi ngờ. Không bao giờ đồng ý hoặc giải quyết cho một cái gì đó được nói. Là đáng ngờ và tò mò sẽ luôn luôn thêm giá trị cho các kiểm thử sản phẩm và do đó sẽ phản ánh các đặc điểm tốt nhất của một Tester.

Lý luận và đặt câu hỏi là một đặc điểm quan trọng khác mà một Tester nên có để chứng tỏ là một Tester hiệu quả. Chỉ người thực sự hiểu chủ đề mới có thể đặt câu hỏi và người hỏi câu hỏi hay hơn cũng được coi là thông minh. Bất kể đó, lý luận và đặt câu hỏi, trong trường hợp này, cho phép một Tester hiểu nếu thực hiện bởi họ là lựa chọn tốt nhất hoặc nếu có bất kỳ tùy chọn nào khác có sẵn.

Không chỉ vậy, như đã đề cập trước đó, đặt câu hỏi giúp hiểu rõ hơn về sản phẩm và cũng hiểu được tại sao giải pháp cụ thể đó đã được triển khai, ngoài nhiều tùy chọn có sẵn khác. Trong trường hợp như vậy, một Tester có thể tiếp tục mở rộng bản thân để suy nghĩ vượt ra ngoài mọi người và đi ra với ý tưởng tốt hơn và rẻ hơn mà không ai nghĩ đến cho đến nay. Chúng ta cũng biết nguyên tắc 5 why của việc tìm ra nguyên nhân gốc rễ . Điều này chắc chắn sẽ giúp Trình kiểm thử truy cập vào thư mục gốc của sự cố và sau đó xác định xem sự cố tương tự có tồn tại ở bất kỳ khu vực nào khác của sản phẩm hay không. Những người kiểm thử nên luôn luôn lý luận về bất cứ điều gì mà họ nghe để hiểu rõ hơn và quá chi tiết. Đôi khi thậm chí tự hỏi bản thân cũng sẽ giúp ích rất nhiều. Tại sao một trong những thiết kế như thế này và tại sao không như thế này? Con đường quan trọng là gì? Giải pháp tối ưu hóa là gì? Một Tester nên có sự nhiệt tình để hiểu được trong và ngoài của sản phẩm, vượt ra ngoài phạm vi của kiểm thử để xác định các vấn đề thực sự trong sản phẩm. Vài lần, tôi đã nhận thấy các nhà phát triển hoặc quản lý phát triển ra lệnh cho nhóm kiểm thử khi có một cuộc khủng hoảng thời gian, và nhóm nghiên cứu đã sửa lỗi nghiêm trọng, nói rằng 'chỉ cần chạy những trường hợp kiểm thử này, nó là đủ'. Hỏi họ tại sao? Hiểu lý do tại sao lỗi cụ thể đó xảy ra và họ đã làm gì để sửa lỗi đó. Trung thực, một Tester tốt sẽ không ngủ một cách hòa bình, trừ khi tất cả các nghi ngờ được xóa ra gốc. Khi tôi nói điều này, tôi cũng muốn đề cập đến những người kiểm thử rằng họ không bao giờ nên chịu áp lực của các nhà phát triển và người quản lý phát triển hoặc bất kỳ ai khác trong nhóm. Đó là trách nhiệm của họ để phân tích kỹ lưỡng và quyết định những gì được yêu cầu để được kiểm thử, thay vì để nó cho người khác để ra lệnh Testers.

Rõ ràng, 'bảo vệ chất lượng' , là chất lượng tốt nhất và được uỷ quyền nhất của người kiểm thử.

Chúng tôi biết có rất nhiều tình huống mà một Tester sẽ gặp phải dưới áp lực thỏa hiệp trong quá trình kiểm thử, hoặc bằng cách không cung cấp đủ chi tiết khi câu hỏi được hỏi hoặc cắt giảm phạm vi kiểm thử, thỏa hiệp trong trường hợp công cụ, v.v. Trong những trường hợp như vậy, tốt nhất là nên đặt chân xuống, hãy để những gì có thể đến và chỉ làm công lý với chất lượng mà không bị ảnh hưởng.

Tôi đã quan sát thấy trong vài tổ chức, nơi mọi người bỏ qua những lời của Test Manager hoặc nhóm Test và tự quyết định về kiểm thử. Nhưng nếu quyết định đó trong bất kỳ cách nào dẫn đến việc làm tổn hại đến chất lượng, như một người kiểm thử giỏi, thì người ta không bao giờ nên chấp nhận điều đó. Vì vậy, việc bảo vệ chất lượng của sản phẩm cuối cùng trở thành trách nhiệm của Tester, mặc dù nó được hình thành và được xây dựng bởi toàn bộ nhóm. Nó trông rất đơn giản, nhưng không ảnh hưởng đến chất lượng, là một nhiệm vụ rất khó khăn trong thực tế. Khi mọi thứ được hoàn thành, nhóm nghiên cứu 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, việc bảo vệ chất lượng đối với các quyết định cuối cùng như vậy để thực hiện các thay đổi đối code sẽ trở thành trách nhiệm của Tester. Khi chúng ta sử dụng từ 'bảo vệ', nó có nghĩa là rất nhiều. Nó không chỉ là kiểm thử phần mềm và phát hiện lỗi, mà còn đảm bảo chất lượng tổng thể của phần mềm ở mọi giai đoạn của sản phẩm và quan sát nghiêm túc nếu có bất kỳ sự cố nào xảy ra hoặc bất kỳ quyết định nào của các bên liên quan làm tổn hại đến chất lượng và chống lại các quyết định đó. Đi thêm một dặm để duy trì chất lượng được gọi là 'bảo vệ chất lượng'.

Là " hung hăng" trong việc đưa ra quyết định là một đặc tính khác của Tester. Đã giải thích các tình huống trên, nơi mà các Tester chịu áp lực làm ảnh hưởng đến việc kiểm thử và không thể thực hiện đủ kiểm thử. Tôi sẽ nói rằng Testers cần phải tích cực trong việc đưa ra quan điểm, quyết định của họ, trong việc thể hiện suy nghĩ của họ, nếu không, nó chắc chắn sẽ bị bỏ quên và cuối cùng dẫn đến chất lượng kém của phần mềm. Khi một Tester cố gắng thiết lập rằng lỗi là rất quan trọng, thì không ai muốn chấp nhận nó trong trường hợp đầu tiên. . Tại một thời điểm như vậy, Tester cần phải tích cực trong việc đưa ra những suy nghĩ của họ. Người kiểm thử không nên có thái độ từ bỏ các quyết định của người khác trừ khi họ đánh giá tính quan trọng của quyết định. Nhiều lần, với mong muốn cung cấp hoặc đáp ứng timeline, các bên liên quan khuyên bạn nên cắt giảm phạm vi kiểm thử và khuyên bạn nên chỉ kiểm thử một khu vực cụ thể của phần mềm trong trường hợp sửa lỗi hoặc chỉ đủ nếu các trường hợp kiểm thử này được chạy. Nó luôn luôn là tốt để có đầu vào nhưng không nên bị ảnh hưởng bởi quyết định của bất kỳ khác. Do đó Tester cần phải rất tích cực trong khi đưa ra quyết định như vậy. Bất cứ khi nào nhóm QA gửi kế hoạch và lịch trình kiểm thử của họ và cố gắng truyền đạt rằng thời gian có sẵn cho họ là không đủ để thực hiện kiểm thử, thì chi tiết kế hoạch và ước tính của họ là mọi người cố gắng đẩy nó xuống. Vì vậy, trong trường hợp như vậy, Tester trải qua một sự thúc đẩy mạnh mẽ trong việc thực hiện các hoạt động kiểm thử một cách thoải mái. Trong kịch bản như vậy, nếu đội QA có thể trình bày điểm của họ một cách mạnh mẽ thì sẽ có khả năng thay đổi trong các quyết định trong toàn bộ đội.

Việc truyền đạt thông tin được yêu cầu một cách hiệu quả là chất lượng thiết yếu cơ bản của một Tester. Một Tester là cần thiết để làm việc với các bên liên quan khác nhau trên toàn cầu ở các giai đoạn khác nhau của vòng đời phát triển phần mềm và do đó nó là điều cần thiết để thể hiện và trình bày chính xác thông tin, với sự rõ ràng và không tạo ra bất kỳ sự nhầm lẫn nào. Chúng tôi tiếp tục nghe rằng khi một lỗi từ cuộc sống trở lại và tấn công nhóm QA, mọi người bắt đầu đổ lỗi cho nhóm QA, nói rằng 'tại sao lỗi này đơn giản không được phát hiện trong quá trình kiểm thử'? Nó là khá thường xuyên rằng cùng một khiếm khuyết đã được báo cáo trước đó và nhóm nghiên cứu đã không được ưu tiên đủ để có nó nghiêm túc và sửa chữa nó. Có vấn đề gì? QA không trình bày rõ ràng hoặc giải thích và dự đoán độ ảnh hưởng của defect một cách phù hợp với các bên liên quan? và không hiệu quả trong việc giao tiếp mức độ nghiêm trọng của vấn đề và thuyết phục nhóm? Vì vậy, cùng với giao tiếp, đó là khả năng để nói rõ mọi thứ và ảnh hưởng đến nhóm để đồng ý với quan điểm của họ, đó là điều quan trọng cần thiết cho một Tester.

Khi tôi nói một Tester cần giỏi về giao tiếp, người đó không cần phải là người được giải Nobel tiếng Anh nhưng ít nhất phải có khả năng giao tiếp rõ ràng và hiệu quả những gì họ cảm thấy, bằng lời nói hoặc thông qua tài liệu bằng văn bản. Nếu người ta không thể đưa ra ý nghĩa rõ ràng của nội dung một cách dễ hiểu, thì toàn bộ mục đích của việc kiểm thử hoặc xác định khiếm khuyết nghiêm trọng và có khả năng truyền đạt rằng nó là rất quan trọng sẽ bị đánh bại. Sự giao tiếp có thể đơn giản như giải thích mô tả lỗi, viết chuỗi sự xuất hiện của lỗi hoặc giải thích cho nhóm về rào cản, nhóm kiểm thử bị kẹt với việc không thể tiếp tục. Đồng thời, một Tester cần phải nhận thức khá rõ rằng giao tiếp kém và không hiệu quả sẽ dẫn đến nhiều nhầm lẫn và dẫn đến chất lượng kém. Nói chung, các nhà phát triển không thích trưng bày các lỗi nghiêm trọng trong mã của họ, vì vậy vấn đề ở đây là khả năng của một Tester để truyền đạt và thuyết phục rằng có một lỗi trong mã của bạn theo cách chiến thuật. Trong khi truyền đạt những khiếm khuyết cho nhóm phát triển, không nên có một màn trình diễn cảm giác rằng, ' Tôi đã tìm thấy khuyết điểm trong công việc của bạn hoặc bạn đã phạm sai lầm', từ đó sẽ dẫn đến vấn đề cái tôi trong đội. Điều này được yêu cầu như một người giao tiếp tốt. Vì vậy, Chuyển tải bất kỳ âm bản nào theo cách khách quan sao cho không có cá nhân nào đi vào chế độ tấn công bằng cách giải thích rõ ràng tác động của tình huống là khá quan trọng. Một người kiểm thử nên luôn luôn giữ sự quan tâm của dự án trong tâm trí trong khi truyền tải bất cứ điều gì mà không làm nổi bật sai lầm của một cá nhân. Trong trường hợp này, chúng ta có thể mở rộng định nghĩa về kỹ năng giao tiếp nhiều hơn một chút cho Tester về kỹ năng viết, trong đó Tester trong dự án cần ghi lại những thứ nhất định với độ rõ ràng hơn, như Readme, Hướng dẫn sử dụng, tạo báo cáo ý nghĩa tóm tắt kiểm thử, v.v.

Nói chuyện trong nhóm và làm cho giọng nói của bạn được nghe là một đặc điểm quan trọng khác của một Tester. Nó có thể là một cuộc họp đánh giá hoặc một bài thuyết trình kỹ thuật hoặc đơn giản như một tập hợp để truyền đạt quyết định cho các Testers, để gọi họ làm việc vào cuối tuần hoặc về việc trình bày một lịch trình dự án. Trong các cuộc họp đó, một Tester sẽ có thể đứng lên trong nhóm, trình bày rõ ràng điểm của họ và có thể làm cho giọng nói của họ được nghe bằng cách đảm bảo rằng họ thực sự hiểu những gì nó thực sự cần để kiểm thử, thách thức của họ là gì và hậu quả là gì nếu không được kiểm thử kỹ lưỡng và có thể ảnh hưởng đến việc đảo ngược các quyết định.

Phải mất rất nhiều thời gian và công sức để một cá nhân hiểu sâu sắc về chủ đề này và trừ khi một người là một người lao động chăm chỉ, rất khó để trở thành một người kiểm thử giỏi. Khía cạnh làm việc chăm chỉ của một Tester không cần nhiều lời giải thích.

Người kiểm thử không nên chỉ xác định các khuyết điểm và ném tất cả các vấn đề khác của dự án ra khỏi tường cho các nhà phát triển. Nó là khá quan trọng đối với các Testers để giúp toàn bộ đội trong việc' giải quyết vấn đề' hoặc ít nhất là đề xuất các giải pháp khả thi cho các vấn đề.

Khi một QA có kỹ năng giải quyết vấn đề, các bên liên quan và mọi người khác trong nhóm muốn tìm kiếm họ với nhân phẩm và tầm quan trọng và sẽ liên hệ với họ để đưa ra đề xuất của họ trong trường hợp có bất kỳ vấn đề hoặc vấn đề nào. Vì vậy, nếu một QA bắt đầu phân tích các vấn đề và làm việc với nhóm để giải quyết vấn đề, vai trò QA trong dự án không chỉ trở nên quan trọng mà còn khá thú vị nữa.

Người kiểm thử cần phải là ' người không ngừng học hỏi' và nên tự cập nhật bằng cách liên tục học hỏi, công nghệ và diễn biến mới trên toàn cầu, từ đó sẽ giúp họ thực hiện vai trò Kiểm thử theo cách tốt hơn và giúp họ nổi bật đội. Hãy để nó trở thành kiểm thử chức năng, phi chức năng, tự động hóa, học ngôn ngữ mã hóa, học máy, kiểm thử tự động dựa trên AI, kiểm thử dịch vụ vi mô, v.v ... và tìm hiểu bất cứ thứ gì đi theo cách của họ. Việc học tập này giúp họ sáng tạo, sáng tạo hơn và giúp giải quyết các vấn đề và thực hiện các ý tưởng và giải pháp mới. Sở hữu kiến thức nhiều giúp họ trong việc đưa ra quyết định đúng đắn.

Nó không chỉ là học hỏi kỹ thuật hay công nghệ mới hay một quá trình mới, mà còn học hỏi từ những sai lầm trước đó, không chỉ từ những sai lầm của chính họ mà còn từ những sai lầm của người khác nữa. Không ngừng học hỏi từ những người khác, học hỏi từ mọi thứ mà họ thấy, là chất lượng tốt nhất của Tester.

Việc ' đón nhận sự thay đổi và thích ứng linh hoạt' là một đặc điểm quan trọng khác của một Tester. Chúng ta biết rằng một sự thay đổi là không thể tránh khỏi và luôn luôn là tốt. Một người kiểm thử nên cởi mở và chấp nhận được với những thay đổi trong phạm vi, những thay đổi trong thiết kế (vài lần), những thay đổi về kiến trúc, những thay đổi trong công cụ, công nghệ hay bất cứ thứ gì khác. Bất cứ điều gì có thể thay đổi, một Tester nên chấp nhận những thay đổi đó và thích ứng nhanh chóng với sự thay đổi và thực hiện công việc kiểm thử một cách trung thực mà không có bất kỳ khiếu nại nào.

Người kiểm thử phải đủ linh hoạt để chấp nhận nhận xét từ các bên liên quan về lĩnh vực công việc của họ, có thể là đề xuất được cung cấp để cải thiện, phạm vi tự động hóa, số liệu lỗi, báo cáo kết quả kiểm thử, phân loại lưu trữ hoặc bất kỳ thứ gì khác. Họ nên cởi mở để chào đón bất kỳ loại thay đổi hoặc gợi ý nào và liên tục học hỏi và cải thiện. Một người kiểm thử nên được mở để làm việc với nhóm Phát triển với sự kiên nhẫn, giúp họ mô phỏng các defect, ngoài việc cung cấp các mô tả lỗi và ảnh chụp màn hình trong thời gian báo cáo lỗi .

Người kiểm thử phải là 'làm việc nhóm tốt' . Anh ấy có thể liên tục làm việc chặt chẽ với nhóm, học hỏi từ họ và cũng giúp những người khác học hỏi từ bản thân. Người kiểm thử cần làm việc cùng với nhóm trong việc xác định các vấn đề trong sản phẩm, giới thiệu họ với nhóm một cách tốt hơn và giúp họ giải quyết nhanh chóng.

Một Tester cần đứng cho toàn bộ nhóm khi một lỗi hoặc lỗi được xác định và hỗ trợ mọi Tester khác trong tất cả các giai đoạn với nhau trong một nhóm. Là một Tester, bất kỳ vấn đề hoặc vấn đề nào nên được sở hữu bởi toàn đội thay vì đổ lỗi cho một người. Như chúng ta biết, một cá nhân có thể đạt được nhiều hơn trong một tinh thần đồng đội hơn là độc thân.

Duy trì 'tính kỹ lưỡng, chính xác và rõ ràng' trong mọi thứ mà họ làm là một đặc điểm quan trọng của một Tester.

Trừ khi họ có đặc điểm này, chất lượng toàn bộ của một sản phẩm không thể được đảm bảo và bất kỳ công việc nào sẽ không bao giờ hoàn thành kiểm thử và không thể đảm bảo chất lượng tổng thể. . Nó giống như một kỳ thi của trường, và chúng tôi không biết câu hỏi nào sẽ đến và từ đâu. Tương tự như vậy, chúng tôi không biết một lỗi phần mềm sẽ đến từ đâu nếu chúng tôi chưa được kiểm thử nó.

' Văn hóa cộng tác ' là từ thông dụng chính của DevOps. Với sự ra đời của DevOps, việc hợp tác với tất cả các bên liên quan, đặc biệt đối với một Tester là hết sức quan trọng.

Việc hợp tác cũng giúp ưu tiên các hoạt động kiểm thử và các kịch bản kiểm thử dựa trên các tương tác, các cuộc thảo luận mà một Tester sẽ có với các bên liên quan khác và giúp giảm chi phí kiểm thử và do đó cải thiện chất lượng.

Một tiêu chí quan trọng khác để mọi người trở thành một người kiểm thử giỏi là trở thành một ' người nghe giỏi' . Là một Tester, người ta cần lắng nghe cẩn thận và diễn giải một cách chính xác bằng cách lắng nghe người khác. Họ cần thu thập rất nhiều ý tưởng và kiến thức về sản phẩm và cách thức nó sẽ được sử dụng trong thời gian thực bằng cách đơn giản lắng nghe người khác.

Một người kiểm thử cần hiểu vấn đề thực sự của khách hàng, điều này là tiềm ẩn và một khách hàng có thể thấy khó chuyển đổi nó thành các yêu cầu của dự án và ghi lại chúng. Vì vậy, một Tester nên có thể đọc được suy nghĩ của khách hàng và hiểu chúng một cách kỹ lưỡng bằng cách lắng nghe chúng.

Khi có một bản phát hành quan trọng và nếu nhóm kiểm thử đã được yêu cầu đến vào cuối tuần để thực hiện vòng kiểm thử cuối cùng và mọi người đã đồng ý đến. Sau đó, phân bổ công việc được thực hiện trong số đó.

Hãy tưởng tượng đột nhiên nếu một ai đó trong số những người đã đồng ý đến hoặc là sự chậm trễ trong việc bắt đầu công việc và thậm chí không thông báo rằng họ không thể đến ?? Hãy suy nghĩ về tác động của tình hình. Lịch trình cùng với chất lượng là một dấu hỏi lớn. Vì vậy, với tư cách là người kiểm thử nên có trách nhiệm rõ ràng về công việc và kịp thời của họ và cần phải hiểu sự phụ thuộc vào họ. Họ cần phải ghi nhớ rằng công việc của họ là ở phần cuối của bản phát hành và kéo dài nó sẽ ảnh hưởng đến toàn bộ lịch trình dự án.

Cuối cùng nhưng ưu tiên khôn ngoan đầu tiên, là ' cam kết mà một Tester nên có đối với khách hàng và quan tâm của họ. Nó luôn luôn là rất quan trọng đối với một Tester để giữ cho khách hàng trong tâm trí trong suốt cuộc hành trình của họ về việc phân phối phần mềm. 'Trải nghiệm khách hàng' và 'sự hài lòng của khách hàng' nên là chìa khóa cần có trong tâm trí Người kiểm thử. Chỉ có suy nghĩ này và không thỏa hiệp về tư duy này sẽ làm cho sản phẩm thành công.

Trong những tình huống mà bất kỳ sự thỏa hiệp nào phải được thực hiện do bất kỳ hoàn cảnh không thể tránh khỏi nào thì trách nhiệm của Tester là liên lạc với khách hàng, thông báo cho họ rõ ràng và chấp nhận thỏa thuận đang xảy ra. Người kiểm thử cần phải biết, điều gì làm cho khách hàng hài lòng và điều khiến họ khó chịu. Họ cần phải hiểu rõ mục tiêu kinh doanh của họ là gì và nơi nào cần tập trung khi đạt được chúng. Phần kết luận Đây là những đặc điểm mà trở thành thước đo cho một Tester để trở thành một Tester tốt . Nó giúp rất nhiều trong việc xác định ' Chỉ số Chất lượng ' của một Tester. Hiện nay rất rõ ràng rằng kiểm thử phần mềm không chỉ là tìm ra khiếm khuyết mà còn vượt ra ngoài yêu cầu và vì thế, bất cứ phẩm chất nào cần phải là một Tester tốt phụ thuộc vào 'các giá trị cốt lõi' của Testers họ sở hữu. Nếu một người không có những kỹ năng cốt lõi / điểm mạnh chính hoặc ' Chỉ số Chất lượng ' thì bất cứ việc đào tạo bên ngoài hoặc chứng chỉ nào họ thêm vào sẽ không đưa họ đến đâu cả.

Refer https://www.softwaretestinghelp.com/quality-quotient-of-tester/