toi5
Senior Member
Tôi thấy box này ít có nói gì nhiều về testing, nên tạo topic này để share và discuss
## FAQs
Tiếng việt thì test là kiểm thử (ok that's fine xD). Theo style hiện đại ngày nay thì test được phân tách rõ ràng thành 2 phần: Testing và Checking
## Information
Information , nôm na gọi là thông tin ta có được ảnh hưởng tới việc testing và checking.Vì sao? Vì testing và checking là 1 process ko thể xa lìa. Testing giúp kiếm ra thứ để checking và checking để validate lại xem nó có đúng ko. Thứ chúng ta kiếm ra là information, mà information này muốn kiếm ra dc ko phải dễ.
Chúng ta, tức QAs aka culi hay DEVs hay PO/PM mọi thành phần trong team sẽ là 1 phần giúp có dc thứ để checking. Còn bản thân mình thì phải kiếm information này bằng công sức , vậy làm sao để có? Đây là 1 câu hỏi mà tôi cũng hỏi nhiều người khi interview là làm sao em test dc những thứ mà em ko biết và mặc định ứng viên bay vào kêu kiếm doc và test luôn tại chỗ mà ko rõ mình cần làm gì trước
Refer: https://danashby.co.uk/2016/03/08/i...6k1xi6YSxe8DyYMhk8e9Eica5UZWgBwqp55FqECqsoUBY
## Testing & Checking
Ok chúng ta tới đây nhiều fence xem Testing = Ad-hoc/Exploraty Test. Điều này đúng 1 phần vì ching mục đích nhưng sai cách tiếp cận. Nếu các fence là fan lâu năm của "thánh" James Batch thì chắc có nghe qua test model là Rapid Software Testing
## Rapid Software Testing
Topic này ko đề cập nhiều tới model này, nếu muốn refer có thể check qua : https://www.satisfice.com/download/a-rapid-software-testing-framework. Đây là 1 model ko mới, nhưng nó đề cập sâu tới việc sử dụng "input" để produce ra "output" cần verify . Đây là 1 dạng testing mình đã đề cập ở trên
Mô hình khái quát như sau
## Testing Inputs
Inputs ở đây ko phải là những inputs về data, parameters, variables ... cho 1 feature nào đó. Inputs là những cái cần thiết để fence bắt đầu việc Testing. Tôi hay interview khi hỏi 1 thằng candidate là cho feature này làm sao em test thì họ trả lời ngay lập tức theo khuôn mẫu là đọc documents, hỏi dev, hỏi PO/PMs blah blah.
Cái này đúng như trong context của cái RST này là chưa đúng và thiếu. Inputs để xác định việc checking và checking từ đó mới sinh ra nên apply testing thế nào.
Vậy nên để có inputs cho việc checking hiệu quả dựa vào :
Mục đích của testing là gì? Tại sao tôi phải làm? Làm để làm gì? Là những câu hỏi phải ra khi dc giao validate 1 cái gì đó.
## Testing outputs
Outputs của testing đến từ việc apply tools, methods, appoaches và orcles. Và tất nhiên ko thể thiếu 3 cái inputs ở trên. Việc apply testing kiểu này mang lại hiệu quả nhưng tốn thời gian và sẽ rất khó khăn với ai mới vào nghề, vậy giải pháp là gì ?
Những bài sau sẽ nói thêm về automation tests
## FAQs
- Topic này về gì?
Đa số vozers trong khu này là dev front-end, back-end hay fullstack các kiểu. Ít có vozers nào về tests nói chung và automation nói riêng nên tui mạo muội tiên phong về vấn đề này - Tóm lại là lại nói về automation tests à?
Không. Topic này nói những thứ có đi lệch với những cái automation tests các fence đã học trong trường, hay đi làm ít ai chỉ, hay freshers mà bắt làm automation tests như cái máy, etc. Topic này kiểu resources tóm gọn lại cho các fence bước đầu vào con đường tests và automation tests mang lại value cho product của mình - Ủa mắc gì làm?
Làm vì để chia sẻ kiến thức, trao dồi kĩ năng. Ko focus quá vào tests chung chung
Tiếng việt thì test là kiểm thử (ok that's fine xD). Theo style hiện đại ngày nay thì test được phân tách rõ ràng thành 2 phần: Testing và Checking
- Testing: Sử dụng tools, methods, approaches để test system nó work như thế nào, nó cần improve gì, nó có những lỗi tìm ẩn hay ko, nó có những vấn đề bất cập nào, nó cần dc test để cung cấp thông tin mình cần biết thế nào etc... Cái này gọi là testing
- Checking: Đơn giản chỉ là có output sẵn, mình cần check lại xem với input thế này thì output có đúng ko. Làm sao cung cấp dc inpput? => Input đến từ việc apply những thuật toán, những thứ mình ĐÃ BIẾT, những thứ mình có sẵn để produce ra 1 input mà mình expect với input này mình sẽ có dc output.
## Information
Information , nôm na gọi là thông tin ta có được ảnh hưởng tới việc testing và checking.Vì sao? Vì testing và checking là 1 process ko thể xa lìa. Testing giúp kiếm ra thứ để checking và checking để validate lại xem nó có đúng ko. Thứ chúng ta kiếm ra là information, mà information này muốn kiếm ra dc ko phải dễ.
Chúng ta, tức QAs aka culi hay DEVs hay PO/PM mọi thành phần trong team sẽ là 1 phần giúp có dc thứ để checking. Còn bản thân mình thì phải kiếm information này bằng công sức , vậy làm sao để có? Đây là 1 câu hỏi mà tôi cũng hỏi nhiều người khi interview là làm sao em test dc những thứ mà em ko biết và mặc định ứng viên bay vào kêu kiếm doc và test luôn tại chỗ mà ko rõ mình cần làm gì trước
Refer: https://danashby.co.uk/2016/03/08/i...6k1xi6YSxe8DyYMhk8e9Eica5UZWgBwqp55FqECqsoUBY
## Testing & Checking
Ok chúng ta tới đây nhiều fence xem Testing = Ad-hoc/Exploraty Test. Điều này đúng 1 phần vì ching mục đích nhưng sai cách tiếp cận. Nếu các fence là fan lâu năm của "thánh" James Batch thì chắc có nghe qua test model là Rapid Software Testing
## Rapid Software Testing
Topic này ko đề cập nhiều tới model này, nếu muốn refer có thể check qua : https://www.satisfice.com/download/a-rapid-software-testing-framework. Đây là 1 model ko mới, nhưng nó đề cập sâu tới việc sử dụng "input" để produce ra "output" cần verify . Đây là 1 dạng testing mình đã đề cập ở trên
Mô hình khái quát như sau
## Testing Inputs
Inputs ở đây ko phải là những inputs về data, parameters, variables ... cho 1 feature nào đó. Inputs là những cái cần thiết để fence bắt đầu việc Testing. Tôi hay interview khi hỏi 1 thằng candidate là cho feature này làm sao em test thì họ trả lời ngay lập tức theo khuôn mẫu là đọc documents, hỏi dev, hỏi PO/PMs blah blah.
Cái này đúng như trong context của cái RST này là chưa đúng và thiếu. Inputs để xác định việc checking và checking từ đó mới sinh ra nên apply testing thế nào.
Vậy nên để có inputs cho việc checking hiệu quả dựa vào :
- Project
- Quality Criterias
- Product
Mục đích của testing là gì? Tại sao tôi phải làm? Làm để làm gì? Là những câu hỏi phải ra khi dc giao validate 1 cái gì đó.
## Testing outputs
Outputs của testing đến từ việc apply tools, methods, appoaches và orcles. Và tất nhiên ko thể thiếu 3 cái inputs ở trên. Việc apply testing kiểu này mang lại hiệu quả nhưng tốn thời gian và sẽ rất khó khăn với ai mới vào nghề, vậy giải pháp là gì ?
- Xác định mục tiêu : Tao cần test gì, tại sao phải test, nếu ko test thì có được ko ?
- Xác định rủi ro: ok tao đã xác định xong mục tiêu, vậy những rủi ro có thể xảy ra là gì? Rủi ro nào tao nên care, rủi ro nào team tao nên care, rủi ro nào customer hay client nên care?
- Xác định cách tìm information cho việc testing: Việc testing mà ko có document hay tools để track lại là ko hiệu quả. Refer bài này để biết thêm. Information này giúp cho việc checking sau này của bạn.
- Xác định nên xài oracles nào: Tuỳ target, tuỳ rũi ro, tuỳ cách tiếp cận để kiếm information mà refer xem nên apply
- Khi nào nên dừng test? Khi bạn đã xác định rõ được đã kiếm đủ information và validate dc information mình cần check là đúng
Những bài sau sẽ nói thêm về automation tests
