How to write a test case

Август 7, 2022

Главная
Разное
How to write a test case

Содержание

2. Test plan Template: Write test cases according to requirements/acceptance criteria, and think about all the following
3. How to write a test for the Automation Pay attention when you write Regression tests for
4. Test case fields and links: Pay attention when you write the Test case to do the
5. Bug definition
6. Before opening a bug Make sure it's a bug and the scenario you made is valid.
7. Bug structure Description: …….. -Keep the title short and readable -Use the affected area/feature in the
8. Defect Severity
9. System behavior which worked OK on the previous build/s, and on the current tested build behaves
11. Скачать презентацию

Слайд 2

Test plan Template:
Write test cases according to requirements/acceptance criteria, and think

about all the following aspects:
Acceptance tests / Sanity Tests
Configuration + setup
Functionality
GUI / UI
Usability
Integration tests
Recovery / Disconnections
Long term
Stress/load test
Use cases
Logs/Audit-Important!
Performance
Upgrade
Limitations
Regression
Backward compatibility
Operating system + OS language

Слайд 3

How to write a test for the Automation
Pay attention when you

write Regression tests for the automation:
The test case should be short and divided by topics
The expected result should be one and exact

Слайд 4

Test case fields and links:
Pay attention when you write the Test

case to do the following:
Link the test case to the User Story with the ‘Tests’ relation
Use correct tags. for example:
After Test design-review meeting (when TC was approved),
change the ‘Qognify automation status’ drop down to
‘Ready for automation’ or ‘Not Required’ in case automation
is not required.

Слайд 5

Bug definition

Слайд 6

Before opening a bug
Make sure it's a bug and the

scenario you made is valid.
The meaning of opening a bug that is not really a bug is wasting your time opening the bug, the developers' time to start researching, and then again your time to close the bug and add an explanation of why it opened and closed.
Check yourself twice before each bug you open if it is indeed a bug and if so, is it already open/open now that there will be no duplicates and the bug will not be closed as a "work-as-design/not-reproduced/Duplicate" status

Слайд 7

Bug structure
Description:
……..
-Keep the title short and readable
-Use the affected

area/feature in the title
-Describe the bug with simple words what is not working well
Steps to Reproduce:
1.
2.
Expected Results:
…….
Actual Results:
…….

1. Attached is a file to a bug:
Screenshots
Dumps and log files
2. Link the defect to the User Story (relevant for new content)
3. In case of regression, mark the ‘Regression’ radio button as ‘True’
4. Choose the correct Severity/priority according to the next slide
5. Fill the ‘found in Version/Build’ fields

Слайд 8

Defect Severity

Слайд 9

System behavior which worked OK on the previous build/s, and on

the current tested build behaves differently or broken.
Relevant for the previous version, and for previous builds on a specific version.
QA should state the scenario that was once successful or verify the right behavior on the previous version/build.
All info should be documented in the comments field including the version/build number that was used for comparison, or the test case and its related version and build

Regression Defects