🗊Презентация Test cases overview v.1.5

Fundamental Test Process

Test Planning and Control Test Planning Determine the scope and risks and identify the objectives of testing Determine the test approach (techniques, test items, coverage, etc) Implement the test policy and/or the test strategy Determine the required test resources (e.g. people, test environment, PCs) Schedule test analysis and design, test implementation, execution and evaluation Determine the exit criteria Test Control Measure and analyze the results of reviews and testing Monitor and document progress, test coverage and exit criteria Provide information on testing Initiate corrective actions Make decisions

Test Analysis and Design Test Analysis and Design Review the Test Basis * Identify Test Conditions ** based on analysis of Test Items ** Design the tests using Test Design Techniques Evaluate testability of the requirements and system Design the test environment set-up and identify any required infrastructure and tools * Test Basis – all documents from which the requirements of a component or system can be inferred (the documentation on which the test cases are based). ** Test Items (Test Conditions) – an item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute or structural element.

Test Implementation and Execution Test Implementation Develop and prioritize our test cases, using the techniques Create test suites from the test cases for efficient test execution Implement and verify the environment Test Execution Execute the test suites and/or individual test cases, following test procedures Log the outcome of test execution Report discrepancies as incidents Repeat test activities as a result of action taken for each discrepancy

Evaluation and Reporting Evaluating Exit Criteria and Reporting Check test logs against the exit criteria specified in test planning Assess if more tests are needed or if the exit criteria specified should be changed Write a test summary report for stakeholders

Test Closure Activities Test Closure Activities: Check which planned deliverables we actually delivered Finalize and archive ‘testware’ Evaluate how the testing went and analyze lessons learned

Output Documentation

Test case DEFINITION / structure

…makes you think about specific usage scenarios, looking for places forgotten by everybody (like implicit requirements); …makes you think about specific usage scenarios, looking for places forgotten by everybody (like implicit requirements);

Test Case ID Test Case ID Identification of the test case It should be unique across Test Case Specification Can consist of numbers or/and letters Example: 1, 2, 3, etc; UR.001, UR.002, etc Test Case Name Short name of test case which briefly indicates what will be verified Description / Objective Describes the functionality/actions that test case validates/does It should be detailed enough to understand purpose of test case Priority Reflects the relative importance of the test case taking into consideration different aspects Can be presented by words or numbers Example: High, Medium, Low, etc; Major, Minor, Trivial, etc; 1, 2, 3 (where 1-the most important, and 3-the least important), etc

Test Case Type Test Case Type Reflects the type of test case depending on what kind of testing is covered by particular test case Example: GUI, Functional, System, Performance, etc. Automation Status Indicates whether test cases is candidate for automation taking into consideration different aspects or not Also indicates whether test cases is automated already or not Example: Candidate – test case is recommended for automation, but it is not automated yet Not Candidate – test case is not recommended to be automated and should be run manually Automated – test case is automated and during the next execution can be run automatically etc. Pre-condition Defines conditions that should be met before test case can be executed Usually pre-condition field lists data/actions which should exist/be done in system and links to appropriate test cases/test functions which can setup required pre-conditions Test Steps Step by step instructions on how to carry out the test case There should not be missed or redundant steps!

high critical functionalities, which are the parts of Core test cases or new functionality, implemented in build/release modules containing more bugs, more complex or more dependent areas which are highly accessed by the customer/end users positive test cases risk analysis

Good Candidates for Automation are: Good Candidates for Automation are: Repetitive test cases that run for multiple builds Test cases that run on several different configurations (hardware/OS) Frequently used functionality that introduces high risk conditions Test cases that tend to cause human error Test cases that require multiple data sets Test cases that are impossible to perform manually Test cases that take a lot of effort and time when manual testing Bad Candidates for Automation are: If automation efforts are few times higher than manual execution Test cases that are only performed a few times Some test steps cannot be automated

Test case IMPLEMENTATION

Test case SPECIFICATION

Test Case Specification Identifier section covers Test Case Specification Identifier section covers Unique "short" name for the test case Version date and version number of the test case Version Author and contact information Revision history Test items identifies the items or features to be tested by test case. References for source documents (Requirements Specification, Mock-ups, Users Guide etc) can be provided in the section as well Input Specifications identifies all inputs required to execute the test case (Data, Tables, Human Actions, Conditions, Files etc) It is also acceptable to simplify the documentation process by using tables for elements, steps and values

Output Specifications identifies Output Specifications identifies all outputs required to verify the test case outputs can also be simplified using tables as noted above and may even be included in the same table as the associated input to further simplify the documentation and improve its usefulness Environmental needs consists of Hardware Configurations Limitations Software System (Operating systems, Compilers, Tools) Other Application Mix of applications Other Facilities Training

Special procedural requirements identifies Special procedural requirements identifies Any special constraints on the test case(s) Special approach (in needed) for executing test case(s) Focus on key elements such as: Special Setup Operations intervention Output location and identification Special wrap-up Inter-case dependencies identifies Any prerequisites for test cases It is also recommended that the relationship of test cases be documented at both ends of the relationship.

TEST CASE MANAGEMENT TOOLS

Many organizations use Microsoft Excel to create and manage Test Cases. Test Case Specifications are stored in repositories Many organizations use Microsoft Excel to create and manage Test Cases. Test Case Specifications are stored in repositories

PractiTest – the complete & lightweight SaaS solution for QA Management, SaaS Test Management, Issue Tracking and Requirements PractiTest – the complete & lightweight SaaS solution for QA Management, SaaS Test Management, Issue Tracking and Requirements 5 key features of PractiTest Flexible Hierarchical Views Fields and Workflow Customization Intelligent Anti-Duplication Bugs Mechanism Bugs submitting by Email Super-Fast Bug Review

BEST PRACTICES

Write test cases for all possible test conditions of test item Write test cases for all possible test conditions of test item Write test cases with necessary level of detail: Detailed test cases if automation is going to have place Detailed test cases if any legal compliance standards to testing on project Non-detailed test cases (or just test objectives) if test case won’t be executed often or step setup is described in another document (link to the document should be provided) Write test cases independent and cross-platform: The last test case step should return system to the state before executing this test case It is possible to re-order test cases without additional steps or data setup Tests should be cross-platforms as reasonably possible, working across different devices, platforms, screen resolutions, etc Write test cases according to STANDARD TEMPLATE (project convention)

Write short test cases (up to 10-15 steps) Write short test cases (up to 10-15 steps) Write steps using simple English and general words Write ACCURATE test cases Write test cases so that expected results are easy to interpret Provide TEST DATA if possible or where it makes much sense Add reference to bugs and requirements Add notes/highlight things if you want to convey / pay attention to some info Write detailed SQL queries (it will save time while executing) Keep test cases UP TO DATE 