Slide Nhóm 12

NguyenDucThang đã viết:"làm deverloper thì làm đc tester nhưng làm tester chưa chắc đã làm đc deverloper " câu này đúng k ạ ? nếu đúng thì các bạn hãy làm rõ ,nếu sai thì các bạn hay giải thích ạ?

Tớ xin trả lời là SAI. Làm dev chưa chắc đã làm đc test vì test k chỉ cần có kỹ năng chuyên ngành mà test cũng còn cần phải có đạo đức tốt và có sự cẩn thận, tỉ mỉ, tò mò, kiên nhẫn nữa.

ucto đã viết:Bạn có nghĩ rằng kiểm thử tự động có thể thay thế kiểm thử thủ công?

nhóm 12 xin trả lời:
nên nhớ kiểm thử tự đông k thể áp dụng 100%,Bởi vậy cho nên với nhiều trường hợp test k yêu cầu hồi quy,đặc điểm kỹ thuật luôn thay đổi thì tự động hóa k mang lại chút hiệu quả nào mà còn phản tác dụng => DO VẬY KHI ĐÓ PHẢI DÙNG ĐẾN KIỂM THỬ THỦ CÔNG

ucto đã viết:Có nên tham gia một khóa học tester hay tự học cũng được

Nên tham gia 1 khóa học tester bạn nhé

ucto đã viết:Tố chất của một người tester?

Để kiểm tra trực tiếp trên source code (mã nguồn) của các lập trình viên, các tester cần phải hiểu và
thông thạo ít nhất một ngôn ngữ lập trình. Vì thế kiến thức chuyên môn về lập trình là điều đầu tiên
cần có của một tester.
Bạn còn phải có được những kỹ năng thiết kế, lập trình, phân tích và hiểu biết về các ứng dụng khác
nhau của các phần mềm vì kỹ sư kiểm định phần mềm cũng giống như bác sĩ chẩn bệnh, phải nắm
vững kiến thức mới có thể chẩn đoán chính xác.
Ngoài ra, các tester cũng cần có trình độ tiếng Anh để đọc, hiểu, viết được tài liệu chuyên ngành, để
tiếp cận kiến thức mới của thế giới.
Do đặc trưng của nghề nên các tester phải có tính cẩn thận, tỉ mỉ, nhạy bén. Nếu đã qua khâu kiểm
tra mà sản phẩm vẫn bị lỗi, tester phải chịu trách nhiệm hoàn toàn.
Cuối cùng, "một kỹ sư kiểm tra chất lượng vừa phải có cái nhìn của người phát triển phần mềm,
vừa phải là người dùng đầu cuối", vì thế để trở thành tester giỏi cần phải phải học nhiều để có tầm
nhìn rộng, biết được xu hướng thị trường để tư vấn và đưa ra quan điểm của mình về sản phẩm.
Từ những liệt kê trên, nếu bạn thấy được những tố chất của mình phù hợp với nghề thì còn chờ gì
nữa, hãy đeo đuổi đam mê ngay từ bây giờ đi.

Nếu một người làm ra sản phẩm để người ngoài test thì mới biết được lỗi mà sửa chứ.còn để Dev kiểm tra chưa chắc đã đúng các yêu cầu mà nhà sản xuất đã đưa ra.
test đứng trên phương diện của nhà sản xuất hoặc là người dùng để xem có đủ ,đúng các yêu cầu chưa

ucto đã viết:Tại sao cần phải tester? ngày trước k có tester vẫn ok thế mà

-Tai vì con người k phải ai cũng nhận ra lỗi của mình mà sản phẩm chính là con đẻ của lập trình viên mà đã là con đẻ do mình tạo ra thì sẽ k thể đánh giá đc 1 cách khách quan và cũng k đủ dũng cảm để thừa nhận lỗi của mình vì thế nên cần phải có tester.
-chính vì ngày trước k có tester nên chất lượng sản phẩm mới k đc cao và phát triển

ucto đã viết:Cơ hội nghề nghiệp của nghề này?

nguoonf: http://sinhvienit.net/forum/nghe-tester-tiem-nang-va-co-hoi-lon-cho-sinh-vien-cong-nghe-thong-tin.374795.html
Nhu cầu tuyển dụng cao: Search trên Google từ khóa “tuyển dụng tester 2014” sẽ có kết quả 4,780,000 kết quả trong chưa đầy 0.21 giây.
Nghề nghiệp ổn định, thường xuyên được cập nhật những công nghệ mới và tiếp xúc với những dự án khác nhau, học được nhiều thứ mới lạ nên không nhàm chán.
Có quy định về nghề nghiệp và cơ hội thăng tiến rõ ràng: Tester càng nhiều kinh nghiệm càng được quan tâm và chú trọng.
Nghề Tester không có tuổi: Đối với nghề lập trình sự nhạy bén của tuổi trẻ rất quan trọng, nhưng đối với Tester thì kinh nghiệm tích lũy nhiều năm mới là điều quan trọng nhất.
Nếu Tester giỏi tiếng anh thì càng có cơ hội làm ở công ty phần mềm lớn với các dự án outsourcing của nước ngoài với mức lương cao 15-20tr, thậm chí còn có cơ hội đi làm tại các nước phát triển như Nhật, Mỹ, Canada…
Mức lương của một tester cao và ổn định: Với 1 tester mới từ 5-6tr, mức lương này sẽ tăng dần theo kinh nghiệm mà tester có, với tester cứng kinh nghiệm từ 4-6 năm mức lương có thể lên đến 12-15tr.

ucto đã viết:Một tester chuyên nghiệp cần những kỹ năng gì?

Nguồn: http://testerviet.com.vn/diendan/showthread.php?t=12355
Để thành công và trở thành một good tester thì bạn cần phải có 2 kỹ năng sau đây: techniques skill và soft skill. Tức là ngoài các kỹ thuật về testing thì các kỹ năng mềm cũng đóng vai trò quan trọng ko kém.

- Technique skill: Bạn phải có các kiến thức về vòng đời phần mềm, các quy trình xử lý (process), (môn Công nghệ phần mềm khi bạn đi học cũng giúp ích được khá nhiều )đó là kiến thức nền tảng bạn cần nắm được. Liên quan đến technique còn có các kiến thức về functional / business, các vấn đề về nghiệp vụ bạn cần phải nắm rõ.Bạn cũng phải có kiến thức về việc viết tài liệu, cách thể hiện một tài liệu rõ ràng mạch lạc để người khác đọc dễ hiêu. Bạn cũng nên biết qua về một số tool test nào đó, trong những tình huông cụ thể thì tool giúp bạn tiết kiệm công sức và hiệu quả khá nhiều .Và cuối cùng là một chút kiến thức về lập trình, ko cần phải quá sâu nhưng ít ra bạn cũng hiểu một chút về nó, ít ra bạn cũng phải biết gọi tên một bug lỗi thể nào: nó là 1 cái text box, dropdown list, lable…đang bị lỗi.

- Về kỹ năng mềm:

+ Kỹ năng đọc tài liệu :Khi join vào dự án thì lượng tài liệu phải đọc rất nhiều: đó có thể là SRS (Software requirement specification), BD(Basic design)…. Bạn phải biết cách đọc sao cho mình có thể hiểu một cách clear nhất, nếu ban đầu có khó khăn hãy nhờ sự giúp đỡ của người khác.

+ Kỹ năng communication: Đây là kỹ năng khá quan trọng vì bạn phải giao tiếp với khá nhiều người, việc communication gồm cả viết và nói, bạn có thể dung email hoặc đàm thoại trực tiếp trong quá trình làm việc, hãy cố gắng chuyển tải thông tin cho đồng nghiệp/ khách hang… một cách ngắn gọn tránh lan man dài dòng.

+ Kỹ năng tạo tài liệu: Bạn phải create khá nhiều tài liệu (test design, testcase, test report…) cố gẵng rèn kỹ năng viết sao cho hiệu quả, tránh quá nhiều lỗi ngữ pháp,chính tả (đa phần test case viết bằng tiếng anh nên cố gắng học tiếng anh ít nhất là để đọc Spec và viết test case).Khi report cũng phải hiệu quả để có thể reproduce nhanh bug.

+ Kỹ năng tự quản lý,tổ chức:Bạn cũng chỉ có 8 giờ làm việc trong ngày hãy cố gắng thu xếp thời gian tập trung cho công việc để ko phải overtime và hoàn thành công việc, để làm việc được thế bạn cũng cần estimate thời gian cho chính mình và phân bố effort như thế nào cho hợp lý.

ucto đã viết:Bạn sẽ làm gì nếu bạn không có đủ thời gian để kiểm thử?

Đương nhiên là mình sẽ xin thêm thời gian

Admin đã viết:Theo sự trình bày của Đại diện công ty Harvey Nash, mô hình làm việc là 4 Developer thì chỉ cần một Tester. Vậy có phải cơ hội việc làm của Tester rất ít hay không?

Không. cơ hội làm việc của tester rất cao. Hàng năm vị trí tester luôn đc tuyển dụng rất nhiều

ucto đã viết:Bạn có nghĩ rằng kiểm thử tự động có thể thay thế kiểm thử thủ công?

MÌnh ngĩ kiểm thử tự động không thể thay thé kiểm thử thủ công

ucto đã viết:giống và khác nhau giữa kiểm thử thủ công và kiểm thử tự động là gì

So sánh giữa kiểm thử thủ công và kiểm thử tự động:
Điểm mạnh:
Kiểm thử tự động:

Nếu ta phải thực hiện một loạt các kiểm tra liên tục và lặp lại thì tự động hóa là một lợi lớn
Giúp thực hiện "kiểm tra khả năng tương thích" – kiểm thử phần mềm trên cấu hình khác nhau
Nó cung cấp cho chúng ta khả năng để thực hiện tự động hóa các kiểm thử hồi quy trong một thời gian ngắn
Nó cung cấp cho chúng ta khả năng để thực hiện kiểm thử hồi quy trên một đoạn code liên tục thay đổi
Có thể chạy đồng thời trên các máy khác nhau do đó giảm thời gian kiểm thử
Giảm được chi phí dài hạn


Kiểm thử thủ công:

Nếu các Test Cases chỉ thực hiện một số ít lần thì có nhiều khả năng để thực hiện kiểm tra thủ công
Nó cho phép tester thực hiện việc kiểm thử khám phá
Thích hợp khi kiểm tra sản phẩm lần đầu tiên
Giảm được chi phí ngắn hạn


Điểm yếu:
Kiểm thử tự động:

Sẽ tốn kém hơn để thực hiện kiểm thử tự động, đầu tư ban đầu nhiều hơn kiểm thử thủ công
Chúng ta không thể tự động hóa mọi thứ, nhiều kiểm thử vẫn tiếp tục phải thực hiện thủ công

Kiểm thử thủ công:

Kiểm thử thủ công sẽ tốn thời gian hơn
Đối với mỗi bản phát hành (release), chúng ta phải chạy lại cùng một tập hợp các kiểm thử đã làm có thể dẫn đến sự mệt mỏi và lãng phí

ucto đã viết:Sự khác biệt giữa QC & QA?

QA: Các hoạt động cần thiết được lập một cách có kế hoạch và có hệ thống để đáp ứng đầy đủ mức độ tin tưởng vào các yêu cầu đó có được thiết lập chính xác và các sản phẩm hoặc các dịch vụ có phù hợp với đặc tả của các yêu cầu.
QC: Quá trình chất lượng của sản phẩm được so sánh bằng các tiêu chuẩn thích hợp; và sự tác động kịp thời khi sự không phù hợp được phát hiện.
QA: Hoạt động được thiết lập và đánh giá tiến trình tạo sản phẩm.
QC: Hoạt động kiểm tra liệu sản phẩm có phù hợp với các tiêu chuẩn đã có sẵn.
QA: Hỗ trợ thiết lập các tiến trình.
QC: Thực thi tiến trình.
QA: Thiết lập các chương trình đo lường để đánh giá các tiến trình.
QC: Kiểm tra liệu các đặc tính cụ thể có nằm trong sản phẩm.
QA: Xác định điểm yếu nhất trong tiến trình và cải thiện chúng.
QC: Xác định các thiếu sót với mục đích chính là tìm ra đúng các khuyết điểm.
QA: Là trách nhiệm của toàn bộ nhóm.
QC: Là trách nhiệm của tester.
QA: Ngăn chặn các hậu quả của vấn đề hoặc các khuyết điểm.
QC: Các thiếu sót, các báo cáo và các lỗi chính xác.
QA: Đánh giá xem có hoặc không quá trình điều khiển chất lượng đang hoạt động, mà mục đích chính là xác định liệu có hoặc không các điểm yếu trong tiến trình.
QC: Đánh giá xem ứng dụng đang tiến hành với mục đính chính là xác định liệu có một chỗ hỏng hoặc thiếu sót nào trong các chức năng.
QA: Cải thiện tiến trình mà được áp dụng cho nhiều sản phẩm được tạo ra bất kỳ lúc nào phù hợp tiến trình.
QC: Cải thiện sự phát triển sản phẩm cho phù hợp.
QA: Những người đảm bảo chất lượng không nên thực hiện công việc điều khiển chất lượng, trừ khi công việc đó là để xác nhận tính hợp lệ của quá trình điều khiển chất lượng đang được thực hiện.
QC: Những người điều khiển chất lượng có lẽ nên thực hiện công việc đảm bảo chất lượng nếu và khi được yêu cầu.

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

Cám ơn câu hỏi của bạn Nhóm mình xin trả lời như sau:
Làm test không cần phải biết lập trình mà chỉ cần hiểu NNLT.

ucto đã viết:Sự khác biệt giữa smoke testing và sanity testing?

Sanity testing là kiểu test dựa trên việc đánh giá ước lượng tính phù hợp của yêu cầu hoặc sự tính toán một cách nhanh chóng. Ví dụ như trong lĩnh vực toán học, khi lấy 3 nhân cho 9, ta phải kiểm tra rằng tổng các chữ số của kết quả phải chia hết cho 3 hoặc 9 (đây là phương pháp casting out nines), tương tự như là sanity testing.

- Smoke testing là một tập hợp con của kế hoạch lập test case là bao phủ chức năng chính của một phần hoặc toàn bộ hệ thống, để chắc chắn rằng hầu hết các chức năng chủ chốt (cốt yếu) của chương trình làm việc đúng, nhưng không làm ảnh hưởng đến các thông tin chi tiết hơn. Smoke testing là một trong số các phương pháp công nghệ tốt nhất

- Sanity testing: Trong khoa học máy tính, sanity là một bước thực hiện một cách ngắn gọn các chức năng của chương trình máy tính, hệ thống, sự tính toán hoặc phân tích khác, để chắc chắn rằng hệ thống hoặc phương pháp suy luận đáp ứng được kết quả mong đợi, thường được thực hiện trước phương pháp kiểm tra vét cạn.

- Smoke testing: Trong lĩnh vực sản xuất phần mềm, smoke testing thường được dùng cho lần tích hợp các modules, thành phần hoặc sau khi phần mềm được sửa chữa, bảo trì nhằm mục đích cung cấp cho các bên liên quan những bảo đảm phần mềm không có những lỗi nghiêm trọng. Nó chứng minh được phần mềm không bị thất bại ngay lần đầu tiên để chuẩn bị cho bước test tiếp theo là stress test.

- Sanity testing: Sau khi phần mềm được cải tiến, bảo trì, thay đổi chức năng hoặc fix bug xong, thì việc kiểm tra lại (regression testing) các chức năng đã test xong trước đây trên phiên bản vừa sửa xong này là để chắc chắn rằng những sự thay đổi vừa rồi không làm ảnh hưởng đến phần mềm và phần mềm đã được fix bug, cải tiến hoặc bảo trì đúng theo yêu cầu. Lúc này phương pháp đặc thù riêng của regression testing này được nói đến là sanity testing, dùng để kiểm tra nhanh các hành vi quái gỡ, kỳ dị của phần mềm/hệ thống.

- Smoke testing: Sau khi phần mềm được cải tiến, bảo trì, thay đổi chức năng hoặc fix bug xong, thì việc kiểm tra lại (regression testing) các chức năng đã test xong trước đây trên phiên bản vừa sửa xong này là để chắc chắn rằng những sự thay đổi vừa rồi không làm ảnh hưởng đến phần mềm và phần mềm đã được fix bug, cải tiến hoặc bảo trì đúng theo yêu cầu. Lúc này phương pháp đặc thù riêng của regression testing này được nói đến là smoke testing, dùng để kiểm tra các chức năng cơ bản của phần mềm/hệ thống.

- Sanity testing: Bao phủ các chức năng cơ bản của bản build có ổn định để hoàn thành sản phẩm để deploy hay chưa.

- Smoke testing: Mở rộng sự cải tổ toàn diện trong quá trình sanity test.

ucto đã viết:Làm thế nào để bạn biết rằng tất cả các kịch bản thử nghiệm được bao phủ (covered)?

Mình cũng không rõ kịch bản thử nghiệm trong ngữ cảnh câu hỏi là gì. Tuy nhiên theo mình hiểu câu hỏi đề cập đến độ bao phủ trong kiểm thử. Độ bao phủ đóng vai trò quan trọng trong kiểm thử đặc biệt là trong quản lý kiểm thử. Tuy nhiên khi nói đến độ bao phủ, chúng ta phải nói độ bao phủ đó được đo dựa trên đơn vị nào. Độ bao phủ của yêu cầu, độ bao phủ của chức năng, độ bao phủ của các loại kiểm thử, độ bao phủ của kỹ thuật kiểm thử, độ bao phủ của trình duyệt v.v. ;Chúng ta cũng nên lưu ý thông tin về độ bao phủ cũng rất dễ gây nhầm lẫn.
Bạn có 100 yêu cầu và bạn đã kiểm thử được 90 yêu cầu vậy độ bao phủ là 90% đối với yêu cầu. Con số 90% nói lên điều gì về chất lượng công việc kiểm thử cũng như chất lượng sản phẩm. Chẳng nói lên điều gì cả. 90% đó sẽ có nghĩa hơn nếu được kết hợp với những thông tin khác như bao nhiêu yêu cầu quan trọng đã được bao phủ, bao nhiêu lỗi đã tìm được trong 90% đó.

ucto đã viết:Bạn biết những công cụ kiểm thử tự động nào?

Mình biết cc kiểm thử Selenium
Selenium là một trong những công cụ kiểm thử phần mềm tự động mã nguồn mở (open source test automation tool) mạnh mẽ nhất hiện nay cho việc kiểm thử ứng dụng Web. Selenium script có thể chạy được trên hầu hết các trình duyệt như IE, Mozilla FireFox, Chrome, Safari, Opera; và hầu hết các hệ điều hành như Windows, Mac, Linux.

ucto đã viết:Làm thế nào để đảm bảo chất lượng của sản phẩm phần mềm?

Một câu hỏi thuộc dạng khó và rộng tuy nhiên để tóm gọn thì mình xin trả lời như sau. Để đảm bảo chất lượng của phần mềm theo mình có 2 yếu tố quan trọng: qui trình tốt và nhân lực tốt. Qui trình chỉ những bước, cách thức để làm ra một sản phẩm có chất lượng. Nhân lực chỉ yếu tố con người để thực hiện qui trình đó. Nhân lực bao gồm đội phát triển, đội kiểm thử, phân tích yêu cầu, quản lý dự án, quản lý qui trình, v.v. (tùy theo mô hình có thể sẽ có thêm hoặc bớt). Điều đó có nghĩa là tất cả những bộ phận liên quan trong dự án đều tham gia, đóng góp và chịu trách nhiệm về chất lượng của sản phẩm. Đội kiểm thử đóng vai trò quan trọng trong đảm bảo chất lượng sản phẩm nhưng không phải duy nhất.

ucto đã viết:VÒng đời của bug là gì

vòng đời của bug :là thời gian của 1 bugs tồn tại từ lúc phát sinh cho tới lúc bug được sửa.

Admin đã viết:Theo sự trình bày của Đại diện công ty Harvey Nash, mô hình làm việc là 4 Developer thì chỉ cần một Tester. Vậy có phải cơ hội việc làm của Tester rất ít hay không?

Bạn cho mình hỏi là Đại diện công ty Harvey Nash trình bày từ khi nào ạ.
Trước Việt Nam thì 3 dev cần 1 test nhưng hiện nay nghề đang hội nhập nên các công ty cũng có những yêu cầu khắt khe trong việc viết các phần mềm. Do vậy nghề test giờ đang cần rất nhiều. cơ hội việc làm cao có thể trong tương lại Việt Nam là 1dev và cần 3 test

ucto đã viết:Bạn có nghĩ rằng kiểm thử tự động có thể thay thế kiểm thử thủ công?

Có và không. Kiểm thử tự động có thể thay thế kiểm thử thủ công ở những công việc mang tính lặp đi lặp lại hay không thể thực thi bằng kiểm thử thủ công. Tuy nhiên, kiểm thử tự động không thể thay thế kiểm thử thủ công chẳng hạn như việc tìm bug hay hỏi những câu hỏi hay.

ucto đã viết:em tham gia bao nhieu dự rôi, và trong dư án đó em làm nhưng cong viec gì

e chưa tham gia dự án nào

ucto đã viết:Mô tả những vấn đề chung của kiểm thử tự động

Kiểm thử tự động mang lại nhiều giá trị cho công việc kiểm thử. Tuy nhiên, cũng như kiểm thử thủ công, kiểm thử tự động cũng có những vấn đề riêng của nó.

1) Chi phí cao. Chi phí này bao gồm chi phí mua công cụ, chi phí đào tạo hoặc thuê kỹ sư triển khai, chi phí bảo trì.

2) Kỹ thuật. Việc tương tác giữa công cụ kiểm thử và sản phẩm là một thách thức lớn đối với kiểm thử tự động do sự phát triển nhanh chóng của công nghệ nói chung và công nghệ phát triển phần mềm nói riêng.

3) Đòi hỏi một nền tảng kiến thức nhất định về coding cũng như phát triển phần mềm. Thực chất, kiểm thử tự động cũng không khác việc phát triển phần mềm là mấy. Chúng tai phải viết thiết kế framework, viết code, thực thi, debug, sửa lỗi v.v. Nhiều công cụ ngày nay với những mô hình tiên tiến hỗ trợ kỹ sư kiểm thử có thể triển khai kiểm thử tự động mà không phải “động” đến code nhiều nhưng vẫn còn nhiều hạn chế.

Admin đã viết:Lỗi lớn nhất mà bạn từng tìm được là gì?

nhóm 12 xin trả lời:
toàn bộ các thành viên nhóm 12 chưa có đi làm do vậy chưa có tìm ra lỗi nào cả .

nhóm bạn phân biệt cho mình chiến lược kiểm thử phần mềm anpha và beta đc không?