31/8/14

Test plan là gì? - What is the test plan?

What's a 'test plan'?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:

* Title
* Identification of software including version/release numbers
* Revision history of document including authors, dates, approvals
* Table of Contents
* Purpose of document, intended audience
* Objective of testing effort
* Software product overview
* Relevant related document list, such as requirements, design documents, other test plans, etc.
* Relevant standards or legal requirements
* Traceability requirements
* Relevant naming conventions and identifier conventions
* Overall software project organization and personnel/contact-info/responsibilties
* Test organization and personnel/contact-info/responsibilities
* Assumptions and dependencies
* Project risk analysis
* Testing priorities and focus
* Scope and limitations of testing
* Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
* Outline of data input equivalence classes, boundary value analysis, error classes
* Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
* Test environment validity analysis - differences between the test and production systems and their impact on test validity.
* Test environment setup and configuration issues
* Software migration processes
* Software CM processes
* Test data setup requirements
* Database setup requirements
* Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
* Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
* Test automation - justification and overview
* Test tools to be used, including versions, patches, etc.
* Test script/test code maintenance processes and version control
* Problem tracking and resolution - tools and processes
* Project test metrics to be used
* Reporting requirements and testing deliverables
* Software entrance and exit criteria
* Initial sanity testing period and criteria
* Test suspension and restart criteria
* Personnel allocation
* Personnel pre-training needs
* Test site/location
* Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
* Relevant proprietary, classified, security, and licensing issues.
* Open issues
* Appendix - glossary, acronyms, etc.

Tạm dịch

Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào nỗ lực kiểm thử phần mềm. Quá trình chuẩn bị test plan là một cách hữu ích để suy nghĩ tới những nỗ lực cần thiết để xác nhận khả năng chấp nhận một sản phẩm phần mềm. Các tài liệu đã hoàn thành sẽ giúp mọi người bên ngoài nhóm test hiểu được 'tại sao' và 'như thế nào' chấp nhận sản phẩm. Nó cần phải hoàn hảo đủ để dùng được nhưng không đủ hoàn hảo vì không ai bên ngoài nhóm test sẽ đọc nó. Sau đây là một số hạng mục có thể được bao gồm trong một test plan, tùy thuộc vào từng dự án cụ thể:

* Tiêu đề
* Định nghĩa version của phần mềm (version release)
* Lưu lại quá trình hiệu chỉnh tài liệu như tác giả, ngày cập nhật, duyệt
* Mục lục
* Mục đích của tài liệu, ý kiến chung
* Mục tiêu của chi phí kiểm thử (test)
* Giới thiệu tổng quan về sản phẩm
* Danh sách tài liệu liên quan như spec, tài liệu thiết kế, các kế hoạch test khác,...
* Các tiêu chuẩn thích hợp, các yêu cầu hợp lệ
* Nguồn gốc của các sự thay đổi
* Relevant naming conventions and identifier conventions
* Overall software project organization and personnel/contact-info/responsibilties
* Test organization and personnel/contact-info/responsibilities
* Assumptions and dependencies
* Phân tích rủi ro của dự án
* Các vấn đề ưu tiên và tập trung test
* Phạm vi và giới hạn test
* Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
* Outline of data input equivalence classes, boundary value analysis, error classes
* Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
* Test environment validity analysis - differences between the test and production systems and their impact on test validity.
* Test environment setup and configuration issues
* Software migration processes
* Software CM processes
* Test data setup requirements
* Database setup requirements
* Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
* Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
* Test tự động - giải thích và tổng quan
* Các công cụ test được sử sụng, bao gồm các version, bản vá lỗi,...v.v
* các qui trình bảo trì và quản lý version của test script/test code
* Theo dõi và giải quyết vấn đề - Các công cụ và qui trình
* Các thước đo về test sản phẩm được sử dụng
* Báo cáo các yêu cầu và khả năng giao test
* Điều kiện đầu vào và đầu ra của phần mềm
* Giai đoạn và điều kiện test ban đầu
* Điều kiện dừng test và test lại
* Sự bố trí nhân sự
* Những người cần training trước khi tham gia
* Nơi test
* Các tổ chức test bên ngoài sẽ sử dụng và mục đích, trách nhiệm, khả năng hoàn thành, người liên hệ và các vấn đề hợp tác của họ
* Các vấn đề độc quyền thích hợp, phân loại, bảo mật và bản quyền.
* Các vấn đề mở
* Phụ lục - bảng chú giải, các từ viết tắt, ...v.v.

29/8/14

How Much Testing is Enough? - Kiểm thử bao nhiêu là đủ?

This can be difficult to determine. Most modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:

Deadlines (release deadlines, testing deadlines, etc.)
Test cases completed with certain percentage passed
Test budget depleted
Coverage of code/functionality/requirements reaches a specified point
Bug rate falls below a certain level
Beta or alpha testing period ends

Đối với 1 phần mềm, chúng ta không thể nói được rằng nó không còn lỗi nữa, perfect rồi, bàn giao cho khách hàng thôi. Có thể những lỗi các bạn phát hiện ra, fix và ko còn hiển hiện nữa nhưng còn những lỗi tiềm tàng thì sao? Các bạn có chắc chắn rằng mình có thể cover hết được các tình huống có thể xảy ra đối với phần mềm của mình hay không? Câu trả lời là không. Vậy thì kiểm thử như thế nào là đủ? Cái này cũng rất khó có thể xác định. Như có ai hỏi các bạn có bao nhiêu tiền thì cảm thấy đủ, chẳng ai trả lời đc. Càng có nhiều lại muốn có nhiều hơn nữa kia. Ta quay lại vấn đề, kiểm thử bao nhiêu là đủ. 
- Thứ 1 đó là dựa vào hạn release sản phẩm
- Số lượng test case hoàn thành so với phần trăm test case pass
- Ngân sách dành cho kiểm thử đã hết
- Độ bao phủ code/chức năng/yêu cầu đều đã đạt được điểm yêu cầu.
- Tỷ lệ bug thấp hơn mức cho phép 
- Các phiên bản thử nghiệm beta hoặc alpha đã kết thúc
Xem thêm tạihttp://www.softwareqatest.com/qatfaq2.html

Các câu hỏi phỏng vấn xin việc tester


1. Why do you choose to become a Tester? 
Tại sao bạn chọn nghề Kiểm thử viên?

2. What sources do you learn testing? 
Bạn học lý thuyết và thực hành test từ những nguồn nào?

3. Would you like to become a professional Tester? How do you plan to achieve it? 
Bạn có kỳ vọng trở thành chuyên gia về test không? Bạn đã lên kế hoạch như thế nào để đạt được mục tiêu đó?

4. What time do you usually spend using computer a day? 
Bạn thường sử dụng máy tính bao lâu trong một ngày?

5. What do you use computer for and how much time for each? 
Bạn sử dụng máy tính vào những công việc gì và thời gian sử dụng cho mỗi công việc đó là bao lâu?

6. In your opinion, what are the most important factors that establish a successful website? 
Theo bạn đâu là những yếu tố cơ bản tạo nên sự thành công của một website?

7. What characters are necessary for a Tester? Have you got them? 
Những tính cách nào cần thiết cho vị trí Tester? Bạn có những tính cách đó không?

8. Tell us your team-work experience. Have you ever worked in a team? What was your team size and your role in the team? 
Bạn đã bao giờ làm việc nhóm chưa? Nếu có, quy mô nhóm của bạn là bao nhiêu người và bạn có vai trò như thế nào trong mỗi nhóm?

9. What are the factors that create an effective working team? 
Những yếu tố tạo nên một nhóm hoạt động hiệu quả?

10. What is your strength and why? 
Điểm mạnh của bạn là gì? Tại sao?

11. What is your weakness and please tell us why it is? 
Đâu là điểm yếu của bạn và tại sao?

12. Please describe the relationship between “Learn” and “Practice”? 
Bạn hãy trình bày mối quan hệ giữa “Học” và “Hành”?

13. What are the most important factors that help you become successful in your chosen career? Please explain why? 
Những yếu tố nào giúp bạn thành công trong nghề nghiệp của bạn? Tại sao?

14. What do you enjoy doing the most in your free time and tell us why? 
Bạn thích làm gì trong thời gian rỗi của bạn và tại sao?

15. What source have you known our recruitment information? 
Bạn biết thông tin tuyển dụng của chúng tôi qua nguồn nào?

16. Why do you apply for our company? 
Tại sao bạn tham gia dự tuyển vào làm việc tại công ty?

17. What do you think about job change? How long would you like to stay in each job? 
Bạn nghĩ gì về sự thay đổi công việc? Đối với bạn một công việc nên kéo dài bao lâu là đủ?

18. If you are recruited, what date could you start to work? 
Nếu trúng tuyển, bạn có thể bắt đầu công việc từ khi nào?

19. Are you willing to travel oversea for training? 
Bạn có đồng ý đi đào tạo ở nước ngoài không?

20. What is your expected starting salary when joining our company and tell us why you are suitable for this? 
Mức lương khởi điểm bạn mong muốn khi làm việc tại công ty chúng tôi và tại sao bạn xứng đáng với mức lương đó?

21. What about your expected salary in the future and how do you plan to achieve it? 
Mức lương bạn mong muốn trong tương lai và kế hoạch của bạn để đạt được mức lương đó?

22. Tell me about your last job? Why did you want to leave?/ 
Hãy nói qua về công việc trước của bạn? Tại sao bạn lại nghỉ công việc đó?

23. How would your last boss describe you?/ 
Người quản lí trước nhận xét gì về bạn?

24. What can you personally add to a software testing / SQA team? 
Những kỹ năng nào của bạn cần cho công việc kiểm thử?

25. What motivates you? 
Điều gì là động lực thúc đẩy bạn?

26. What are you looking for in your next job? What are your career aspirations? 
Bạn đang tìm kiếm điều gì cho công việc tiếp theo? Nguyện vọng nghề nghiệp của bạn là gì?

27. What has been the biggest problem you have encountered working in software testing / QA? 
Vấn đề nào là lớn nhất bạn gặp phải khi tham gia kiểm thử phần mềm?

28. How do you organise your workload? 
Bạn sẽ tổ chức khối lượng công việc của mình như thế nào?

29. What do you see as the advantages and disadvantages of this job? 
Bạn thấy nghề này (kiểm thử) có ưu điểm và nhược điểm gì không?

30. If you got this job, what would you be able to contribute immediately? What skills gaps or training needs would there be?/ 
Nếu bạn nhận công việc này, bạn có thể làm việc ngay lập tức không? Bạn sẽ cần thêm nhưng kỹ năng hay hay đào tạo gì không?

31. What resources do you make use of to keep abreast of the latest development and news in software testing / SQA? 
Bạn sẽ làm gì để nắm bắt, theo kịp những thông tin, phát triển mới nhất của ngành kiểm thử?

32. What quality standards and models are you familiar with? 
Những mô hình và tiêu chuẩn nào bạn đã biết?

33. What has been your biggest personal achievement in software testing / SQA? 
Bạn đã đạt được thành tựu gì lớn nhất trong việc kiểm thử?

34. How would your colleagues describe you? 
Các đồng nghiệp nói về bạn như thế nào?

35. Have you ever missed finding a very important bug? How did you react afterwards? 
Bạn đã bao giờ bỏ sót một lỗi rất quan trọng? Bạn đã giải quyết thế nào?

36. How would you describe yourself? 
Bạn thấy mình là người như thế nào?

37. What is the best bug you have ever found? 
Lỗi lớn nhất mà bạn từng tìm được là gì?

38. What tools do you use? 
Bạn thường sử dụng những phần mềm nào để hỗ trợ công việc của mình nào ?

39. What tools don’t you like? Why? 
Bạn không thích những công cụ (phần mềm) nào? Tại sao? 

40. What non-functional test experience do you have?/ 
Những kinh nghiệm bạn rút ra từ việc kiểm thử là gì?

41. Do you have any scripting or coding skills? If so, what?/ 
Bạn có thể viết các scripts hoặc code chứ? Nếu có, đó là những gì?

42. Have you ever written any test tools or harnesses? 
Bạn đã bao giờ viết một chương trình test ???

43. When you are happiest testing what exactly is it that you are doing? 
Việc gì khiến bạn cảm thấy hạnh phúc nhất khi kiểm thử?

44. Imagine a stressful project. It’s towards the end of the integration test phase. You find an issue you believe to be an important bug and you discuss it with the developer. He dismisses it as being a ‘feature’ and suggests you ‘just live with it’. What do you do? 
Hãy tưởng tượng bạn đang trong một dự án rất căng thẳng. Đang là cuối quy trình kiểm thử tích hợp. Bạn tìm thấy vấn đề mà bạn tin đó là một lỗi rất quan trọng và bạn trao đổi với người phát triển. Dev bác bỏ, nói nó chỉ là lỗi nhỏ và khuyên bạn nên chấp nhận nó.Bạn sẽ làm gì trong trường hợp này?

45. You have a new software release to test but you have been given a limited time to test it by your management. Despite your protests you are given no more time. What is your test approach? 
Bạn phải test một phần mềm mới nhưng người quản lí gia hạn thời gian để test rất ít. Với trình độ của bạn sẽ cần nhiều thời gian hơn để test. Bạn sẽ phải làm gì?

46. What SDLCs (software development lifecycle models) have you worked with? 
Bạn đã từng làm việc với những Mô hình Vòng đời phát triển phần mềm nào?

47. What is your experience of agile testing? 
Kinh nghiệm của tra nhanh của bạn là gì?

48. When do you think it is appropriate to automate tests? 
Bạn nghĩ khi nào thích hợp để dùng kiểm tra tự động?

49. Do you have any questions for us? 
Bạn có câu hỏi nào cho chúng tôi không?
Sưu tầm

20/8/14

Automation Testing

Trong thế giới ngôn ngữ lập trình, hẳn các bạn đã biết và làm quen với những ngôn ngữ như C, C++, C#, VB, Java, Php, ASP.NET…! Và cũng có thể các bạn đã từng làm hoặc mới nghe nói đến các tools như: QuickTestProfessional, TestComplete, RanoRex, LoadRunner, hoặc CodedUITesting (Visual Studio 2010 Ultimate version). Các tools đó là gì, chúng làm gì hay liên quan gì đến thế giới lập trình phần mềm?

        Bạn biết rằng, trong suốt giai đoạn phát triển phần mềm bạn thường xuyên phải thay đổi functions, hoặc modules nào đó, để cho phù hợp với yêu cầu thực tế. Hoặc sau khi deliver sản phẩm cho khách hàng, khách hàng yêu cầu chúng ta thay đổi 1 module, hoặc một function…, thì sau khi các bạn change requirements, các bạn phải thực hiện lại việc Regression Testing, và dĩ nhiên nếu làm bằng tay, các bạn sẽ mất rất nhiều công sức và thời gian và có thể còn không chính xác.
Automation Testing và tại sao?

Đặt vấn đề: Các bạn đang làm trong một dự án lớn cho một cty lớn. Dự án của các bạn có khoảng 5 testers. Và vấn đề ở đây là khách hàng yêu cầu các bạn (testers) thực hiện việc testing cho sản phẩm với các data của việc test sẽ do chính khách hàng cung cấp. Khách hàng gửi cho các bạn một file excel với tổng số row data cho việc test là 20.000 rows. (Đây là một ví dụ, nhưng trong thực tế có thể lên tới gấp đôi con số trên – nên các bạn có thể hơi ngạc nhiên vì sao lại nhiều data như vậy).

Yêu cầu của bài toán testing: Với mỗi một row data nhập vào hệ thống (sản phẩm các Developer của chúng ta đang code), hệ thống sẽ tính toán và phải đưa ra một giá trị chính xác với giá trị khách hàng cung cấp. Ở đây, khách hàng cung cấp cho các bạn cả Input Data, Expected Result, việc còn lại bạn sẽ phải lấy Output data trên sản phẩm các bạn đang làm để compare với Expected của khách hàng.

Test case: Chỉ gồm các bước như nhập dữ liệu vào textboxes, comboboxes, clicking on some buttons, rồi lấy kết quả trên màn hình, so sánh với Expected Result của khách hàng, rồi mark vào report là Pass or Fail.
Picture
Manual Testing: 5 Testers của chúng ta sẽ phải hì hục ngồi nhập từng row data mà khách hàng provided vào hệ thống (trên UI), Lúc đầu rất hào hứng vì việc test đó không có gì khó khăn, nhưng việc đó cứ lặp đi lặp lại đến chán ngắt, buồn ngủ => có người nhập đúng các Input data, nhưng lại lấy sai Actual Output. Có người nhập sai cả Input Data…!

Mình estimate như sau: Cứ 5 phút thì một tester làm xong một case (một row) và đưa ra được report là pass hay fail. Một ngày 5 testers sẽ làm được: 5 người *((8h * 60 phút)/5 phút một row) = 480 cases. Vậy phải mất 41,6 ngày làm việc thì 5 testers của chúng ta mới kết thúc được 20.000 rows data.

Các bạn nghĩ sao, liệu các testers có chăm chỉ làm 1 ngày 8h hay không? Liệu cứ sau 5p họ có xong một test case (row) hay không? Và liệu họ có bị buồn ngủ và làm nhầm hay không? Con số mình estimate ở bên trên chỉ là estimate. Chứ còn thực tế, nhỡ tester ốm thì sao, nhỡ về lấy chồng thì sao? Hoặc nhỡ xin nghỉ việc đi du lịch thì sao???

Các bạn nghĩ sao, liệu các testers có chăm chỉ làm 1 ngày 8h hay không? Liệu cứ sau 5p họ có xong một test case (row) hay không? Và liệu họ có bị buồn ngủ và làm nhầm hay không? Con số mình estimate ở bên trên chỉ là estimate. Chứ còn thực tế, nhỡ tester ốm thì sao, nhỡ về lấy chồng thì sao? Hoặc nhỡ xin nghỉ việc đi du lịch thì sao???

Automation Testing: Trên đầu topic, mình đã nêu ra vài Automation test tools! Nhưng trước hết Automation Testing là gì? Là một software program dùng để chạy một cách tự động thay thế các thao tác testing bằng tay.
Ưu điểm của Automation Testing: Nó chạy thay thế testers và không biết mệt, không có chuyện ốm đau, không có chuyện phải dừng để chát, ăn quà vặt, hay để đi WC. Chúng có thể chạy liên tục ngày đêm, một khi chạy đúng được 1 case, thì chúng ta yên tâm rằng Script sẽ chạy đúng những gì chúng ta yêu cầu.

Những gì chúng ta cần viết scripts cho bài toán trên: Viết các script code để giả lập việc nhập dữ liệu vào Textboxes, chọn một item trong combobox, click vào một checkbox, hoặc click vào Button. Và chúng ta cũng phải viết scripts để lấy dữ liệu Output từ một textbox, label, hoặc datagrid… để so sánh với Expected của khách hàng. Chúng ta cũng phải viết các scripts để compare dữ liệu, và đưa ra kết quả là Pass hay Fail.
Picture
Và cuối cùng chúng ta sẽ để cho Script của chúng ta chạy đêm ngày – còn chúng ta sẽ ngồi đọc báo, học thêm sách technical, hoặc học tiếng anh, đi uống trà đá. ^^ Còn các em testers xinh đẹp sẽ đỡ vất vả hơn rất nhiều, dĩ nhiên các em ý sẽ yêu quý chúng ta hơn!
                                                                                                                                                                                    
Sưu tầm
Automation Testing Tools
1-    Quick Test Professional 10
2-    Ranorex 2.4.1
3-    TestComplete 9
4-    Visual Studio 2010 Ultimate

Tất cả các tools này đòi hỏi phải có license, còn các bạn muốn sử dụng thì cũng có thể tìm key hoặc crack để sử dụng. Mình thì hay dùng Trial version, sau 30 ngày thì lại phải cài lại máy, hơi buồn chút! Như các bạn đã biết, để tạo được Automation Test Scripts, thì ngôn ngữ chúng ta dùng ở đây chính là dưới dạng Script, tuy nhiên, mỗi loại tool cho phép chúng ta viết các automation scripts dưới dạng một hay nhiều ngôn ngữ khác nhau:
  • QTP: Cho phép chúng ta lựa chọn 1 trong 2 ngôn ngữ để viết Script là VBScript hoặc Delphi script.

  • TestComplete: JavaScript, VBScript, C/C++/C# script, Delphi
  • Ranorex: C#, VB.NET và Python


    Như các bạn thấy, mỗi một tool đều những ưu nhược điểm riêng biệt,

Đối với QTP, script được viết bằng VBScript nên nó tương đối nhẹ, nhưng là ngôn ngữ thuần script nên việc xây dựng các Objects không được flexible cho lắm, còn đối với Visual Studio 2010, tuy code script chạy nặng hơn VBScript, nhưng chúng ta hoàn toàn thoải mái customize, xây dựng các objects, data, tiers như một ứng dụng C#. Còn ví dụ như TestComplete 9, bạn có thể lựa chọn một trong các languages để viết theo khả năng của bạn, hơn nữa TestComplete8 còn support khá mạnh cho việc test các ứng dụng được viết bằng Delphi.


Đặc điểm chung của các tools:

-       Các tools đều có một tính năng rất hay, Recording. Tính năng này cho phép người sử dụng có thể ghi lại các steps như: click, focus, press, hoặc nhập dữ liệu vào textboxes, click vào button, check vào checkboxes, select các items trong combobox, thao tác với DataGrid…vv.

-       Các tools đều có một Object Repository. Các bạn hiểu nôm na rằng đây là một nơi để lưu trữ (stores) các object, controls mà các tools ghi lại sau khi thực hiện quá trình Recording. Thông tin này thông thường được store dưới dạng XML, và dĩ nhiên các bạn không phải mò mẫm trong đống XML để xem từng object cụ thể, mà nó có tool cho phép bạn tìm kiếm, lựa chọn như trên một DataGrid.

-       Các tools đều hỗ trợ làm việc với Data Driven (đây là một khái niệm gần như thuộc về Architecture, mình sẽ đề cập đến khái niệm này sau, còn bây giờ các bạn cứ hình dung như thế này, các bạn không bao giờ viết cả Script và Data lẫn nhau, mà Data nên đặt tại SQL DB hoặc Excel hoặc XML. Một khi các bạn hoàn thành Scripts, các bạn chỉ cần thay đổi Data và cho chúng chạy, nên=> 1 script sẽ test được cho n data).

Đặc điểm riêng:

-       Chính ngôn ngữ được support trong các tools đã nói nên các đặc điểm (đúng hơn là về tính ứng dụng của mỗi tool)

-       Thông thường mình hay dùng QTP để test cho các ứng dụng Web based apps. Dùng Ranorex để test cho Window based apps. Dùng TestComplete để test cho Web, Win, đặc biệt là Delphi apps. Còn VS2010 dùng để test cho các ứng dụng như WPF trên .NET 3.5,

Để học việc sử dụng các tools này không khó, nhưng để sử dụng được vào thực tế (vì sử dụng tools ở đây không chỉ làm tăng năng suất cho đội dự án, mà chúng ta đang đi hẳn về một ngề, Testing Service) thì các bạn cần phải sử dụng chúng một cách chuẩn, theo một template nào đó.