9 Nguyên tắc áp dụng trong phương pháp Agile

Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng. Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt và được xem như là sự cải tiến so với những mô hình cũ như mô hình “Thác nước (waterfall)” hay “CMMI”.

1. Kiểm thử giúp dự án nhanh chóng được bàn giao

Ở dự án truyền thống, kiểm thử thường được xem là bước cuối kiểm tra chất lượng sản phẩm. Và việc ngăn chặn lỗi của phầm mềm bị coi như trách nhiệm của QA/tester. Bug được tìm thấy dù quan trọng hay không thì cũng sẽ làm chậm quá trình bàn giao sản phẩm.

Trong dự án Agile, chúng ta xây dựng một sản phẩm tốt ngay từ ban đầu, sử dụng kiểm thử để phản hồi trên ngay khi phát triển để làm thế nào cho sản phẩm tương đồng với yêu cầu.

Nghe có vẻ là thay đổi nhỏ, nhưng thực chất thì việc này có ý nghĩa lớn. Mối liên hệ giữa tester và dev cần là sự cộng tác, tương hỗ lẫn nhau

1. Kiểm thử không chỉ là một giai đoạn của dự án
   Kiểm thử không phải là một giai đoạn trong quá trình phát triển Agile mà cần được tham gia sâu vào quy trình phát triển từ sớm.
   Cách tiếp cận Agile tập trung vào việc xác nhận những điều đúng đắn ngay từđầu, giảm sự cần thiết phải có nhiều kiểm thử viên (QA Tester) ở cuối quy trình để đạt được kết quả. Đảm bảo tiến độ dự án được liên tục.
2. Cá nhân và sự tương hỗ quan trọng hơn quy trình
   Với dự án truyền thống, tester làm việc độc lập và chịu trách nhiệm với toàn bộ hoạt động test.
   Đối với Agile, các hoạt động test được thực hiện bởi toàn bộ dự án. Để thực hiện được hết test thì cần thực hiện lặp lại qua các sprint.
   Tuy nhiên tới khi dự án lớn hoặc phức tạp lên thì sẽ có lúc không thể test hết các testcase đề ra và không thể thực hiện được mục tiêu ban đầu đề ra. Có nghĩa team không thể thực hiện nhanh như họ nghĩ. Vì nếu test chưa xong thì feature cũng không thể xong được, vì vậy để đẩy nhanh tốc độ thì cả team phải làm cùng nhau và đẩy nhanh phần chậm nhất, test cùng nhau.
3. Rút ngắn vòng lặp phản hồi
   Thời gian từ khi viết code và thực hiện code tới khi biết được code vận hành như thế nào được gọi là feedback loop (vòng phản hồi).
   Nếu một phần mềm không được thực hiện test cho tới khi kết thúc và được bàn giao thì vòng phản hồi này bị kéo dài tới cả tháng, như thế là quá dài.
   Agile tạo nên một vòng phản hồi ngắn hơn bởi với dự án Agile, phần mềm được sẵn sàng để test ngay từ khi bắt đầu. Đặc thù của Agile là đội dự án có rất nhiều cấp độ kiểm thử để có thể tấn công được nhiều loại dữ liệu khác nhau.
   Agile sử dụng nhiều test tự động vì nó trả lại phản hồi nhanh. Test hồi quy thủ công mất nhiều thời gian thực hiện hơn, cần có nhân lực và có thể không thực hiện ngay lập tức được. Kiểm tra thủ công vẫn còn quan trọng.
   Tuy nhiên, đội Agile thường thấy rằng những thông tin phản hồi nhanh chóng tạo nên bởi hồi quy tự động là chìa khóa để phát hiện các vấn đề một cách nhanh chóng, do đó làm giảm rủi ro và giảm việc phải làm lại.
4. Thỏa mãn mong muốn của khách hàng
   Cho dù là test tự động hay test thủ công thì kịch bản test cần phải khớp với yêu cầu và mong đợi của khách hàng. Trước khi tốn thời gian tìm bug nên đặt câu hỏi để làm sáng tỏ mong muốn của khách hàng đối với chức năng sản phẩm
5. Giữ code rõ ràng
   Nguyên tắc này là một ví dụ về một nguyên tắc mà đội Agile phải có. Sẽ mất nhiều công sức và thời gian để sửa lỗi khi chúng được tìm thấy.
   Nếu đó là một lỗi chính đáng nó sẽ được sửa trong vòng lặp và đôi khi kết quả sau khi sửa sẽ không được tốt bằng làm từ đầu vì nó ảnh hưởng tới những phần khác.
6. Giản lược tài liệu kiểm thử
   Thay vì viết dài dòng thì Agile test
   • Tái sử dụng checklist
   • Tập trung vào bản chất của các thử nghiệm chứ không phải là các chi tiết ngẫu nhiên
   • Sử dụng các tài liệu hướng dẫn đơn giản
   • Nắm bắt những ý tưởng thử nghiệm trong điều lệ kiểm nghiệm thăm dò
7. Chưa thể hoàn thành khi chưa qua giai đoạn kiểm thử

Trong dự án truyền thống có sự phân tách rõ ràng giữa dev và test, đó là đặc trưng cho việc dev nói “xong” với phần họ phát triển nhưng nó vẫn chưa được test. Do đó thực tế là phần phát triển ấy vẫn chưa xong cho tới khi test xong và bug được fix.

Đó là lý do vì sao mà phần mềm chỉ được để “90% done”. Agile không tính là “done” mà nó cần được sẵn sàng cho sự chấp nhận của Product Owner và khách hàng cho tới khi nó được thực thi và test

8. Test-Last và Test-Driven

Trong môi trường phát triển truyền thống, test được lấy từ tài liệu yêu cầu. Yêu cầu và design đầu tiên, sau đó đến kiểm thử. Quá trình kiểm thử diễn ra ở cuối dự án. Tuy nhiên kiểm thử cung cấp một ví dụ về ý nghĩa của việc phát triển thỏa mãn yêu cầu. Test được định hướng từ các thành phần của project, trong đó có tài liệu dự án. Việc thực hiện test được tiến hành vào thời điểm cuối cùng của project. Đây gọi là cách tiếp cận "testlast" - Test sau cùng

Continue Reading →

QTP GUI introduction

This article is going to give you an insight into the Keyword view of the QTP GUI. During this process we are going to get a quick introduction to Actions, Object Hierarchy and the basic columns in the keyword view.
Step1: Run QTP
Tests in QTP are recorded in terms of actions. Action is nothing but a set of statements performing a sequence of actions.  Most often an action is simply a logical unit of modularity. The calls to one or more actions can be defined as a QTP test.

Continue Reading →

Hướng dẫn cài đặt QuickTest Pro (QTP)

Bạn tải phần mềm QTP tại đây http://www.automationrepository.com/2011/08/download-qtp-11-trial-version-from-hp/

Yêu cầu phần mềm gồm:

Software	Version	Description
QuickTest Pro	9.2
Browser	IE 6.0, FF 2.0	Hỗ trợ tốt IE
.Net FrameWork	2.0

Hardware	Version	Description
Windows XP	SP2
Memory		Ram tối thiểu 512MB
Free Hard Disk space		500MB

Sau khi tải phần mềm về bạn  Copy file “qtp92.zip” về máy, click chuột phải -> chọn “Extract here”=> Chạy file “setup.exe”

Hiển thị menu chương trình -> chọn “QuickTest Professional Setup”

  Chương trình sẽ kiểm tra và yêu cầu bạn cài đặt “.Net FrameWork 2.0” (Nếu máy bạn đã cài “.Net FrameWork 2.0” rồi thì thực hiện tiếp bước “7”)

 Tích vào checkbox và chọn [Install >]

Continue Reading →

Bắt đầu với công cụ Quick Test Pro

QTP là phần mềm dùng để kiểm tra chức năng (functional test) và cho phép thực hiện kiểm tra hồi qui (regression test) một cách tự động. Đây cũng là công cụ áp dụng phương pháp Keyword – Driven, một kỹ thuật scripting hiện đại, cho phép kĩ thuật viên bổ sung test case bằng cách tạo file mô tả cho nó mà không cần chỉnh sửa hay bổ sung bất cứ script nào cả.

1.1.     Loại phần mềm hỗ trợ

QTP giúp chúng ta kiểm thử phần mềm theo hướng chức năng trên rất nhiều loại chương trình phần mềm khác nhau. Tuy nhiên QTP chỉ hỗ trợ sẵn một số lại chương trình thông dụng như:

·        Ứng dụng Windows chuẩn / Win32.

·        Ứng dụng web theo chuẩn HTML, XML chạy trong trình duyệt Internet Explorer...

·        Visual Basic.

·        ActiveX.

·        QTP hỗ trợ Unicode (UTF-8, UTF-16).

1.2.     Đặc điểm.

·        Dễ sử dụng, bảo trì, tạo test script nhanh. Cung cấp dữ liệu kiểm tra rõ ràng dễ hiểu.

·        Kiểm tra phiên bản mới của ứng dụng với rất ít sự thay đổi.

·        Hỗ trợ làm việc theo nhóm thông qua sự chia sẻ thư viện, thống nhất quản lý Object Repository.

·        Thực tế cho thấy, QTP thực hiện Kiểm thử đối tượng trên nhiều trình duyệt cùng lúc tốt hơn những phần mềm khác.

·        Với chức năng Recovery Scenarios, QTP cho phép sử lý những sự kiển hoặc lỗi không thể đoán trước có thể làm script bị dừng trong khi đang chạy.

·        QTP có khả năng hiểu test script của Mercury Winrunner (một công cụ kiểm tra khác của mercury).

1.3.     Các thành phần quan trọng QTP.

a)     Action

Giống như thủ tục hay hàm trong các ngôn ngữ lập trình khác, Action ghi lại các bước thực hiện kiểm thử và nó có thể được sử dụng lại nhiều lần. Trong một test script có thể có nhiều action.

b)     DataTable

Nơi lưu trữ dữ liệu phục vụ cho kiểm thử. Một test script sẽ có một DataTable được dùng chung cho tất cả các Action. Bên cạnh đó mỗi Action cũng có một DataTable riêng cho mình.

c)     Object Repository (OR)

Cấu trúc theo dạng cây, mô tả các đối tượng trong phần mềm được kiểm tra. Đây được xem là cầu nối để test script tương tác với phần mềm được kiểm tra.

Khi ra lệnh cho QTP ghi lại thao tác người dùng lên phần mềm thì trong OR sẽ tự động phát sinh thành phần đại diện cho những đối tượng trên phần mềm vừa được thao tác.

OR có thể tổ chức thành 2 loại, một loại dùng chung trong nhiều test script, loại khác dùng theo từng nhóm Action.

d)     Checkpoint

Có thể hiều là nơi kiểm tra trong test script, khi chạy nó sẽ thực hiện so sánh kết quả thực tế khi kiểm tra phần mềm với kết quả mong đợi. Sau khi tiến hành so sanhs QTO sẽ tự động ghi lại kết quả vào Test Results.

1.4.     Ngôn ngữ sử dụng viết script

QTP sử dụng ngôn ngữ VBScript để viết test script. Đây là ngôn ngữ dễ học, rất giống ngôn ngữ VBA – Visual Basic for Apptications. Chế độ Expert View của QTP là chế độ soạn thảo dành cho VBScript. Ngoài việc dùn VBScript để tương tác với phầm mềm được kiểm.
Một số màn hình làm việc của công cụ Quick Test Pro

•          Add-in Manager: 

• Giao diện chính của chương trình
  
•   Cửa số Object Repository Manager: dùng để quản lý các Object Reepository

• Giao diện kết quả test

Continue Reading →

#23 User Acceptance Test (UAT)

Introduce about User Acceptance Test, What, Why and How?

User Acceptance Test
 Is often the final step before rolling out the application
 Do by customer.
 AT environment, for most aspect should represent for the production environment.
 AT concentrates on validation types of testing to determine whether the system is fit for use.
 AT may occurs at many levels due to the scope of project (after UT, IT, ST).
 Time scale of AT may overlap on ST.

UAT - Objective
 Validate system set-up for transactions and user access
 Confirm use of system in performing business processes
 Verify performance on business critical functions
 Confirm integrity of converted and additional data, for example values that appear in a look-up table
 Assess and sign off go-live readiness

UAT –Why, When
- Why
 Accept product based on acceptance criteria
 Ensure function needed and expected by customers is present in a software product
-When:
 After software product is released and system tested

UAT – How To Test
 User Acceptance Test (UAT) Planning
 Designing UA Test Cases
 Selecting a Team that would execute the (UAT) Test Cases
 Executing Test Cases
 Documenting the Defects found during UAT
 Resolving the issues/Bug Fixing
 Sign Off.

UAT – Planning
 Outlines the User Acceptance Testing Strategy
 Identify the key focus areas
 Identify entry and exit criteria

UAT Plan Sample

UAT – Designing UA Test Cases
 Based on User Case
 Create test case for real-world flow
 Is described in a simple language the precise steps to be taken to test something.

 Is reviewed by Business Analysts

UAT – Select a Team…
 Is an important step
 The UAT Team is generally a good representation of the real world end users
 The Team thus comprises of the actual end users who will be using the application

UAT – Executing Test Case
 The Testing Team executes the Test Cases and may additional perform random Tests relevant to them
 The Team logs their comments and any defects or issues found during testing
 The issues/defects found during Testing are discussed with the Project Team, Subject Matter Experts and Business Analysts. The issues are resolved as per the mutual consensus and to the satisfaction of the end users

UAT – Sign Off
 This step is important in commercial software sales
 Indicates that the customer finds the product delivered to their satisfaction

User Acceptance Test Types
 User Acceptance Testing
 Operational Acceptance Testing
 Contract and Regulation Acceptance Testing
 Alpha and Beta Testing

Operational Acceptance Testing
 The acceptance of the system by system administrators, including:
 Backup/ restore
 Disaster recovery
 Maintenance tasks
 Security weakness

Contract and Regulation AT
 Contract acceptance testing is performed against a contract’s acceptance criteria for producing
custom-developed software. Acceptance criteria should be defined when the contract is agreed
 Regulation acceptance testing is performed against any regulations that must be adhered to,
such as governmental, legal or safety regulations

Alpha and Beta (or Field)
Testing
 Alpha test: do by users in development environment.
 Beta test: do by users in real world environment.

AT and Configuration Management
 The focus of CM during AT is similar to during ST
 The major difference are that the system is released to end-users and any problem reports and CRs are generated by end-users
 A help desk application can be useful tool for AT.

Continue Reading →

#22 Automation Testing Tools

What is Test Automation
 Test automation is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions. Commonly, test automation involves automating a manual process already in place that uses a formalized testing process.

Why do we need test automation
 Run existing tests on a new version of a program
 A lot of programs are frequently always modified in the same environment
 Run more tests more often
 Giving possibilities to run more tests which are run more often
 Perform tests that would be difficult or impossible to do manually
 Better use of resources
 Saving time
 Better use of resources
 Testers can do better jobs, machines can be run all the time.

Benefits of automated testing
a. Manual testing
 Time-consuming
 Tedious
 Depend on tester’s emotions => Serious defects may be undetected

b. Automated Testing
 Fast
 Reliable
 Repeatable
 Programmable
 Comprehensive
 Reusable

Test Tools
 Application test tools
 Source test tools (depends on program language)
 Functional test tools
 Performance test tools
 Embedded test tools
 Web test tools
 Functional test tools
 Performance test tools
 Test management tools
 Bug tracking tools

Test Tools Comparison
 Major features in Automated test tools
 Record & play back
 Web Testing
 Data function
 Image testing
 Extensible language
 Environment support
 Tools in comparison
 Rational Robot
 Ruby
 OpenSTA
 Quick Test Pro
 …

Record & Playback
 Details how easy it is to record & playback a test.
 Does the tool support low-level recording (mouse drags, exact screen location)
 Is there object recognition when recording and playing back or does it appear to record ok but then on playback (without environment change or unique id’s, etc changes) fail?
 How easy is it to read the recorded script

Web Testing
 Are there functions to tell me when the page has finished loading?
 Can I tell the test tool to wait until an image appears?
 Can I test whether links are valid or not?
 Can I test web based objects functions like is it enabled, does it contain data, etc
 Are there facilities that will allow me to programmatically look for objects of a certain type on a web page or locate a specific object?
 Can I extract data from the web page itself? E.g. the title? A hidden form element?

Data Function
 Does the tool allow you to specify the type of data you want?
 Can you automatically generate data?
 Can you interface with files, spreadsheets, etc to create, extract data?
 Can you randomise the access to that data?
 Is the data access truly random?

Image Testing
 Does the tool provide OCR (optical character recognition)?
 Can it compare one image against another?
 How fast does the compare take?
 If the compare fails how long does that take?
 Does the tool allow you to mask certain areas of the screen when comparing?

Type of Automation Test
 Functional Testing
 Performance Testing

Performance Testing Features (1)
 Performance Test Recording
 Flexible User Scenarios: To emulate the load test of realuser activities, an easy, complete and customizable building of user scenarios are provided.
 Real-world Performance Testing: Real-world web load testing allows you to dynamically vary the number of virtual users hitting your web applications/web sites to study the load testing/stress testing conditions under varying load.
 Dynamic Data Replacement: Modifying the performance test scripts to reflect dynamic data requires no programming skills.

Performance Testing Features (2)
 Server Performance Monitors: Load test your web sites/web applications with integrated monitoring of server machine's system resources (cpu % and memory usage).
 Configurable Playback Options: Wide range of play options that affects the playback of load test scripts.
 Proxy Support: Peformance testing can be done through proxy servers, supporting authentication and proxy exclusions for local networks.
 Distributed Load Testing: Option to simulate thousands of simultaneous users working from a single machine or distributed on multiple machines. Centralized coordination and reporting of distributed load testing results.

Performance Testing Features (3)
 Datapools for Parameterization: To use unique data for each user in load testing/stress testing
 Configurable Think Time: Configurable think times to perform real-world performance testing where each user spends thinking time (wait time) before performing the next action in the web page.
 Browser Simulation: Support for simulating exact browser behavior (MSIE, Firefox and Mozilla simulation).
 Random Delay: Random Delay for Virtual user start to simulate user visit to the web site/web application in irregular intervals.
 Bandwidth Simulation: Option to emulate different network speeds during playback.

Functional Testing Features (1)
 Playback Options
 Automatic/Customizable Error Recovery for unattended testing to handle unexpected window, like an ASSERT box, pop- ups, etc.
 Playback Synchronization to handle the variation in time the application takes to load a new page.
 Option to chain scripts for controlling the order of script execution.
 Multiple Playback Options that enables testers to debug test errors while creating and maintaining test scripts.
 Allows execution of individual and/or groups of tests from one or many workstations.

Functional Testing Features (2)
 Scripting Capabilities
 Simplified Script Creation with recording provision.
 Records parent/child frames, PopUp's, modal and modeless dialogs.
 Learn mode to learn objects into the object repository.
 Keyword-driven testing allows automation experts to have full access to the underlying object repository to author and debug scripts using pre-defined keywords.

Functional Testing Features (3)
 Scripting Capabilities …
 Standard Scripting Language allows you to easily create/update scripts without much programming knowledge.
 Object Repository eliminates the need to modify all the scripts each time the application is modified.
 Data-driven Testing enables you to perform functional testing in different scenarios by just changing the test data in an external data source.
 Unicode Support allows you to test multi-language deployments of your applications..


Functional Testing Features (4)
 Portability
 Allows you to record scripts in Windows and replay it in Linux without re-creating the scripts.
 Browser Abstraction Layer allows scripts recorded in one browser to be replayed in all other supported browsers.
 Runtime locale option lets you to simultaneously test all language versions of your application with a single script.

Functional Testing Features (5)
 Reporting Capabilities
 Clear and Powerful Reports are provided to indicate the status of the test execution.
 Hyperlinks allow easy navigation through the report. This helps you to quickly identify application failures and clearly assess application quality.
 Supported Environments
 Internet Explorer 6, Firefox 1.5.x and Mozilla 1.7.x, Windows XP, 2000 and Linux …

Continue Reading →

#21 Practical Guide to Software Unit Testing

1 Unit Test - What?
2 Unit Test - Why?
3 Unite Test - When?
4 Unit Test - How? (method, technique)

Unit Test – What
 Unit Testing Actions:
 Validate that individual units of software program are working properly
 A unit is the smallest testable part of an application (In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is always a method)
 Units are distinguished from modules in that modules are typically made up of units
 Unit Testing Deliverables:
 Tested software units
 Related documents (Unit Test case, Unit Test Report)

Unit Test – Why ?
 Ensure quality of software unit
 Detect defects and issues early
 Reduce the Quality Effort & Correction Cost

Unit Test – When ?
 After Coding
 Before Integration Test

Unit testing
 Modules can be tested statically or dynamically
 A basis path set will execute every independent path through a module
 Modules can be instrumented to gather statistics on their execution
 Modules can be unit tested top-down, bottom-up or in isolation
 Test drivers and stubs are required to unit test modules
=> The motivation is to ensure that value is not added to defective products

Source code reviews (static testing)
 Everyone’s code is reviewed
 Do not review code to measure individual performance
 Drawing a flow graph and calculating complexity could be used as part of the inspection
 Portability and maintainability can be given special attention during reviews

Unit testing (Dynamic testing)
 Functional test cases
 Black box test cases
 Structural test cases
 White box test cases
 Steps to develop a basis set of a module:
 Create annotated Pseudo code
 Draw Control Flow Graph
 Select a baseline path through the program (should be the most common paths that is followed)
 A second path is added by varying the outcome of the first decision along the baseline path while keeping all of the other decision outcomes as same as the baseline path
 This process is repeated until all of the decisions along the baseline path have had their outcomes altered.
 The number of paths in a basis set is always equal to the cyclomatic complexity of the module

Unit testing strategy
- Start with simple tests that get the module running;
- Run functional tests designed to validate that the module does what it is supposed to (positive test);
- Run negative tests that are designed to make the
module fail;
- Run tests associated with specific ISO 9126 quality attributes (performance, security, etc.) if required; and finally
- Add additional structurally tests to complete a basis set that achieves coverage of all independent paths;

Unit testing strategy (cont.)
- Both Functional and structural test techniques identify positive test cases
- Negative tests are designed to demonstrate that a module does not work as expected. Unfortunately,
there are no simple techniques for identifying negative test cases. Error guessing, based on experience, remains the best approach.

- Some common types of error include:
 Array sizes;
 Counter maximums;
 Physical boundaries;
 Variable field sizes;
 Arithmetic operation;
 Switch variable values;
 Pointer variables; and
 Null values.

Order of Testing modules
 Top-Down Unit Testing: stubs are required
 Bottom-up Unit Testing: drivers are required
 Isolation Unit Testing: drivers and stubs are required for each module

Advantages and Disadvantages

Unit Test – How? Techniques
 Black box test (Functional)
• Specification derived tests
• Equivalence partitioning
• Boundary value analysis
 White box (Structural)
• Statement coverage
• Decision (branch) coverage
• Path coverage

Unit Test – Black box technique

 Black-box testing
 Functional testing: ensure each unit acts right as its design
 Business testing: ensure the software program acts right as user requirement

Unit Test –White box technique

 White-box testing
 Check syntax of code by compiler to avoid syntax errors
 Run code in debug mode, line by line, through all independent paths of program to ensure that all statement of codes has been executed at least one time
 Examine local data structure to ensure that data stored temporarily maintains its integrity during all all steps of code execution
 Check boundary conditions to ensure that code will run properly at the boundaries established as requirements
 Review all error handling paths

BBT – Specification derived test
 You can choose all or some statements in the specification of software
 Create test cases for each statements of specification
 Execute test cases to check test result will output as the specification

Example Specification
 Input - real number
 Output - real number
 When given an input of 0 or greater, the positive square root of the input shall be returned.
 When given an input of less than 0, the error message "Square root error - illegal negative input" shall be displayed and a value of 0 returned.

Example Test Cases
 Test Case 1: Input 4, Return 2
 Use the first statement in the specification
 ("When given an input of 0 or greater, the positive square root of the input shall be returned.").
 Test Case 2: Input -10, Return 0, Output "Square root error - illegal negative input“
 Use the second and third statements in the specification
 ("When given an input of less than 0, the error message "Square root error - illegal negative input" shall be displayed and a value of 0 returned.”).

BBT: Equivalence partitioning
 Divide the input of a program into classes of data from which test cases can be derived. This might help you to reduce number of test cases that must be developed.
 Behavior of software is equivalent for any value within particular partition
 A limited number of representative test cases should be chosen from each partition

Example Test Cases

White box test : Node

WBT: Statement Coverage

WBT: Decision/Branch Coverage

WBT: Path Coverage

Example: White box test case

White box test: Comparison

Unit Testing Tools

Continue Reading →

#20 Software Quality & Risk

Risk Overview:

 Is possibility of a negative or undesirable outcome
 It is a possibility, not a certainty
The level of risk associated with its possible negative consequences
Risk is classified into 2 types: Product Risk and Project Risk

Where to look for risks?
 Dependencies: HR, tool, equipment, etc.
 Assumptions: may not actually be true.
 Project characteristics: objectives, requirement, design, implementation, testability, etc.
 Activities on the critical path
 Team spirit and attitude
 Outside project: organization, policies, rules, standards, etc.
 ….

Product Risk
 Product risks/Quality risks: the possibility that the system or software might fail to satisfy some reasonable customer, user, or stakeholder expectation
 Unsatisfactory software might:
 Omit some key functions that the customers specified
 Unreliable and frequently fail to behave normally
 Fail in ways that cause financial or other damage to a user or the company that user works for
 Have problems related to a particular quality characteristic, which might not be functionality, but rather security, reliability, usability, maintainability or performance
 Project risks: apply to testing. The same concepts we apply to identifying, prioritizing and managing product risks.
 What project risks affect testing?
 Direct risks:
 Late delivery of the test items to the test team
 Availability issues with the test environment
 Indirect risks
 Excessive delays in repairing defects found in testing
 Problems with getting professional system administration support for the test environment
 For any risk, product or project, you have four typical
options:
 Mitigate: Take steps in advance to reduce the likelihood (and possibly the impact) of the risk.
 Contingency: Have a plan in place to reduce the impact should the risk become an outcome.
 Transfer: Convince some other member of the team or project stakeholder to reduce the likelihood or accept the impact of the risk.
 Ignore: Do nothing about the risk, which is usually a smart option only when there's little that can be done or when the likelihood and impact are low

Software Quality and Risk
 Contrary to popular beliefs, testing cannot demonstrate that software works
 Software testing must be viewed as a risk mitigation activity designed to reduce the risk of defects in software
 Standard lists of risk factors are useful for identifying potential risks
 Risk analysis priorities risks based on the likelihood that they will occur & their potential impact

Software testing
To prove the software works correctly
 Executing all paths => Only possible for a simplest of software
 Every combination of input & output => Only possible if the executing the tests could be performed automatically
Testing and Risk:
 There will always be a real possibility that software will contain defects no matter how well it is tested
 The goal of software testing is to minimize the risk of defects Risk-based Testing
 Uses risk to prioritize and emphasize the appropriate tests during test execution
 Starts early in the project, identifying risks to system quality and using that knowledge of risk to
guide testing planning, specification, preparation and execution
 Involves both mitigation and contingency
 Mitigation - testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects
 Contingency - testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects

Minimizing Risks
 Risk assessment:
 Identify what potential risks exist
 Determine the likelihood of a risk occurring & the impact if it occurs
 Risk control: identify & perform activities to
 Minimizing the likelihood of a risk occurring
 Minimizing the impact if the risk occurs

Risk Statement template
Given the <condition>, there is a possibility that
<consequence> will occur
 Condition: describes the situation that gives rise to the risk
 Consequence: describes a potential undesirable outcome related to the situation

Analyzing Risks

Quality Risk Dimensions

Prioritizing Risks
 Compare risks with the software quality characteristics described in ISO 9126 and estimate the potential impact that each risk could have each characteristic
 Example: (open excel file for reference)

Risk Factor Influence on Software Quality Characteristics

Example
Risk Control
 Risk can be controlled by planning, specifying & executing activities designed to:
 Minimize the likelihood of a risk occurring
 Minimize the impact of the risk if it does occur
 The results of executing risk control activities is recorded for three reasons:
 The record provides auditable evidence that the risk control activities were performed
 The data can be used to measure the efficiency of the risk control activities
 The data can be used o decide if an acceptable level of risk has been achieved

Continue Reading →

#19 Introduce about CAR Process, DPC, DP at project level

Purpose:
1 Understand CAR and CAR process
2 Responsibilities of DPC, DP Teams
3 How to conduct Causal Analysis meeting and identify preventive actions
4 How to create/update DP log
5 Group assignment: Causal analysis & resolution meeting

Misconceptions on CAR
 During Project Execution -> From Project Planning
 To fix problem -> to minimize the cause (Prevention)
 Apply only for Defects -> Issue/Incident/Defects/NC/Customer complaint
NC= Non Conformity

CAR process & How?

 Plan for CAR periodically at organization and project level (DP Plan)

 Follow goal and objective of organization/project

 Determine resource

 Plan for budget & effort …

 + How?

Problems can be:

 Defect -> Common defects/Common cause

 Use Pareto chart ( 80/20 rules)/ to select some defect type to analyze further

 Should consider

 Impact of defects

 Frequency of occurrence

 Similarity between defects

 Cost for analysis

 NC/Issue/Customer complaints

 State the problem out and log it to tracking system

How to determine problem?

 Pareto: To determine the priorities of the problem to be analyzed. It helps in identifying this vital few pictorially

 Common issues , defects/Common causes

 80/20 Rule : What 20% of sources are causing 80% of the problems?

 Where should we focus our efforts to achieve the greatest improvements?

=> Answer

 Analyse cause

 Hold CAR meeting

 Brainstorming to identify Cause

 Use Cause and Effect (fish bone/ Ishikawa) techniques

 Use 5 why rule

 Groups Causes to categories

 Log common defects to common defect list

 Define action proposals

 Log DP actions to DP logs

 Log analysis and actions to Issue list for problems

How to find the root cause?

 Fish born ( see picture)

 Cause can be branched to categories

 Ask why and put bone to the fish till we find the root cause

 5 why

 Ask why 5 times till we see the root cause Why A? Answer : B, Why B? answer: C, Why C?....

 5 why can be used separately or with fish bone

 Reference for 5 why?

 Ask why 5 time for each categories below

 Investigate why problem happen ( specific root cause)?

 Investigate why the problem was not detected:

 Investigate why system let the problem happen ( Systemic root cause): such as current process, procedure,….

Example – 5 Why
Cấp trên giao trách nhiệm cho bạn tìm văn phòng mới vì hàng tháng nay các nhân viên phòng mua hàng phàn nàn việc thiếu chỗ làm việc. Trước khi đưa ra dự án, bạn quyết định nghiên cứu vấn đề. Vậy bạn nên tiến hành trao đổi với các nhân viên trong phòng
1. Tại sao các anh muốn có văn phòng mới?
Câu trả lời nhận được một cách tức thì: thiếu chỗ, mỗi văn phòng có những 3 người
2. Nhưng tại sao lại có 3 người trong mỗi văn phòng
Câu trả lời: vì chúng tôi phải lưu kho ngay cả những máy tính cần kiểm tra trước khi gửi chúng đến các phòng ban khác. Cả 1 tầng đầy máy tính
3. Tại sao các anh phải kiểm tra máy tính ngay tại đây?
Trả lời: Trước kia nhà cung cấp họ tự kiểm tra chất lượng, bây giờ chúng tôi phải làm việc này
4. Tại sao nhà cung cấp lại ko tự kiểm tra chất lượng nữa?
Trả lời: Đi mà hỏi người quản lý mua hàng. Khi bạn hỏi ông ta cũng câu hỏi đó, ông ta trả lời rằng nhà cung cấp đã tăng lệ phí cho việc kiểm tra này lên 70%
5. Bạn gọi cho nhà cung cấp để biết được quan điểm của họ "tại sao các ông lại tăng lệ phí cho việc kiểm tra này?"
Trả lời: đó là do người quản lý chất lượng của công ty có những yêu cầu hoàn toàn thiếu thực tế. Việc kiểm tra mà ông ấy yêu cầu phải mất 4 hours cho mỗi máy tính.
=> Sau "5 tại sao" cuối cùng bạn đã tìm ra được thực chất của vấn đề: những yêu cầu phi thực tế của phòng quản lý chất lượng. Vì vậy bạn đã yêu cầu thay đổi những yêu cầu này và nhà cung cấp lại bắt đầu tiếp tục công việc kiêm tra. Kể từ đó phòng mua hàng lại có chỗ làm việc của họ

How?
 Implement actions
 Assign person in charge
 Implement and track to closure
 Logs info in DP logs or Issue actual actions
 Evaluate the effect of change
 Evaluate the benefits of actions
 Log benefits in DP log of action
 Records:
 All records are kept for later process improvement in organization level
 Sharing:
 Common defects of most used program languages in organization
 Technical knowledge to share experience, practice or lessons
 DP Norm
 DP Database

DPC
 Board of Management (BOM): responsible for problem analysis and resolution at organization level. BOM decides that Group/Project team should conduct Causal analysis meeting for issues/problems
 Defect Prevention Council (DPC): responsible for Defect Prevention actions at organization level
 Responsibility:
 Prepare DP plan for organization.
 Review and approve DP plan of groups.
 Defect report monthly
 Identify and provide necessary resource for defect and problem prevention.
 Evaluate performance of DPC biannually.
 Control the implementing of DP activities of groups through review and internal audit.

DPC members
 DPC head: QA branch will take responsible for DPC at organization level
 DPC lead of OGs: QA leaders take this role.
 DP Specialists: Each OG will has plan and list of DP specialists
 Qas

CAR Meeting
 When: Quarterly/BOM decides or critical problem occurs
 Purpose: To decide preventive actions and implement at organization level
 Responsibility: DPC Head/DPC Lead/Group Leaders/QA Leaders
 Content:
 Identify problems and major defects
 Analyze the root causes of problems/defects
 identify most expensive, most frequent defects or problems
 Give preventive activities for problems/defects
 Assign member and give deadline for preventive action

DPC at Group level
-  DP Plan
 Set DP target for the group basing on special requirements of groups/customers
 Members of DPC at Group: Coordinator
 DP Specialists
 DP Actions of groups (to achieve the targets)
 In the Initiation stage of the project, Project manager establishes DP Team for the project
 DP team sets targets and plans DP activities
 DP Plan of a project includes 3 items :
 DP targets: The targets should follow goals of DP at Group level.
 DP activities: give actions to avoid defects and meet DP target
 DP Team
- Review DP Plan
 DP plan is reviewed by PM, project QA and approved by DP leader.
 DP Plan is approved in Kick-off meeting
 Causal analysis meeting
 When:
 As planned DP plan.
 Defect density is over the norm
 Problem that affects to quality or productivity occurs
 Causal Analysis meeting can be a part of project meeting
 Purpose
 Discuss and evaluate the effectiveness of Defect/Problem preventive actions defined in previous meeting
 Identify most common defects/problems of the project and root causes of those defects/problems.
 A root cause is a source of a defect such that if it is removed, the defect is decreased or removed
 Find out actions to prevent similar errors/problems
 Preparation
 DP Teams/PM/PTLs review defect/problem data and list some common defects/problems
 Update results of actions in DP log or Issue list
 Invite all members and DPC representative to the meeting

- In the meeting:
 Report status of planned DP actions and actual result or report the problems and the impacts/effectiveness
 Discuss about common defects/problems in last phase
 Analyze the root causes of defects/problems
 Prioritize defect/problem types
 Identify possible actions to prevent occurrence of similar defects or problems
 Assign member and give deadline to implement preventive action.
 Records
 Meeting minutes
 Preventive action is logged in DP log
 Common Defects : record all common defects of the project with root causes.
 Issues: record all issues, causes, solutions and actions to remove the causes.

Continue Reading →

#18 Exercise to create test report

Exercise 1
 Create test report for each function: include following items:
1. Number of test case
2. Number of passed test case
3. Number of fail test case
4. Number of untested test case
5. Number of N/A test case
6. Percentage of test coverage
7. Percentage of test successful coverage

Answer 1:

=> Conclusion:
Function ‘Manage student mark’ has many fail test case.
The system can not calculate student mark

Exercise 2
 Create general defect report:
 Open defects: base on severity (Fatal, serious, Medium,
Cosmetic) and status of defect ( Error, Assigned, Fixing,
Corrected, Confirming)
 Fixed defects: base on severity (Fatal, serious, Medium,
Cosmetic) and status of defect Delivered, Validated,
Approved, Accepted, Canceled, Closed)
 Total weight defect:
 1 cosmetic defect = 1 w.def
 1 medium defect = 3 w.def
 1 serious defect = 5 w.def
 1 fatal defect = 10 w.def

Answer 2:

Execise 3:
 Create Defect distribution test report (include following information)
 Number of defects for each process ( Requirement, Design, Coding, Test, Other)
 Number of defects for each QC activities ( Unit test, Integration test, System test, Acceptance test, Code review, Document review, Final Inspection, Baseline audit
 Total weight defect:
 1 cosmetic defect = 1 w.def
 1 medium defect = 3 w.def
 1 serious defect = 5 w.def
 1 fatal defect = 10 w.def

Answer 3:

Exercise 4
 Create Defect trend
 Draw graph to know found defects and fixed defect trend From date….. To date

Answer 4:

Continue Reading →