Automated testing: Difference between revisions

From A Technological Wiki
Jump to navigation Jump to search
imported>Unknown user
No edit summary
imported>Unknown user
No edit summary
Line 1: Line 1:
Automated testing involves using software tools to execute pre-defined tests on a software application without manual intervention. The goal is to efficiently validate that the software functions correctly and meets specified requirements. By automating repetitive test cases and enabling parallel execution, automated testing can significantly accelerate the testing process. It provides consistent test results, facilitates early bug detection, and allows for robust regression testing as the codebase evolves. While it requires initial setup and maintenance of test scripts, the benefits of speed, repeatability, and accuracy make it a pivotal component in modern software development and continuous integration pipelines.


{{AttachmentsSectionStart}}
<span id="benefits-of-automated-testing"></span>
* [[Media:UserDocumentation_Knowledge_Central_KC_IT_IT_Quality_assurance_team_Automated_testingimage-20250419-102906.png]]
= Benefits of automated testing =
* [[Media:UserDocumentation_Knowledge_Central_KC_IT_IT_Quality_assurance_team_Automated_testingimage-20250419-102956.png]]
* [[Media:UserDocumentation_Knowledge_Central_KC_IT_IT_Quality_assurance_team_Automated_testingimage-20250419-102906.png]]
* [[Media:UserDocumentation_Knowledge_Central_KC_IT_IT_Quality_assurance_team_Automated_testingimage-20250419-102956.png]]


{{AttachmentsSectionEnd}}
* Trust in the code, both new and legacy
* Build quality in the first place
* Development speed
* constrain on development process to encourage good practices
* Think more about the code
* Reduce time to production


<span id="main-attributes"></span>
= Main attributes =
* They must be fast in order to be executed without generating a bottleneck
* They must be executed from the early phases of development / integration
* Group tests by suites in contexts / environments
* theyreduce workload on testers so they can concentrate on manual tests
* It is better to write and run incomplete tests than not running complete tests
* When you find a bug, first write the test
<span id="test-types"></span>
= Test types =
* business-faced
* technology-faced
* cross functional
[[File:UserDocumentation_Knowledge_Central_KC_IT_IT_Quality_assurance_team_Automated_testingimage-20250419-102906.png|576px|center]]
<span id="testing-strategy"></span>
= Testing strategy =
Its design is primarily a process of identifying and prioritizing project risks and deciding what actions to take to mitigate them.
Testers collaborate with developers and users to write automated tests from the start of the project. These tests are written before developers start working on the features they test. When feature is completed and tests pass, they demonstrate that the functionality has been implemented completely and correctly.
An automated testing strategy needs to be improved constantly. If some use case changes a lot, do not invest a lot of time changing it, wait until it is stable and then create the automated test. If test won't be used again, delete it, you can always retrieve it from version control. It is important to remember that you should only write automated tests where they will deliver value.
<span id="new-projects"></span>
== new projects ==
They represent a chance to achieve these ideals with a low cost by establishing some simple ground rules and creating some relatively testing infrastructure. It is important to start writing automated acceptance tests by:
* choosing a testing tool
* Set up a simple automated build
* Describe requirements that follow INVEST You can them implement a strict process:
* Stakeholders and testers define acceptance criteria
* Testers work with developers to automate acceptance tests based on acceptance criteria
* Developers code behaviour to fulfill acceptance criteria
* If any tests fail, make it a priority to fix them.
== midproject ==
Often we find ourselves in projects that develop a rapidly changing codebase under pressure to deliver. The best way to introduce automated testing is to begin with the most common, important and high-value use cases of the application. You should automate <u>happy paths</u> that cover them. Those tests that are no that repetitive, do not need to be straightly automated.
<span id="legacy-systems"></span>
== legacy systems ==
''Legacy systems are those that do not have automated tests'' - Michael Feathers
The first priority is create an automated deploy process and then create an automated functional test based on the documentation or knowledge of team that developed the system.
Oftenly stakeholders are unwilling to allow the development team spend time on what seems to them a low-value activity like testing. It is important to sit down with stakeholders and identify its high-value use cases and their tests. They are essentially smoke tests for the legacy system.
Code in legacy systems often are not modular an well structured. Thus it is common for a change in one part of the code to affect another area. One useful strategy is creating an acceptance test for the happy path and then start refactoring the whole system.
[[File:UserDocumentation_Knowledge_Central_KC_IT_IT_Quality_assurance_team_Automated_testingimage-20250419-102956.png|576px|center]]
  <!-- From bodyContent 1543106.mraw -->
  <!-- From bodyContent 1543106.mraw -->



Revision as of 11:30, 19 April 2025

Automated testing involves using software tools to execute pre-defined tests on a software application without manual intervention. The goal is to efficiently validate that the software functions correctly and meets specified requirements. By automating repetitive test cases and enabling parallel execution, automated testing can significantly accelerate the testing process. It provides consistent test results, facilitates early bug detection, and allows for robust regression testing as the codebase evolves. While it requires initial setup and maintenance of test scripts, the benefits of speed, repeatability, and accuracy make it a pivotal component in modern software development and continuous integration pipelines.

Benefits of automated testing

  • Trust in the code, both new and legacy
  • Build quality in the first place
  • Development speed
  • constrain on development process to encourage good practices
  • Think more about the code
  • Reduce time to production

Main attributes

  • They must be fast in order to be executed without generating a bottleneck
  • They must be executed from the early phases of development / integration
  • Group tests by suites in contexts / environments
  • theyreduce workload on testers so they can concentrate on manual tests
  • It is better to write and run incomplete tests than not running complete tests
  • When you find a bug, first write the test

Test types

  • business-faced
  • technology-faced
  • cross functional

Testing strategy

Its design is primarily a process of identifying and prioritizing project risks and deciding what actions to take to mitigate them.

Testers collaborate with developers and users to write automated tests from the start of the project. These tests are written before developers start working on the features they test. When feature is completed and tests pass, they demonstrate that the functionality has been implemented completely and correctly.

An automated testing strategy needs to be improved constantly. If some use case changes a lot, do not invest a lot of time changing it, wait until it is stable and then create the automated test. If test won't be used again, delete it, you can always retrieve it from version control. It is important to remember that you should only write automated tests where they will deliver value.

new projects

They represent a chance to achieve these ideals with a low cost by establishing some simple ground rules and creating some relatively testing infrastructure. It is important to start writing automated acceptance tests by:

  • choosing a testing tool
  • Set up a simple automated build
  • Describe requirements that follow INVEST You can them implement a strict process:
  • Stakeholders and testers define acceptance criteria
  • Testers work with developers to automate acceptance tests based on acceptance criteria
  • Developers code behaviour to fulfill acceptance criteria
  • If any tests fail, make it a priority to fix them.

midproject

Often we find ourselves in projects that develop a rapidly changing codebase under pressure to deliver. The best way to introduce automated testing is to begin with the most common, important and high-value use cases of the application. You should automate happy paths that cover them. Those tests that are no that repetitive, do not need to be straightly automated.

legacy systems

Legacy systems are those that do not have automated tests - Michael Feathers

The first priority is create an automated deploy process and then create an automated functional test based on the documentation or knowledge of team that developed the system.

Oftenly stakeholders are unwilling to allow the development team spend time on what seems to them a low-value activity like testing. It is important to sit down with stakeholders and identify its high-value use cases and their tests. They are essentially smoke tests for the legacy system.

Code in legacy systems often are not modular an well structured. Thus it is common for a change in one part of the code to affect another area. One useful strategy is creating an acceptance test for the happy path and then start refactoring the whole system.