Slide Nhóm 12

Mọi người vào nhận xét, góp ý giúp chụy em tớ phát nào :v

Slide 12/23

Nghề test k có tuổi nghĩa là như thế nào?
(Phải chăng trẻ em, người già cũng có thể làm? )

Admin đã viết:Slide 12/23

Nghề test k có tuổi nghĩa là như thế nào?
(Phải chăng trẻ em, người già cũng có thể làm? )

Cảm ơn câu hỏi của bạn!
Tại sao nói nghề tester không có tuổi, có thể ví nghề tester - gừng càng già càng cay, vì thực tế cho thấy: nghề lập trình thường chỉ sung sức ở độ tuổi khoảng từ 23-30. Còn nghề tester khi càng làm lâu năm thì bạn lại càng có kinh nghiệm hơn, càng hứng thú hơn, nếu như 1 tester mới đi làm thì có khi mấy tháng mới log được 1 vài lỗi, còn 1 tester làm lâu năm thì lại khác: gần như họ cứ động vào là tìm ra lỗi vì dựa vào kinh nghiệm làm của mình họ dự đoán những vùng có nguy cơ xảy ra lỗi cao để tập trung test. chính vì thế nên càng làm càng sung sức chứ không có độ tuổi sung sức như lập trình viên.

nhóm bạn cho mình hỏi là: trong một dự án, có bao giờ các Tester không được các PM(Project Manager) coi trọng bằng Developer ko?

mình nghe nói: khi có dự án thì có một số PM ko cho Tester đọc Requiment ngay từ đầu mà phải khi nào dự án gần kết thúc các Dev xong việc thì mới cho đọc Requiment. Vật theo nhóm bạn quan điểm trên là đúng hay sai, và tại sao?

Làm tester thì có nhất thiết cần biết lập trình không?

Theo nhóm bạn thì các Developer và Tester trong một dự án có hay xảy ra xung đột ko? Nếu có thì làm sao để giải quyết vấn đề trên?

thjnhqwerty đã viết:nhóm bạn cho mình hỏi là: trong một dự án, có bao giờ các Tester không được các PM(Project Manager) coi trọng bằng Developer ko?

Cảm ơn câu hỏi của bạn!
Nếu PM coi trong Dev hơn Tester thì đấy là một quan niệm sai lầm, Tester vô cùng quan trọng, có thể nói đây là khâu sống còn của việc phát triển sản phẩm phần mềm. Hai chứ "Kiểm định nghe có vẻ đơn giản, nhàm chán nhưng khâu này giúp cho sản phẩm được hoàn thiện nhằm đáp ứng yêu cầu của khách hàng. Sản phẩm hoàn thiện, chất lượng cao sẽ tạo thêm niềm tin và uy tín của công ty với đối tác. Nế không có khâu này, tình trạng trả sản phẩm về xảy ra thường xuyên. Chính vì vậy, tester là vị trí không thể thiếu và công việc này quyết định khác nhiều vào sự thành công của dự án.
Tester là người đầu tiên và cuối cùng tiếp xúc với khách hàng. Nên có thể nói Tester đại diện cho " Bộ mặt, Bộ lão" của công ty.
Nói như vậy để thấy tầm quan trọng của tester.

jerry130495 đã viết:Làm tester thì có nhất thiết cần biết lập trình không?

Cảm ơn câu hỏi của bạn!
Công việc nào cũng có nhiều vị trí và Tester cũng vậy. Để làm tốt công việc Tester thì bạn cần thông thạo ít nhất 1 ngôn ngữ lập trình: để bạn kiểm tra mã nguồn của các lập trình viên, bạn có thể kiểm thử hộp trắng, code công cụ test... và bạn tiếp cận với công việc dễ dàng hơn.
nếu như không biết 1 ngôn ngữ nào cả thì công việc của bạn lại khác mức lương cũng khác.

thjnhqwerty đã viết:Theo nhóm bạn thì các Developer và Tester trong một dự án có hay xảy ra xung đột ko? Nếu có thì làm sao để giải quyết vấn đề trên?

Cảm ơn câu hỏi của bạn!
Trong thực tế: 1 thằng làm- 1 thằng soi: Không tránh khỏi những khó chịu đôi khi là xung đột với nhau. thường nguyên nhân xung đột là khi phần mềm có lỗi. Tester có bằng chứng lỗi của tester, Dev có cơ sở của Dev. Có thể hai người cùng đúng. Vì đôi khi do góc cạnh nhìn của 2 người là khác nhau.
VD: Cái nhìn về chất lượng sản phẩm: - Dev: nhìn từ người sản xuất: chất lượng là đáp ứng được chức năng của bản đặc tả yêu cầu.
- Tester: Nhìn từ người sử dụng: chất lượng là đáp ứng được nhu cầu của người sử dụng.
Nếu không giải quyết được với nhau thì có thể nhờ đến PM.

thjnhqwerty đã viết:mình nghe nói: khi có dự án thì có một số PM ko cho Tester đọc Requiment ngay từ đầu mà phải khi nào dự án gần kết thúc các Dev xong việc thì mới cho đọc Requiment. Vật theo nhóm bạn quan điểm trên là đúng hay sai, và tại sao?

Quan điểm trên là hoàn toàn sai.
Vì khi có dự án thì tester là người đọc Requiment để đặc tả yêu cầu phần mềm, tài liệu thiết kế cũng như kế hoạch dự án. Để đảm bảo được tiến trình dự án cũng như thiết lập kế hoạch kiểm thử để ngăn ngừa lỗi ngay từ đầu, vì nếu để đến gần kết thúc dự án mới bắt đầu kiểm thử thì để sửa lỗi lúc đó mất rất nhiều thời gian và tiền bạc.

Tester tìm ra lỗi nhưng người sửa lỗi lại là dev sửa lỗi vậy Tại sao không để dev kiểm thử luôn ?

Làm tester thì có cần biết lập trình không?

Phân vùng tương đương để làm gì?

Giải thích thêm về kiên định nhưng không cố chấp?

bạn ơi cho mình hỏi?
Sản phẩm của lập trình viên là phần mềm là hệ thống, vậy sản phẩm của tester là gì?

nambn0241 đã viết:bạn ơi cho mình hỏi?
Sản phẩm của lập trình viên là phần mềm là hệ thống, vậy sản phẩm của tester là gì?

cảm ơn câu hỏi của bạn!
Sản phẩm của tester chính là Bản testcase với kết quả kiểm quả test và những bằng chứng lỗi

bachkien510 đã viết:Tester tìm ra lỗi nhưng người sửa lỗi lại là dev sửa lỗi vậy Tại sao không để dev kiểm thử luôn ?

cảm ơn câu hỏi của bạn!
Tại sao mình không thể test sản phẩm mình làm ra?
Vì chúng ta thường giả định, thưởng để cảm xúc vào sản phẩm, hoặc quá quen thuộc với sản phẩm.
Ví dụ đơn giản như bài kiểm tra thường ngày của chúng ta, tại sao lại cần thầy cô chấm bài, chữa bài cho chúng ta mà chúng ta không thể tự làm.
Chính vì thế nên việc test phải được thực hiện bởi 1 người khác.

silverwhite đã viết:Phân vùng tương đương để làm gì?

cảm ơn câu hỏi của bạn!
Với một số điều kiện có thể thực hiện được chúng ta sẽ chia ra thành 2 vùng: vùng hợp lệ và không hợp lệ.
Các giá trị trong cùng 1 vùng thì cho ra kết quả giống nhau, vì vậy để giảm thiểu số lượng testcase, tiết kiệm thời gian mà vẫn đảm bảo được độ bao phủ test nên chúng ta sẽ phân vùng.

imstitch đã viết:           Giải thích thêm về kiên định nhưng không cố chấp?

cảm ơn câu hỏi của bạn!
Kiên đinh nhưng không cố chấp là một kỹ năng rất quan trọng của tester. Kiên định ở đây là mình phải kiên định với những bằng chứng lỗi mình đã có, tuy nhiên không được quá cố chấp vì có đôi khi cả 2 bên đều đúng, chỉ là do góc độ nhìn khác nhau nên khác nhau.
VD: Cái nhìn về chất lượng sản phẩm: - Dev: nhìn từ người sản xuất: chất lượng là đáp ứng được chức năng của bản đặc tả yêu cầu.
- Tester: Nhìn từ người sử dụng: chất lượng là đáp ứng được nhu cầu của người sử dụng.
Nếu không giải quyết được với nhau thì có thể nhờ đến PM.

cho t hỏi khi nào thì nên kiểm thử thủ công và khi nào nên kiểm thử tự động?

Các cậu nghĩ nghề này như thế nào? nó dễ hay khó? tại sao?

Trong kiểm thử tự động có các công cụ kiểm thử (testing tools). Nó có giống với Debuggers mà chúng ta hay dùng trong IDE ko? Mình đang lẫn lộn giữa 2 cái này

Trong Slide 10 có nói :Thông thạo ít nhất một ngôn ngữ lập trình
bạn có thể nói cho mình thông thạo 1 ngôn ngữ LT ở mức nào thì có thể làm Tester được?
nếu thông thạo rồi thì sao k theo lâp trình mà theo test?

Ở slide 16/23 mình thấy có 1 hình thức test là "Test Report" nhưng ko thấy nhóm bạn đề cập tới, bạn có thể cho mình biết "Test Report" là gì ? và nó có những đặc điểm ntn ko ?